Нужны ли GDD при разработке игр?

Кто такой геймдизайнер?

На это есть несколько мнений. В какой-то мере каждый становится геймдизайнером когда начинает работать над игрой - это Мнение Джесси Шелла

С другой стороны геймдизайнер по мнению Тима Кейна - это тот кто способен довести идею до финала, описать ее реализацию, что бы всем было понятно. Кто является настоящим автором идеи? Тот кто первый ее высказал? Тот кто ее разложил и расписал? Или тот кто реализовал ее в коде?

Ну и конечно добавим мнение такого мастодонта как Ричард Гэрриот:

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

Сегодня мы поговорим о планировании. Как то что что любой корабль нуждается в ориентирах, строитель в чертеже, а основа живописи - рисунок. Так и основой игр - является дизайнерский документ.

Я концепт-художник и смотря на повальную некомпетентность в плане создания игр у кучи студий - хочу заявить:

"Может я не очень хорошо понимаю - как это делается. Но уж точно получше чем эти ребята." (с) Подвинься Джеймс Кэмерон - теперь это моя цитата.

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

И я поделюсь с вами наработками по ведению созданию игр и в частности ведения GDD, и порядок создания - от игры до проработки фич. Собранными на основе анализа кучи материалов, интервью и собственного опыта работы в студиях. Разбавлю шутками, ссылками и всем таким, а так же картинками. Все как вы любите. Или нет?

Когда вы поймете что именно вы делаете - вы обретете власть над игрой и будете направлять геймплей в нужную сторону, а не надеяться на "магию биовэр", "магию близзард" или "магию Бетезда". Так вы сможете применять в геймплее разные сочетания не меняя курса.

Соглашаться или нет - ваше дело, но нам точно будет что обсудить.

Причина данной заметки в том что за последние годы стало очень популярно мнение что в "Великие игры играют, а не делают", что создание игры не должно сопровождаться ведением какой-либо документации, ибо документация - это скучно или устарело и больше не нужно в современном геймдеве.

Для меня это такая же дикость как пропускать этап Рисунка и сразу переходить к рендеру финального живописного дизайна.

Поэтому давайте зададимся вопросом: когда GDD нужен и когда не нужен. И что в нем должно лежать? Что же должен по итогу сделать тот кто возьмет на себя роль Геймдизайнера?

Но сначала...

Нет ни одного волшебного средства, и GDD тоже ими не являются. Игры это искусство - и всегда будут исключения.

Поэтому ответ конечно: Можно, но поверьте - оно того явно не стоит.

Без GDD вы вероятнее всего получите проект - который будет:

А если вдруг вам повезет - то...

Вы все видели эти проекты. Это больше похоже на безумную готовку чего-то сложного без рецепта:

Кто знает что вам удастся создать при таком подходе, но я то говорю о контроле на творческом процессе!

Поэтому рассмотрим случаи когда обойтись без GDD можно весьма без болезненно.

Так что разобравшись с тем что отказ от GDD - это вероятно не та идея которая приведет легким путем к шедевру. К тому же та идея что круто звучит в голове - не факт что будет крутой при записи на бумагу. А значит над ней нужно еще поработать.

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

Перейдем к тому что...

Ну... это набор документов, Схем, теста, а еще:

GDD- это чертеж

Это ваша документация по проекту. План создания игры и одновременно отчет о проделанной работе и выбранных направлениях и решениях в создании игры.

Конкретный вид ГДД может различаться от человека к человеку - и от компании к компании. Но главное свойство документации - что она должна давать ответ "какой планируется игра" - что бы не было разночтений и прочие кулстори про лебедя рака и щуку.

Нужно понимать что ГДД - это ЖИВОЙ документ который будет меняться со временем, и будет включать в себя не только созданные решения, но и планы и отброшенные результаты. ГДД - это прошлое настоящие и будущие. По нему можно восстановить процесс работы над проектом.

В качестве занятного курьеза можно вспомнить того же Сталкера от GSC - где ГДД так сильно опережала возможности разработчиков так сильно, что уже после выхода игры модмейкеры пытались на основе слитой сюжетной ГДД по изначальным задумкам восстановить ТОГО_САМОГО_СТАЛКЕРА™ который Григорович нам обещал, — но так и не дал.

Так же стоит отметить что GDD - это техническая литература - ине стоит пускаться в графоманию, разведение воды и наполнение текста тем, что не нужно для создания игры.

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

(Хотя кто вас знает - вон в Алан Вейке 2 целая рок опера в игре, проект все еще не окупился)

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

Не нужно бояться писать некрасиво. Нужно бояться писать непонятно.

GDD - это кристаллизованная мысль

Записывание документов - позволяет структурировать собственные мысли и идеи.(чем я тут и занимаюсь, это больше для меня) Если записанная в виде текста идея/мысль/механика - не выглядит крутой и достойной воплощения - значит над ней нужно поработать побольше.

Мысль в виде текста - позволяет гораздо проще увидеть свои ошибке.

В индустрии и так хватает людей, которые не могут связать двух слов на должностях, дизайнеров.

А ведь будем честны - это еще не самый плохой вариант - бывают и типы с синдромом Туррета при попытке высказать что-либо.

Мысль должна идти от общего к частному. Связывая выдаваемую информацию воедино единой нитью.

Возможно, что те кто боится писать полноценные GDDs, - просто бояться пустоты в своей душе и что им нечего сказать этому миру? И в глубине себя они думают: "А пусть игра сделается как-нибудь сама? А я постою рядом и буду считаться автором"

А не работать над собой, ведь....

GDD - это ответственность.

У каждого принятого решения - всегда есть человек ответственный за внесение информации и подачи ее.

Поэтому многие неуверенные в себе разработчики хотят ее всеми силами избежать. Они настолько не верят в себя - что от синдрома самозванца - становятся настоящими самозванцами буквально саботируя работу коллег. Тим кейн в своем видео Authority Without Responsibility (Власть без ответственности). Буквально описывает эту ситуацию.

Если какой-либо разработчик говорит что ГДД не нужны и/или устарели просто не хотят что бы с них могли спросить за качество игры. Еще наверное и критику слушать не захотят...

Ведь если вы предложили решение на его реализацию потратили время - то очевидно что смотреть и тыкать пальцем в вас будут коллеги. Но если задокументированного автора у решения нет, то вы как бы и не виноваты выйдете. Всегда можно соскочить сказав:
"я имел в виду другое!"
Если у игры нет диздока - виноват за принятые решения будет всегда кто-то другой: некомпетентный сотрудник, продюсер, начальник, издатель и нехватка времени.

GDD - это работа

Как работой художника - является арт, так и у программиста - код. Работой геймдизайнера - является "проектная документация", а не "игра". Игра - это уже результат действий ВСЕХ вместе. Геймдизайнер который не создает документацию - по сути и не работает. Так как всю его работу берут себе по сути программисты.

Да и коллеги результата его работы не видят и не чувствуют. Другие сотрудники студии - будут постоянно нервничать - так как просто не будут знать какое решение приятно и где его посмотреть.

Такие Ленивцы часто оправдываются что ведение GDD - означает ХАОС.

Но как говорил один умный мужик:

А именно пустой стол останется после вас - если вы не будете вести документацию.

Чем более качественная работа проведена - тем меньше риск что, что-то забудут или не доделают. Да и вообще люди склонны переоценивать свою память. Да и возникает вопрос - а чем такой ленивый гейм-дизайнер вообще планирует заниматься в студии?

Будет сам сидеть кодить прототипы или что хуже увидит свою роль в качестве всезнающего гуру - который будет выдавать умные мысли - а все остальные будут ему внимать? Смешно.

GDD - это Философия

В документации обязательно нужно проработать и философию подхода. Причем определится с концепцией о чем игра еще на ранней стадии:

Что в игре будет - и чего в ней быть ни в коем случае не должно.

Границы проекта. Размер. Что бы знать когда надо остановиться. Какой цикл вовлечения игрока и чем игрокам предполагается заниматься. Что бы не допустить появления ползучей нормальности и ползучего расширения.

Заранее определив границы проекта - это позволит избежать так называемого ползучего расширения из которого проект рискует быть НИКОГДА не законченным как Star Citizen Криса Робертса.

Серьезно - Freelancer они смогли доделать лишь когда Майкрософт выставила его на мороз, и Кристу осталась должность консультанта - а не главного управленца.

Ползучие расширение - это весьма неприятная практика когда запланированный размер контента в игре растет прямо пропорционально прошедшему времени, подобно раковой опухоли. Вместо работы над глубиной механики - нерадивые дизайнеры хотят удивить шириной контента. Такой проект рискует никогда не выйти, так как дизайнеры вместо проработки механики и дать в диздоке механику на аптечку с регенерацией HP, описав как она работает, — составляют список из сотен, с уникальным названием, и предысторией.

Если так уж планируете расширять игру на бесконечность-то лучше сразу определиться с границами, где начинается Минимально Готовый Продукт - который можно обозвать релизной версией 1.0 и начать готовить DLC, Expansion Set или внезапно переиздание для следующего года (привет ФИФА)

Другое неприятное явление - это creepy normals(смещение нормы)

Обычно источник этого люди которые внезапно неуместно фонтанируют идеями. И которые плохо будут вписываться в изначальную концепцию игры. Тимоти Кейн определял это как постепенное смешение того что является нормой для сеттинга. И что за это нужно бить по рукам. Это как в Скайриме приземлится НЛО и начнется сценарий войны с инопланетянами. Ну а что!? Ведь инопланетяне круто! Или в Фоллаут добавят магию. Или в Аркануме появится способ соединить магию и технологию и нивелировать штраф на несовместимость путей.

Из-за смещения понятия "нормы" - игра может потерять свою идентичность.

Тим рассказал что добавить "призраков" в фоллаут было его решением. И сейчас он понимает что это была ошибка. Ведь если есть призраки, то возможно в рамках айпи есть и вампиры и некроманты? А ангелы и демоны?! Нет. Список этих сущностей нужно определить сразу.

GDD - это самая дешевая (и быстрая) замена телепатии (инфа 100%)

Даже если вы планируете делать игру в одиночку - то никто не даст гарантию что в какой-то момент не придется расширяться и давать задачи аутсорсерам, так что наличие структурированных заметок - самый быстрый способ объяснить что же именно сделано, как и что нужно доделать.

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

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

Большинство людей читают текст в разы быстрее чем это воспринимается на слух. Серьезно! Исследования показывают что во многих приключенческих играх - игроки часто пропускают диалоги не дожидаясь окончания аудиодорожки. Почему? Потому что уже прочитали субтитры - а мозг дополнил информацию, так зачем ждать?

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

Что бы найти тут какую то часть - вам достаточно прокрутить текст вверх или вниз и зацепится за нужное ключевое слово или смешную картинку, которая была вставлена не просто так (Добавьте в Диздок картинок, не обязательно смешных иллюстрации хорошо разбавляют монотонный текст)

Даже если коллеги не будут читать ВЕСЬ документ (а они, спойлер: и не будут) - они все равно будут читать ту часть что относится непосредственно к их зоне ответственности. Если нужно сделать какую – конкретную часть механизма - то всегда полезно взглянуть как он должен выглядеть если не целиком, то хотя бы понимать как игровые системы будут соединяться в смежных местах стыка

Так же стоит отметить - что коллеги не будут читать и те материалы - которые могут залезать в чужую зону ответственности, если у вас нет компетенции в этом. Если в GDD описаны персонаж и расписан с точностью до мельчайшего элемента одежды - это по сути мусорный материал, который будет вероятно выкинут еще при первой попытке нарисовать этого персонажа. Как говорит мой опыт работы - для дизайна персонажа достаточно расписать функцию персонажа, и возможно 1-2 референс из масс культуры. А дальше с этими вводными будет работать арт отдел своим путем.

Не давайте советов художникам - если вы сами не можете рисовать.

Большинство людей - увы склонны переоценивать качество своей фантазии. Ваша фантазия эффективна настолько - насколько эффективно способны в реализацию. Это во многом касается и GDD как такового. Описывать сможете то что доступно вашему пониманию. А если вдруг не понимаете, то стоит в этом разобраться подробнее и провести исследование...

GDD - это контроль

И хоть творческий хаос это забавно, контроль над проектом повышает шансы, что вы его доведете до финала в том или ином виде. GDD - позволяет контролировать объемы игры наглядно. Диздок это самый простой из доступных способов создания планов работ, организации проекта, и поиска ошибок в игре. Да и просто способ не перегружать голову сложным проектом - а выгрузить значительную часть наработок на бумагу.

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

В общем случае - можно разделить на две большие группы: внешнее диздоки для контрагентов и внутренние - для собственного пользования.

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

Так что перейдем к ...

Внутренний GDD - Это скорее всего СЕРИЯ документов - образующих вертикальную пирамидо-подобную иерархию. От изначальной идеи к конкретным механикам.

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

А для арт отдела - будет "арт-гид" по правилам создания арта, если будет использоваться специфичный стиль, наборы референсов и соглашение о наименовании 3д моделей - что бы из них можно было собрать мир игры.

Так же со временем появятся всякие способы ведения способы учета затраченной работы вроде Jira или иных tasktrackers. И всякие документы планов работ которыми будут размечать пройденный путь: milestone и Roadmap для планирования.

Процесс разработки Игр стандартно делиться на 3 больших этапа:

Пре продакшн, Продакшн и Пост продакшн.

Теперь когда мы с этим разобрались. Поговорим про то что должно содержать GDD.

Правильный ответ - на родном.

Даже если вы работаете в международной команде - то начинать все равно нужно на родном - и после уже потом делать перевод, когда определитесь с механиками и описанием.

Не пытайтесь решать две задачи за раз. Мамонта нужно есть по частям, не нужно его глотать. Это не удобно.

Попытка прыгнуть выше головы - и сразу выдавать готовый результат на международном английском будет затруднять работу головы. Люди не самые многозадачные существа. Для начала нужно научится делать все на понятном языке.

Я лично был свидетелем - когда попытка писать сразу на международном - привела к тому что геймдизайнеры буквально провалили пару майлстоунов. После чего было принято решение разделить работу с GDD на разыне этапы на разных языках На русском на котором работают 3.5 недели и 2-3 дня тратят на перевод готовых наработок для партнеров.

Правильный ответ: ГЛАВНОЕ ВЕСТИ.

В том чем будет удобно:

Каждый из вариантов может иметь свои минусы и плюсы.

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

World/Google документация - это самый простой из дешевых способов при распределенной команде. Доступный любому и везде. Начните на нем.

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

У вики -разметки есть один "не задокументированный" минус в том смысле - что некоторые разделы становятся мертвыми и об их существовании просто забывают. Когда на них ведет слишком мало гиперссылок. Чего на "цельном" документе - не случится, так как тема будет лежать во внутри своего раздела по порядку, а значит будет просматриваться чаще.

Люди чаще видят другие разделы когда листают цельный документ на 100 страниц, чем когда серфят вики. Поэтому даже если ведете вики разметку - всегда делайте сшитый воедино документ, распечатайте вики странички и сшейте. Та же ID Softwork печатала ПДФ "Библию дума" раз в несколько месяцев

Да и салфетки сгодятся - если идея пришла во время обеда в кафе. В конечном счете Тим Кейн расcказывал как после общения с одним продюсером ему пришлось переписывать информацию с десятка растрепанных салфеток. Так что лучше на них - чем никак - верно?

Из простых рекомендаций. Стоит разделять в рамках GDD. Справочные материалы - такие, как: Теазриус, Стандарты. От документа с механиками. А в документ с механиками не пихать таблицы баланса. Ну и конечно материалы по сценариям могут лежать отдельно.

Все! БУКВАОЛЬНО ВСЕ! В итоге финальный диздок должен содержать в себе ВСЮ информацию, что бы клон вашей игры могли соорудить по нему и без вас!
По крайне мере в идеале - GDD - это чертеж проекта. Будь игра домом - описанные логику, системы и фичи игры можно сравнить с ... электро и водопроводной сетью. Наличие чертежа - сильно упростит починку труб - если туалет прорвет.

С этим разобрались, а теперь поговорим про несколько принципов которыми нужно придерживаться что Диздок был Читаемым, и порядок наполнения.

Никто на самом деле не захочет читать ваши горы текста.

(Эй ребят вы еще тут? Напишите кто еще со мной!)

Если в нем нет аттракторов притягивающих взгляд. Или если это не легкая развлекательная литература при приключении в другом мире.

Нужно перебивки - добавлять схемы, чертежи, примерные вставки вариантов как будет выглядеть итоговый вариант.

И этого документа это Сюрприз тоже касается. Поэтому тут так много картинок, что бы настроить вас на нужный лад.

Вместо того что бы рассуждать о дизане того же интерфейса - лучше его набросать. Или дать скриншоты и примеры из других игр.

Пишите аккуратно. Предложение с описанием механик должно быть читаемыми и не быть размытый смысл. Если можно добиться картинкой или схемой-то совсем замечательно:

Что бы этого добиться:

Может показаться что это нечто обратное Лаконичности - но на самом деле это часть принципа диалектике. Единства и борьбы противоположности. Нам нужно писать лаконично, но подробно.

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

GDD - это живой документ - не нужно думать, что он будет не изменен. Не забывайте вносить принятые изменения и описывать причину изменений. Если новое решение заменило устаревшее.

GDD - каждого проекта может быть уникальный, содержать или не содержать в себе те или иные части. Да и процесс работы может идти индивидуально. Каждый проект будет вестись индивидуально. Каждая команда будет работать немного да по-разному. Но что-то общее всегда будет - и это грабли.

Можно ли использовать эту мега-заметку в качестве шаблона?

Да.

Если это кому-то поможет, - то это возможно сделает игры чуть лучше. Заставит задуматься о том - о чем ранее и не думали подумать.

...и нет. Почему нет?

Так каждый шаблон будет делать людей немного ленивыми.

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

Если не будете качать мозг - он не будет проращивать нейронные связи.

А у нас и так переизбыток ленивых геймдизайнеров.

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

Без решения задач самим - нейронных связей в мозгу не образуется, чтение любого материала не так эффективно, как "ПЕРЕСКАЗ"/ ПЕРЕЛОЖЕНИЕ. (как и этот материал хе-хе)

Так например очень сложно научится что-либо рисовать, занимаясь только рассмотрением объектов и субъектов и не берясь после этого за карандаш.

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

Не всю информацию можно сжать.

Да и процесс работы может вестись по-разному. Например, можно вести разработку от Сеттинга игры. А можно от заранее выбранных фич и механик. Рекомендую рассуждения Тима Кейна эту тему: "Designing Mechanics First"

В Тим Кейн говорит что всегда начинал разработку игры с ПРОРАБОТКИ сеттинга и ограничений им вы мы выставляемым. Но существуют кучи игр - где сначала придумывали фичу - и вокруг нее начинали наращивать мясо из других механик и ЛОРа.

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

Другой аспект о котором важно помнить, что GDD должен быть предельно функционален. В нем не нужно тратить неделю на то что возможно будет выкинуто в мусорку за 5 минут. Лучше нарисуйте схему на бумаге за пол часа карандашом, обведите маркером, сфотографируйте и вставьте в GDD

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

Другой важный аспект функциональности - что нужно убедиться что команда его понимает. А если не понимает... что же - тогда нужно учесть их пожелания и перевести документацию на понятный им язык.

Введите систему контроля версий. Это избавит от большой головной боли. Ничто так не де мотивирует творца - как безвозвратная потеря значительной части работы.

Ведь воссоздавать материал по памяти не так весело как создавать что-то с нуля.

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

⚠ Это сохранять документы в специальный архив(внешний HDD) перед началом работы с соответствующей датой.

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

Начать надо с той части что можно назвать ядром документации.

Первое, что нужно сделать - это задать главную идею игр.

Что, где, когда и зачем?!

Это что часто называют Питч - или Вижн документация. Иногда Concept Doc.

Иногда ее называют Продюсерская документация.

Это набор базовой идеи для игры:
Жанр, сеттинг, примерный список фич которыми она будет отличаться от конкурентов, список конкурентов тоже нужно приложить.

У этого документа всегда есть конкретный автор, который эту идею высказал и на чьем решении все будет держаться, это всегда лидер/продюсер/креативный/творческий директор - проекта.

Тим Кейн рекомендует создание Диздоков начинать с создания лозунга, который в одно предложение описывает концепцию игры.

Так для примера the outer worlds такой лозунг звучал следующим образом:

Во-первых, это коротко - а во вторых заставляет задумать и сразу сложить в голове нужный образ.

В целом же задача питча, как и лозунга, задать настроение, вызвать в головах сотрудников образ грядущего, настроить сотрудников на одну волну. Заставить сотрудников буквально мечтать в одном направлении.

Задать завязку, крючок для игрока, то на что мы будем его ловить.

Без этого документа соратники по создании игры - могут сделать несовпадающие куски. Которые вместе просто не будут работать:

Если по каким либо причинам Идея - поменялась. То лучше отложить устаревшие документы в архив и перепройтись по всей документации заново - копируя те куски что остались актуальны, и заменяя то что больше не нужно.

Описание базовой идеи очень важно что бы не размывать айпи, и в один прекрасный день не запутаться самому, имея понимание что и зачем вы делаете.

Пожалуй, помимо лозунга - стоит нарисовать и добавить в этот раздел какой-нибудь тематический арт который будет задавать общую атмосферу.

При придумывании списка Фич с кратким описанием - всегда думайте о будущем в жанре, ведь вам его развивать. Если же вы собираетесь сделать просто клон чего-то существующего... – то игра рискует просто не выстрелить.

И еще помните. Нам нужно устроить из игры ШОУ! Увлекательный процесс - найти чем завлечь игрока, отсылками к масскультуре, узнаваемым образам, мемам. Что бы он воскликнул.

"Я ради этого игру и купил!"

Даже если на самом деле в игре он получит совершенно другой контент.

Именно так и поступили Лариан - они завлекали к себе в БГ3 - ради клубнички и интересного шок контента! Но на само деле игроки получили неплохую пошаговую тактику. И им понравилось, игроки не были разочарованы... в отличие от сами знаете чего, что вышло месяц спустя.

И да лучше продумать меньшее число фичей, но будут более глубокими, Чем горы фич, но которые будут настолько поверхностны, что даже сами разработчики рискуют забыть о них через 5 минут после создания.

Запомните такте словосочестния как "Go into magic deeper, not wider", и "more is less", и "made to be ENJOYED, not ENDURED" и мы к ним еще вернемся, когда нибудь.

Идея это то что останется даже если игрок игру пройдет, и как знать возможно она же заставит его вернуться. Игры без идеи быстро теряют игроков. Игры с идеями - даже несмотря на плохой старт - могут стать признанными шедеврами спустя годы. Как Prey 2017 от Аркейн. Чем был Фортнайт без идеи королевской битвы? - Рядовой выживалкой.

И помните: Количество контента, реализм - это не идея.

Это могло и сработало только один раз - у крайтека в Crysis. Но с тех пор на первый крайзис без слез и не взглянешь.

Делайте ставку на СТИЛЬ. На то что зритель ранее никогда и не видел, или ... давно не видел ...

Задайте себе вопрос: "А что если...?
И ответьте на него через форму
Мы им покажем, дадим поучаствовать и почувствовать...."

Ведь именно для этого игры и существуют? Для того что бы погрузиться в вымышленные миры?! А тем кому мало реализма - могут выйти и потрогать траву.

Теперь пора перейти к фичам? Правильно?! Правильно же?!

НЕ ПРАВИЛЬНО! Сначала нужно разобраться с ....

Прежде чем переходить к тому что будет составлять саму игру - стоит сначала разобраться с устройством ввода со стороны игрока:

Будет ли это мышь и клавиатура, разные типы геймпадов, стики ВР шлема, Руль, Коврик для танцев и т д.

Выделить основные инструменты.

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

Кажется это просто - но если это не записать на видном месте,- то есть риск получить такую же позорную ситуацию как у того же Starfield - где во всех игровых меню разные кнопки навигации: в одном меню стрелки, в другом wasd.

Или попасть в ситуацию когда в фиче будет указана механика на которую просто не хватит кнопок на том же геиймпаде. И снова я о старфилд, где "рывок вперед" на ранце открывается лишь после того как вы в настройках поставите альтернативную кнопку для прыжка. А потом команда BGS не нашла ничего умнее чем скрыть функционал рывка вперед от игроков, что бы консольшикам хватало кнопок.

Другой важно особенностью что любой читающий диздок сможет взять в руки устройство или положить руку на клавиатуру - и самостоятельно проверить как придется много кнопок жать. Удобно ли это? Не занята конфигурация? Это можно сделать еще до появления первого рабочего прототипа.

Так же удобно разделить используемые кнопки - по "функционалу"

Если кнопка действия это "F", "Е" или "Enter" или "Пробел" - то проще это упомянуть в этом пункте. А не бегать по всему документу и переписывать в панике при изменении.

Стоит ли нам говорить о платформах? Несмотря на то, что многие указывают необходимость сразу указывать планируемую платформу - не думаю что в этом есть много смысла, если это конечно не мобильная игра.

Но если это питч издателям - добавьте их по максимум существующих. Если конечно у вас не жанр РТС.

Ведь кто знает насколько затянется разработка и будет ли консоль существовать к тому времени?

А современные движки позволяют сделать порт на нужную платформу буквально парой движений кнопок. Особенность современной разработки - что 90% разработки игры - проходит на ПК. Закидывать билд на девкит начинают когда игра по сути готова, осталось переставить циферки баланса и убрать критичные баги.

Где все что разработчику понадобится это подобрать "пресет" настроек графики - что бы он не тормозила на консоли. И перерисовать UI.

Другой важной особенностью которую стоит начать вести ПАРАЛЕЛЬНО с заполнением Диздока, это...

Это важный элемент GDD - но его лучше вынести в отдельный документ.

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

Главное, что появившись - их можно разъяснить. И пояснение этих терминов будет полезно для любых новичков которые рискуют присоединиться к команде на середине разработки.

Так же тут стоит добавить пополняемый раздел который можно назвать "соглашение об именовании", инструкцию как составлять и читать имена файлов для игры. Будь то 3д модули или Ассеты Звуков оружия, врагов, VFX и прочие.

Очень легко забыть что значит то или иное название файла, если вы к нему не притрагивались пару лет.

Так же сюда стоит перенести все самые важные термины по сеттингу игры. Которые будут напрямую касаться встречаемых фич в механиках. А все остальное можно вынести в отдельную LORE - Энциклопедию включающую карты мира, историю, бестиарий, генеалогию и все-все-все что можно придумать.

LORE - библиотека.

Это не только будет удобный поиск по непонятным терминам, но и важный(!) документ для локализаторов игры. Который позволит избежать кучи сложностей.

И теперь мы можем перейти к вкусным фичам? На самом деле снова нет, следом идут ...

Вопросы левелдизайна, а именно :

Это размеры, Высоты, и прочие предельные значения диапазонов стандартов Базовых элементов игры. Собственно это единственный общий Раздел GDD - где нужны цифры. Цифры относительно размеров персонажей. Благо тот же Unreal ныне позволяет задавать координаты не в абстрактных Unit ах - а в сантиметрах.

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

И помните - габариты из Реальности не всегда подойдут игре. Так как на мир игры мы смотрим через экран монитора.

Для игры от 1го/3го лица - рекомендую сделать:

И эти размеры лучше всего СРАЗУ проверить несколько раз в первом же прототипе уровня, что бы потом мучительно не страдать от неправильно выставленных значений.

Собственно на этом этапе можно уже переходить от составления диздоков к началу прототипирования. Что бы получить свой первый тестовый уровень на greybox'ах

Следующим важным пунктом в диздоке стоит отметить:

Тут в максимально упрошенном виде расписать как будет устроено строение игрового мира и переходы между локаций. Будет ли это открытый мир?

Или Набор линейных уровней? Или это хаб с кучей открываемых локаций?

Процедурная генерация? И все такие пояснения в этом роде.

Тут можно приложить первые наброски карты мира. Придумать названия для локаций, позже стоит добавить "описании фишки локации", когда раздел с фичами будет готов.

Так же стоит определиться с механиками перемещения - Будет ли тут транспорт, крюк кошка, дельтаплан или система телепортов?

Какие пазлы и типы боя предполагается на разных зонах и локациях?

Будут ли локации строится на различных механиках или у них будет своя фича, как багги или лодка в HL2?

Делаем тут все кратко. Так как механике и системы для всей этой красоты будет появляться и разрабатываться позже. Поэтому мы уже переходим к ним:

Но сначала определимся чем логика системы и механики отличается между собой.

Если логика работает ВСЕГДА - и в игре есть лишь моменты ограничивающие ее, по скрипту, то мы говорим о Глобальной СИСТЕМЫ.

К таким Глобальным Системам обычно относится - нечто вроде здоровья персонажа, инвентарь, системы квестов, репутации.

Иногда в роли таких глобальных систем могут выступать буквально ЖАНРЫ ИГРЫ - между которыми происходит переключение внутри игры. Так что можно видеть ... деление весьма условно.

Так в том же Ведьмаке 3м есть Гвинт, а в Космических Рейнджерах Доминаторы есть глобальная пошаговая РПГ, и быстрые аркадные бои и РТС и даже текстовые квесты. 4в 1. И все это системы.

На данном этапе нужно не бояться писать формулы внутрь систем и механик, но стараться не использовать конкретные цифры.

Если логика работает только ИНОГДА - то такую логику стоит назвать Механикой. В качестве примеров можно указать конкретную логику гравитационной - пушки в HL2, логику миниигр и взлома замков в Скайриме или конкретные наборы способности карт в Heartstone, перки и навыки в РПГ играх.

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

Дальше переходим к логике механик.

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

Например, эффекты магии и как они могут комбинироваться.

Или особенности поведения НПС.

Ловушки и эффекты на них.

Присваиваем тегу - описание. А затем собираем набросок механики из тегов, добавляя уже уникальную особенность механики.

Этот подход стимулирует создание модулей механик которые будут соединяться воедино.

Так же помимо тегов - нужно правильно структурировать элементы механики и систем - так что бы некоторые механики были частным случаем систем, и основывались на уже готовом коде.

Например, система взаимодействия инвентарей - может послужить основой для механик торговли, бартера и воровства. И всяких ФИЧ - вроде взаимодействия НПС со своим инвентарем через скрипты ИИ.

А на основе системы нанесения урона - сделать кучу механик РАЗНОГО оружия.

На этом можно сказать основная часть диздока законченна. Мы достигли места назначения на карте сокровищ. Теперь... Берем лопату и начинаем копать.

В смысле предстоит еще много тяжелой работы. Наконец можно приступать.

Да можно разделить механики по важности геймплейного лупа и тому как должны завлекать. Обсудить вопрос UI/UX интерфейса, но будем считать что это часть ЛОГИКИ игры как таковые.

Так что продолжим работ которую можно разделить на следующие итерационные этапы:

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

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

Дальше основная работа пойдет в" Балансной и справочной документации". Через которую будет дублироваться работа с наполнением игры.

Где будут описаны сущности, персонажи из игры и их циферки, статы и т д.

Названия звуков и ВФХ эффектов. Поверьте - это очень важно. Лучше не забывать.

Думаю лучше всего вести эту работу в ексель или хмл формате - настроив выгрузку оного из движка игры.

Но как именно балансировать игру?

Это уже зависит от философии и идеи.

Можно выкрутить все механики - что все в игре будет стремиться убить игрока и его персонажей. И возможно тогда вы найдете свою аудиторию.

Или наоборот что все должно максимально комфортно для игрока. И игрок каждые 10 минут получал новый предмет на 5% лучше предыдущего как в Дьяблойдах.

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

(Да я о старфилде, где мы выпал на 5м уровне автомат с перком "пробивание прочной брони" и "яд" и все - все НПС отлетали с одного 3х попаданий что 10м что на 70м уровне сложности.)

Или другой случай Роб Пардо, продюсер Близзард рассказывал что они стремились разбавить идеальный подбор игроков по ММР в SC2 так что бы каждые 2 матча из 10 были с соперником много сильнее и слабее игрока. Это будет вносить раскачивать эмоциональные качели у игрока. Увеличивая вовлечение в матчи 1х1.

И нужно умудриться по тонкому лезвию бритвы между двумя одинаково плохими вариантами: Скукой от идеального постоянного баланса, и полностью сломанной игрой без веселья.

А возможно поискать ошибку в реализации. Возможно идея недостаточно раскрыта? Проработана. Не задокументирована?

Переделки неизбежны, иногда идеи и механики - которые круто звучали в голове, и даже на бумаге - просто не работают в движке - тогда стоит сесть и подумать "почему"? Возможно стоит вставить более простую временную заглушку?

Но нет ничего более постоянного чем временное.

Все же в отличие от вопросов кито-молочной мобильной гача индустрии как правильно доить китов - настоящий геймдизайн в настоящее время во многом похож на фентезийную алхимию. Надеюсь он таким и останется. Все же получение Окончательного рецепта идеального геймплея было бы просто странным.

Как долго нужно вести тестирование и переделки?

До тех пор, пока магия игры не заработает. Увы это не всегда может совпасть с внешне навязанными сроками.

Как получить ту самую формулу успеха? Как суметь сделать то что что пошатнет мир и прославит в веках?

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

А значит - нужно пытаться снова и снова - и ... систематизировать получаемые результаты.

Будет ли настоящий результат труда геймдизайнера будет похож на трактат мага. Так что не каждый ученик чародея сможет прочесть заклинания из него, требующего долгой подготовки для чтения. Или будет подобен волшебному манускрипту - который даже слабому одаренному выдающуюся мощь?

Взять ту же компанию Лариан - они смогли сотворить то что все остальные студии назвали "Аномалией".

Оживить казалось бы давно умерший жанр, да так что взяли сходу игру Года.

Так что - в искусстве нет "правильного и не правильного" - есть лишь магия творчества. Даже сделав все как казалось бы "правильно" - можно провалится потому что в целом проект не будет работать, потому это работает у кого то другого, но не у тебя. И пока тот творец не сломается - его место никто занять не сможет.

И наоборот из говна и палок - можно прорастить эдемский сад. Используя говно как удобрения, а палки как саженцы.

Весь вопрос во вкладе труда, таланта и души.

Это все? Спойлер: нет.

Есть еще то о чем стоит поговорить. Но не знаю к какой части GDD это нужно добавить и положить. К фичам? К системам? Добавлять к механикам.
В общем это интересные приемы которые нужно знать и возможно применять в том или ином виде:

GDD зачастую будут заполнять и редактировать разные люди. Многие шедевры строились на том что поощряли креатив в студии, при условии что люди потом они сами будут отвечать за результат.

Есть горы примеров когда в игры вносились значительные изменения делавшие их лучше. Не со стороны руководства. А со стороны работников. Так появились текстовые квесты в космических рейнджерах, Черный предел в скайриме, рамка выделения юнитов в Варкрафте, обзор армии союзников в АОЕ(тогда это была инновация) и много - многое прочие:

И что бы не было споров и скандалов - нужно указывать кто автор фичи/механики/идеи. Как на уровне человека который настоял на внедрение той или иной фичи, так и на уровне реализации.

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

Об этом опять же хорошо рассказывал Тим в ролике "Власть без ответственности"

Если идея удастся - то Чайка ВСЕМ-ВСЕМ расскажет что именно она была автором этой гениальной идеи.

А если провалится - то будет молчать. Просто не скажет что у этой гениальной идеи: "есть: имя, фамилия и должность".

Лучше сразу отметить - что бы знать кого хвалить или стыдить.

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

И даже если этим эффективным "чайкам" отказать - то они попытаются заставить работников сделать это втихую.

И даже если начальство - чайка заставит его реализовывать идеи чайки - то после прохождения через его руки - это будет УЖЕ ЕГО ИДЕЯ. Ведь и спрашивать за реализацию будут с него. Но все равно указать какой путь прошла идея и кто автор будет полезно.

Тим так же в своих роликах упоминал смешной случай когда он коллегой геймдизайнером начали спорить чья же это была крутая идея, подняли архивы - и оказалось что ни один из них. Автором был программист Боб - который просто присылал техдокументацию на согласование им обоим.

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

Играйте в чужие игры. Хорошие и плохие. Новые и старые. Но не делайте обзоры на них, исследуйте механики. Делайте конспекты того что вам интересно или нужно по работе при разработках механики.

Вдохновение - важная часть. Мы стоим на плечах гигантов. И если повезет сами станем тем кирпичом на долгом пути истории, служа вдохновением для остальных.

Поиграли в игру?

А теперь поиграйте еще раз - выпишите те аспекты что сделаны хорошо, те что сделаны плохо. Подумайте какими средствами это можно улучшить/исправить?

Чем больше у вас материала - тем лучше для вас. Препарируйте. Попытайте извлечь из нее эссенцию того что можно назвать "душей". Предложите варианты как улучшить ту или иную механику. Смотрите выступления авторов интересных вам игр на GDC и других конференциях. Прочили материал который вам нужен в работе? Конспектируйте. Когда вы что-либо записываете - мозг активируется гораздо сильнее прокладывая больше связей между нейрончиками.

Как говорится:

"Учится можно только на ошибках - учитесь пока я преподаю!"

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

Так же хорошим советом - будет завести блокнот/гугл документы - куда будете записывать все свои мысли и идеи на тему геймдизайном.

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

Прежде чем гуглить решение - подумайте сами

Для развития мозга - полезно сначала поломать свой мозг самостоятельно прежде чем идти гуглить готовое решение. Это как раз то что стимулирует развитие. Подумайте над темой пол часа или час. Систематизируйте все что у вас есть в голове. Выпишите те трудные вопросы и темы с которыми надо поработать.

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

Но и игнорировать чужой опыт тоже нельзя - ведь именно для разработчиков все эти конференции GDC и проводятся. Пишутся инструкции и статьи, такие как эта.

Один из самых интересных советов, что я встречал по ведению GDD документации - это создание мысленного прохождения своей игры с последующей записью оного. Простая идея? Так почему мало кто ее воплощает в реальность?

Всего-то писать фантазию о том как должен идти игровой процесс. Сделать Эссе (сочинение) по этому поводу.

Буквально описать пошаговое руководство по игре на небольшом участке - с описанием шагов игрового процесса. Если хватает навыков - сделать буквально РАСКАДРОВКУ. Да да, она может пригодиться не только для фильмов: Например, ее советуют делать в Нинтендо:

Хотя из забавного - раскадровки рисуют даже для UI/UX приложений

В частности это советовал Рик Гудман (создатель AOE) - я уже приводил эти советы ранее в «Десять заповедей создания RTS» и история разработки Age of Empires и они звучит так:

Написать хороший проектный документ может каждый, но помимо этого для хорошего результата и отделения хороших идей важны еще четыре момента:

Нужно чаще прислушиваться советам коллег и людей которым не все равно на игровой жанр и создаваемую игру. Так же неплохо найти в команду специалиста знатока того жанра в котором будете работать. Постоянно держа в уме, что: «со стороны всегда виднее ошибки», а не кричать всем: «Я гений и я непогрешим!».

Интересные материалы по теме:

Библия Дума

PDF файл - содержащий в себе часть реальной GDD документации по игре тех лет.

От Ноября 1992го года.

Вы наверное и не знали что изначально в думе планировались разные персонажи со своими именами и способностями, думаете Героические шутеры это новая идея? Хаха

SCRIPT IT(Пиши это!)

Инструкция в виде комикса по созданию идей, сюжетов и привлечению аудитории

Арт Гид Valve

На примере персонажей ДОТЫ2. Пример для арт директоров как должен собираться арт гид:

Очень хороший материал разбирающий тему в течение часа c чем то. думаю материала поменьше чем у меня, зато в картинках и наглядно.

Тим Кейн из Интерплей/ТройкаГеймз/Обсидиан - который на своем канале делиться кучей информации о процессах работы. Рекомендую весь канал целиком.

Вот видео непосредственно о GDD. На 15 минут

Шаблон GDD предлагаемый от Unity

А теперь наметив как должен идти процесс разработки - можно приступать к созданию игры мечты.

#gamedev #документация #разработкаигры