Gamedev Serj Nilov
7 761

Как написать дизайн-документ игры

Советы новичкам от опытного геймдизайнера

В закладки

Прежде, чем начать рассказывать правила составления ГДД, давайте определимся, кто же такой геймдизайнер и какова его роль в команде. Ближайший аналог геймдизайнера в искусстве — это режиссёр. Он не играет в фильме, не занимается светом и декорациями и даже не держит камеру, но при этом именно он решает, как должен выглядеть фильм, чтобы он доносил зрителю те ощущения, которые хочет режиссёр. Также и геймдизайнер очень часто не умеет рисовать и программировать, но обязан уметь вызывать у игрока нужные ощущения.

Поэтому его можно назвать мозгом команды, тем, кто всегда контролирует то, что делают все остальные. Даёт задания и принимает работу. Поэтому главное умение геймдизайнера — находить общий язык со всеми в команде и делать так, чтобы они производили именно то, что есть в его голове. Поэтому в идеале нужно, чтобы каждый проект вёл один хороший специалист. О том, насколько трудно такого найти — это уже совсем другая тема. Просто давайте держать в голове, что эта статья — про хорошего геймдизайнера или того, кто хочет им стать.

Вы, наверное, заметили, что среди обязанностей геймдизайнера я не упомянул ГДД. Потому что в идеальном сферическом мире он не нужен. Там геймдизайнер всегда держит в голове описания всех фич, никогда не болеет, не увольняется и ему не нужно ни перед кем отчитываться. Геймдизайнерский документ игры — это вспомогательный документ. Страховка студии от пропажи геймдизайнера, памятка о том, что он хотел сделать, ведь разработка может подчас растягиваться во времени по не зависящим от него причинам, и памятка для специалистов о том, что они должны сделать, если вдруг отвлеклись.

Тут важно отдельно выделить человеческий фактор. Даже при самом идеально написанном техническом задании (далее, ТЗ) будут те, кто его поймёт не так. Кто-то неправильно интерпретирует очевидный вам оборот. Кто-то не будет знать термина или будет знать его омоним (которые в индустрии встречаются довольно часто). Кто-то просто пропустит строчку, читая по диагонали. Действовать с такими людьми жёстко — с высокой вероятностью угробить собственную компанию.

Некоторые, желая сэкономить, нанимают геймдизайнера только для написания документации — результат обычно плачевный. Фильмы не снимают без режиссёра, даже когда из Marvel уволила гениального Эдгара Райта и он оставил после себя максимально полные раскадровки, они всё равно наняли другого человека, чтобы тот доделал фильм. Хотя раскадровки Райта, конечно, лезут из всех щелей и теоретически можно было бы работать по ним.

Теперь о том, как писать сам ГДД. Крупные компании используют для этого сервисы вроде Confluence, но я, поработав в них, нахожу их не особо удобными, по сравнению с самым доступным способом ведения документации — Google Docs. Легко заполнять, легко делиться, легко ориентироваться, да ещё и бесплатно. Если вы беспокоитесь за безопасность, всегда есть возможность сделать корпоративный аккаунт Gmail и тогда никто за пределами студии не зайдёт в вашу документацию.

Следующий большой вопрос — ГДД в одном файле, или как набор ТЗ. Скажу прямо — оба варианта имеют право на жизнь. Первый вариант имеет смысл использовать если у вас небольшой проект вроде match-3 или подобной игры. ГДД до 20 страниц объективно удобнее хранить одним куском. Если же у вас есть гора различных режимов или контента, например миллиард различных танков для WoT, или подробное описание каждого уровня для шутера, то лучше это всё распихать по разным документам, оставив главному лишь структуру.

Также это удобно для выдачи задач: кинул ссылку на конкретный документ — и не паришься, разъясняя, где искать. Но, повторюсь, очень часто удобнее хранить всё в одном файле так как многие проекты не отличаются размером.

Оглавление

В малом проекте с этим всё просто — оно делается штатными средствами документов. Или не делается вообще, что тоже бывает. Если же у вас крупный проект, да ещё и с иерархией, то в главном файле лучше расписать всю его структуру со ссылками на все остальные файлы. Если у вас в проекте есть иерархия, то не стоит ложить ссылку на самое дальнее ТЗ только в промежуточном.

В мой первый месяц работы у меня случилась неприятность: я выложил спецификации по самолётам для World of Warplanes в один подраздел (за давностью лет не помню уже в какой), а программисты искали его в соседнем (художники, кстати, не промахивались). Сначала я хотел продублировать ссылки, чтобы их можно было найти везде, но потом я понял, что правильнее просто выложить все ссылки в виде структуры прямо в главном документе. Тогда сразу появляется понимание структуры проекта и не нужно делать лишних кликов для перехода на нужную страницу.

Вступление

Место для краткого описания игры. Фактически краткая выжимка концепт-документа: название, технологии, платформы, аудитория. Это информация не для вас и не для вашей команды, а для продюсеров, которые, открывая ваш документ, должны мгновенно понять, что у них в руках. И заодно понять, не лажанулись ли вы с позиционированием и своими возможностями.

Базовый геймплей

Необходимо выделить для себя, какая часть игры у вас является базовой, то есть, в чём игрок будет проводить больше всего времени. Например, в нашумевшей Gardenscapes игрок в основном играет в match-3, хоть это и не подчёркивается. Там создатели делают упор на обустройство сада, а match-3 как бы второстепенное занятие, служащее для зарабатывания звёзд. Но на самом деле в этом разделе нужно описывать именно его.

Для Wolfenstein это прежде всего ходьба и стрельба. В этот раздел стоит включить и управление базовым геймплеем. Смотреть мышкой, ходить вперёд-назад-влево-вправо, стрелять на левую кнопку, на три кнопки забиндить скиллы, а ещё одна — ульта, при попадании по персонажу у него отнимаются жизни, потом респаун и так далее.

На этом этапе часто встаёт вопрос: как структурировать написанное так, чтобы программисту его было легко читать. Перепробовав множество разных вариантов, я пришел к выводу, что лучше всего поступить так: в каждом разделе использовать свою нумерацию с иерархией. То есть, пишете утверждение. Под следующим номером другое утверждение. Если у вас есть уточнение или дополнение к основному утверждению, то переходите на один уровень вглубь и пишите там. Например: 1. Персонаж двигается в изометрии при помощи WASD. 1.1 Если игрок направляет персонажа в стену, тот останавливается при столкновении со стеной. 2. При нажатии на ЛКМ игрок стреляет. И так далее.

Важно описать всё не красиво, а точно, не упустив ни малейшего аспекта. Баг, сделанный программистом, чинится им же в ограниченное время. Дизайнерский баг (непродуманный момент) может разом перечеркнуть многие месяцы работы команды. «Не ошибается тот, кто ничего не делает» — отличная фраза для такой ситуации, потому что не реально предусмотреть всё, но одно дело не продумать один экран, а совсем другое — ошибка в базовой механике, из-за которой всё неиграбельно.

В первые три-четыре года работы геймдизайнером и в первые три-четыре месяца на новом рабочем месте вы обязаны подружиться с лидом программистов, чтобы скидывать ему свеженаписанные ТЗ с вопросом: «Нормально?». Это значительно повышает их качество и снижает время, потраченное на разбирательства.

На минутку вернувшись к теме хорошего геймдизайнера, могу сказать, что он ежесекундно должен ставить себя на место других людей и задавать себе вопросы: «Что мне понятно из этого экрана?», «Что будет понятно обычному геймеру?», «Куда бы я нажал, если бы открыл это меню в первый раз?», «Как может человек интерпретировать эту иконку?» и ещё около миллиарда таких же. Главный же вопрос гейм-дизайнера (если уходить в дебри) это «Почему?» . От «Почему PUBG такой популярный?» до «Почему эта фича, которую я придумал, будет востребованной?».

HUD или интерфейс базовой игры

Head-up display — вся информация, которую видит человек, играя в шутер от первого лица. Здоровье, патроны, маркеры на экране и тому подобное. В других жанрах его аналог можно называть по-разному, но в любом случае это то, что видит игрок во время базового геймплея. Это одна из самых важных вещей в игре — игрок должен понимать то, во что играет, но при этом оно не должно отвлекать его от геймплея.

На самом деле искусство создания хорошего HUD — это огромная наука, специалистов в которой очень мало. Лучше всего составлять его совместно с арт лидом и быть готовым, что переделывать его наверняка придётся.

Интерфейсы и главное меню

Этот раздел статьи я хочу начать с рассказа о том, что такое мокап. Или варфрейм. В индустрии очень часто одни и те же сущности в разных студиях называются по-разному и если у вас что-то из того, что я называю в статье, называли по-другому — это проблема отсутствия единого профессионального словаря. Итак, это — схематичный набросок, сделанный в графическом редакторе человеком, максимально далёким от рисования. Здесь не стоит задача сделать красиво, здесь стоит задача сделать понятно. Чтобы художник без лишних вопросов гармонично расставил кнопки и всё остальное.

Лично я для этого использую программу Pencil Project, но вы вольны выбирать всё, что угодно. Хоть карандашом на бумаге рисовать и фотографировать. Вместо картинок — прямоугольники, кружочки, стрелки. Минимализм.

Теперь о том, что этими самыми программами мы будем рисовать. Начать лучше всего со схемы экранов. Возьмите все ваши экраны и окна и разложите на экране. Проведите стрелочки: откуда куда игрок может переходить. Это своего рода интерфейсное оглавление, которое поможет собирать проект.

Типичная схема. Если постараться, то несложно её разобрать в отрыве от ГДД

Дальше идут мокапы всех окон, начиная с главного меню, и заканчивая самым маленьким окошком с кнопкой «Ок» . Не забывайте про то, как из них выходить! Под каждым мокапом должно быть краткое и понятное описание каждой кнопки и другого элемента окна и что они делают. Лайфхак для сложных экранов: возле каждого элемента поставить кружок с числом, а снизу пронумерованные пункты.

Когда художник отрисует это окно, рекомендую наложить эти же кружочки на его рисунок и подменить его в ГДД. Это поддерживает актуальность и понятность, особенно если в процессе отрисовки что-то изменилось, например, положение кнопок.

Мой мокап для замороженной игры про кулинарию. За референт бралось меню Clash Royale

Остальные фичи

Дальше мы просто бьём проект на мелкие составляющие и описываем каждый в своём разделе. Туториал, инвентарь, диалоги, глобальная карта, прокачка — всё, что у вас есть. Описывается всё так же, как и базовый геймплей. К каждой из фич в раздел стоит запихнуть мокап того, что с ней связано.

Функциональные разделы

В конце ГДД можно вставить несколько разделов, которые являются очень полезными для некоторых жанров.

Балансировка — описание того способа, которым гд будет балансировать игру. Нужен практически для всех игр, особенно f2p. Оптимальным вариантом для меня является xml-файл, который конвертится и заливается по специальному адресу. Потенциально ужасный вариант — веб-интерфейс, в котором каждый параметр нужно вводить ручками.

Админка — возможность банить и поощрять пользователей через веб-интерфейс. Необходима для он-лайн игр.

Сбор статистики — жизненно необходимая вещь для f2p. Перечислить все точки сбора статистики и формат её получения.

Minimum Value Product или MVP — описание минимально играбельной версии, которую можно выложить на общий доступ, чтобы проверить, насколько ваш базовый геймплей востребован. Необходимо если вы делаете f2p и придумали оригинальный геймплей.

Чего НЕ должно быть в ГДД?

Прежде всего — описаний анимаций. Это самая частая ошибка новичков. Называйте действия конкретно: «Пушка стреляет». Да, у вас мультяшный стиль и пушка перед выстрелом надувается, будто тужится — всё это не важно программисту, а аниматор лучше вас знает особенности движка и как сделать всё атмосферно. А пожелания лучше передавать ему лично.

Референсов. Картинки делают файлы неподъёмно большими, а те в свою очередь уменьшают их размер, поэтому их лучше заливать в папку на дропбокс, свн или гугл диск. Отдельную папку для каждой сущности, естественно. Видео лучше заливать на ютуб и давать прямые ссылки.

Текстов. Выделите под них отдельный файл, желательно xml, чтобы программисты легко могли подтянуть его прямо в игру. А потом его же будете локализовывать.

Литературных описаний — никто не оценит.

А что дальше?

После того, как вы написали все ТЗ и лид программистов уверенно сказал «Нормально», вы переходите на главную часть работы геймдизайнера — коммуникации. Если эта статья вам понравится, то я напишу ещё одну — как правильно выдавать работу разным специалистам и принимать результаты.

Не забывайте, что всё, описанное в этой статье — не нормативы (хотя если вы заберёте их себе и сделаете нормативами — я против не буду), а результат моей многолетней работы на позиции геймдизайнера. Никто не мешает вам сделать лучше.

#опыт #геймдизайн

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Serj Nilov", "author_type": "self", "tags": ["\u043e\u043f\u044b\u0442","\u0433\u0435\u0439\u043c\u0434\u0438\u0437\u0430\u0439\u043d"], "comments": 35, "likes": 79, "favorites": 86, "is_advertisement": false, "subsite_label": "gamedev", "id": 13891, "is_wide": false, "is_ugc": true, "date": "Thu, 21 Dec 2017 18:39:00 +0300" }
{ "id": 13891, "author_id": 956, "diff_limit": 1000, "urls": {"diff":"\/comments\/13891\/get","add":"\/comments\/13891\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/13891"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 64954 }

35 комментариев 35 комм.

Популярные

По порядку

Написать комментарий...
21

Прежде, чем начать рассказывать правила составления ГДД

Надо объяснить, что такое ГДД

Ответить
6

Гейм-дизайнерский документ

Ответить
0

Спасибо что пояснили, а то выебываются тут всякие.

Ответить
5

Чсх никто так и не ответил на вопрос. Это диздок.

Ответить
–16

Если вы не знаете этого - что вы делаете в индустрии?

Ответить
18

Я тут новости про игровую индустрию читаю.
Если я вижу статью то я, как читатель, должен хотя бы примерно понимать о чем она - и в этом задача автора.
Вопрос - что проще - поставить к коментарию читателя минус или при первом упоминании ГДД написать в скобочках что это значит.

Ответить
11

Не знает, что такое ГДД

Я тут новости про игровую индустрию читаю.

Господа владельцы и редакторы, вот видите до чего вы DTF довели? А вам говорили! Дальше будет только хуже!

Ответить
9

Прошу прощения, но с чего я должен знать что такое ГДД и в чем проблема того, что я читаю тут новости и комментирую их?
Что такое DTF

DTF — это платформа для обсуждения игр, кино, разработки и технологий. У площадки нет консолидированной позиции, здесь собираются люди с разными мнениями и взглядами на одни и те же продукты развлекательной индустрии.

Я просто увидел статью (даже не в Gamedev, хотя это сути не меняло бы), захотел с ней ознакомиться, не понял о чем она и поинтересовался у автора, ибо по моему мнению не указывать расшифровку слова, вокруг которого строится статья, это недочет.
И что я получил в ответ? Сплошной негатив.
вот видите до чего вы DTF довели

Ответить
5

Дтф больше хочет быть котакой, чем гамасутрой. ¯\_(ツ)_/¯

Ответить
0

нужен свой путь

Ответить
0

А история вообще знает хоть один "свой путь", который в итоге оказался чем-то путным?

Ответить
1

У Джобса вроде был свой путь...

Ответить
0

Я от него не в восторге, но, пожалуй, был.

Ответить
1

Сергей Брин, Илон Маск

Ответить
0

У когото когдато 100% был свой путь

Ответить
0

у одного еще и своя борьба была

Ответить
0

Там всё расписано и как раз ДО того, как рассказывается, как его писать

Ответить
0

Это раздел Gamedev?

Ответить
0

Не успели перенести ещё

Ответить
0

У меня для вас есть блестящее дизайнерское решение без опыта работы. Вместо того чтобы дуть проблему, могли просто и лаконично ответить на вопрос читателя. К тому же ваша статья не в разделе Gemedev. И верным будет ГДД называть ИДД- Игровым Дизайнерским Документом. Слово "Гейм" пока не совсем англицизм и вы торопите с этим событием.
"В первые три-четыре года работы гд и в первые три-четыре месяца на новом рабочем месте вы обязаны подружиться с лидом программистов, чтобы скидывать ему свеженаписанные ТЗ с вопросом “Норм?”. Это значительно повышает их качество и снижает время, потраченное на разбирательства."

Это дизайнерское решение судя по всему так и осталось на бумаге? Коммент норм?)))

Ответить
7

По схеме "полностью описали ТЗ" - "сделали игру с нуля и до конца" не работает никто. Никакой план не выживает столкновения с неприятием. Никакое ТЗ не выживает его реализации (если, конечно, нет задачи сделать полную хуйню).

Чем точнее вы пишете - тем больше потом придётся переписывать, тем больше вы переписать забудете. Чем дальше на будущее, в планах разработки, вы пишете - тем больше из того, вы пишете, будет к этому будущему моменту уже не актуально.

Большая часть этой статьи должна была бы быть посвящена не тому, как писать, а тому, как обновлять и легко детектировать ТЗ, которые уже не актуальны.

Ответить
0

Вы бы дополнили статью своими рекомендациями по обновлению и ревизиям диздока - многие бы вам спасибо сказали.

Ответить
4

Вот мой доклад с КРИ 2010 года (название не моё, если что)

http://dailytelefrag.ru/event_gallery/show_file.php?file_id=45672

PDF слайдов раньше был здесь, но DTF его съел: http://www.dailytelefrag.com/blog/read.php?id=60012

Ответить
2

Аудио, конечно, оставляет желать лучшего. Я пофиксил немного, так что теперь более-менее разборчиво.
Может кому будет пригодится: https://1drv.ms/u/s!Aha1MefQfcfGi1t1M0D2zr3aQb_v
(окошко в авторизацией можно просто закрыть, оно не обязательно)

Ответить
0

Спасибо :) Я, должен признаться, никогда эту аудио-запись не слушал, и узнал о её существовании только когда погуглил в ответ на этот комментарий

Ответить
0

А где-нибудь в закромах hdd у вас pdf-слайды, случайно, не остались? А то одно аудио как-то грустно :)

Ответить
5

1.Тут не все из области разработки, и аббревиатуру лучше расшифровать.
2. ГДД в первый раз вообще слышу, на сколько я знаю его все называют диздок (дизайн-документ).
3. ГДД похожа на отсебятину.

Ответить
1

ГДД - это калька с английского названия Game-Design Document

Ответить
3

Сейчас я скукожу вышеописанное. Чтобы тебя абсолютно точно поняла команда, берёшь пишешь диздок, да так, чтобы тебя даже детсадовец понял. Потом, сжимаешь центр мира в одной точке и садишься на неё. Несколько месяцев твоей жизни, уходят на прототипирование, конец.

Ответить
1

Никак не могу отвыкнуть от восприятия слова "мокап" в качестве Motion Capture...
Про Asana ни слова не сказано. По-моему неплохой инструмент по управлению проектом.

Ответить
0

Как я и говорил, омонимов в индустрии тонна) Асану не встречал, судить не могу.

Ответить
1

Спасибо, интересная точка зрения на Design Document. Не со всеми тезисами согласен, но в целом довольно обоснованно.

Ответить

0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-250597-0", "render_to": "inpage_VI-250597-0-1134314964", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=clmf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudo", "p2": "ftjf" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvc" } } } ]
10 самых лучших блюд
(согласно инстаграму Хидео Кодзимы)
Подписаться на push-уведомления