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

«Мне кажется, многие гейм-дизайнеры реально отстойно делают свою работу»

Ричард Гэрриот, Лорд Бритиш, Создатель Ultima

Вместо введения. Начнем издалека.

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

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

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

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

Джесси Шелл

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

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

Я слышал что мои коллеги их называют "Чайками"("seagulls" - в оригинале), потому что они прилетают, гадят на ваш стол идеями и улетают. Думая что на этом работа над геймдизаном закончена.

А уж что "Чайки" думают о других "Чайках" - ох! Это могло бы стать отдельным веселым и безумным обсуждением.

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

А он в ответ: "Я не знаю. Идея только пришла, я еще не успел обдумать"

Или если это менеджер: "Так ведь это уже твоя работа!"

И так происходит сплошь и рядом.

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

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

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

Лорд Бритиш, по документам Ричард Гэрриот

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

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

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

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

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

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

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

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

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

(но лучше все же согласится, я ни на что не намекаю, но..)
(но лучше все же согласится, я ни на что не намекаю, но..)

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

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

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

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

Можно ли обойтись без GDDs ?

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

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

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

  • Прост и скучен
  • Сам не знает чем, хочет быть.
  • Игра будет содержать механики которое будут использоваться считанное число раз в течение геймплея.
  • Сырой настолько, что будь он бифштексом, его можно было бы охарактеризовать: "Еще бегает".

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

  • Никто в студии не будет понимать ЧТО именно в игре позволило добиться этого эффекта. И как их повторить.

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

В конце будет ссылка на полный комикс - дочитаете - получите ее :D
В конце будет ссылка на полный комикс - дочитаете - получите ее :D

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

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

  • Ваш проект очень маленький - и вы всю информацию удержите в голове
  • Вы гений с идеальной памятью и все делаете в одиночку - Как Сид Мейер, Тогда ваша GDD будет просто хранится внутри вас.
  • Вы делаете лобовой клон или реместер/ремейк существующей игры - тогда в роли GDD будет выступать сама оригинальная игра.
  • Ваша новая игра - это незначительная модификация существующей (см FIFA от EA) - где механика давно отработана - и новые версии меняются только в плане замены надписи с 2023 на 2024, улучшения графики и паков доступных футболистов.
  • Вы собираетесь собрать проект из чужих ассетов - и изменения, которые можете внести будут минимальны. В таком случае полноценной GDD не нужно и можно обойтись только документами с сеттингом и сюжетом.
    (Пример: вы думали тут будет Смута? Хах лучше взгляните на - Fallout New Vegas)
  • Имеем дело с вырожденным жанром игр. Пример такого: Визуальные Новеллы и Симуляторы пешей хотьбы. В таком случае вам важен будет только сценарий - но технический документ по механикам.

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

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

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

Что такое GDD?

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

GDD- это чертеж

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

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

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

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

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

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

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

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

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

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

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

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

Когда-нибудь этот кристаллид вырастит. 
Когда-нибудь этот кристаллид вырастит. 

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

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

Почему получилось? Ну я ... эээ, ммм... я хороший мальчик!
Эмиль Пальяруло, ведущий геймдизайнер BGS

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

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

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

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

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

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

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

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

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

GDD - это работа

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

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

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

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

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

Если хаос на столе означает хаос в голове, то что же должен означать "пустой" стол?
Альберт Эйнштейн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если где Геймдиректору и нужно проявлять жесткость - то в границах игры. Пропиши свои ограничения в документах и повесь на видное место. Говори "Нет" Всему что выходит за рамки определенные во время препродакшина. Заставь всех согласится с этим.
Тим Кейн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Виды Дизайнерской Документации.

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

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

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

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

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

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

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

Создание игры

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

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

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

  • Препродакшн - поиск идеи, сеттинга и идеи. На этом этапе не трогаются вопросы баланса. На этом этапе создается ЯДРО ДИЗДОКА. Идеи обсуждаются и отбрасываются. Главное выбрать идею и основные фичи игры. На этом этапе обычно создаются атмосферные концепт арты, пишутся сценарии, рисуются карты мира, и проверяются прототипы самых интересных фич
  • Продакшн - собственно начало работы. Идея определена - и у нас есть готовый минимум на 30% диздок. А лучше сразу на 50%
    геймдизайнеры дописывают диздок, Программисты реализуют механики. Художники создают концепт арты конкретных персонажей и локаций. По мере готовности механики тестируются отдельно.
  • Постпродакшн - Собственно игра формально готова. Диздок заполнен. Но сама игра не отшлифована - наступает длительный процесс тестирования и отладки всего целиком. Что-то не успели? Это доделывают, или вырезают целиком.
    На этом этапе - часто начинают готовить материалы по расширению игры в виде DLC или Epansion set. Художники уходят на маркетинг игры(или дополнения).
  • Релиз - собственно выход игры. И дальше все зависит количества: вложенного труда и души. Все пьют шампанское и не работают, хотел бы я сказать - но нет начинают активно бегать и писать патч на исправление внезапно возникших проблем.

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

На каком языке писать диздок?

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

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

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

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

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

В чем вести Диздок?

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

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

  • В тетрадке - как это делали в 90
  • В World Файле или gogle docs
  • Notion
  • В Вики разметке Confluence
  • На салфетках

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

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

"Это самые первые записи об Ultima, сделанные даже до создания Ultima 1. Я набросал их где-то в 1976, к тому времени не написав ни единой строчки кода" (с) Ричард Гэрриот
"Это самые первые записи об Ultima, сделанные даже до создания Ultima 1. Я набросал их где-то в 1976, к тому времени не написав ни единой строчки кода" (с) Ричард Гэрриот

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

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

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

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

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

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

Что нужно добавить в диздок?

Полагаю что ВСЕ! 
Полагаю что ВСЕ! 

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

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

Больше Визуального языка (Иллюстраций и Схем)

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

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

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

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

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

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

Лаконичность 

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

Набросок интерфейса Космическоих Рейнджеров от Дмитрия Гусарова
Набросок интерфейса Космическоих Рейнджеров от Дмитрия Гусарова

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

  • Используйте списки
  • Если можно сократить. Уберите лишнее.
  • Вставляйте схемы - а не описывайте их.
  • Не пишите просто так. ЛОР и графомания должны проявлять себя в разделе с внутриигровой литературой и опциональными записками.
  • Не используйте фентези шрифты и безумное украшательство документа. Не используйте фоны имитирующие текстуру древних манускриптов (я видел некоторое дерьмо, да, теперь вы поняли почему я пищу эту заметку?!)

Детализация.

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

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

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

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

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

Настройка GDD на проект

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

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

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

Да.

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

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

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

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

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

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

– И каждый дизайнер, с кем я работаю и работал в течение жизни, если честно, по-моему, просто лентяй!

Вот вам еще подколка, эти лентяи обычно они говорят:
“Знаете, мне очень понравилась Medal of Honor, но я бы сделал пушки побольше или добавил аптечек, или…”
Ну, такое...

Они хотят поменять пару-тройку деталей в игре, которая так-то им нравится, а не сесть и основательно подумать:
“Какие существенные изменения я могу внести?”

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

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

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

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

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

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

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

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

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

Функциональность важнее Красоты

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

Что-то из Скайрма. Дизайн пещеры. На препродакшене
Что-то из Скайрма. Дизайн пещеры. На препродакшене

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

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

⚠ НИКОГДА НИЧЕГО НЕ УДАЛЯЙТЕ НА САМОМ ДЕЛЕ ⚠

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

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

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

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

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

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

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

Ядро - это ИДЕЯ (Все начинается с мечты)

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

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

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

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

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

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

Первый концептдок  принадлежащий авторству Тодда Говарда - от 20.06.2007
Первый концептдок  принадлежащий авторству Тодда Говарда - от 20.06.2007

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

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

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

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

Тим Кейн

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

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

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

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

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

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

Я вроде еще понимаю что о чем пишу. 
Я вроде еще понимаю что о чем пишу. 

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

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

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

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

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

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

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

Да конечно вместо того что бы создать что-то новое - всегда можно схалтурить и сделать сиквел и значительно снизить риски.
Это гораздо проще. Но именно поэтому мы и застряли в этом болоте посредственностей."
Рафаэль Колантонио, основатель Аркейн, Вольверин Ай

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

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

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

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

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

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

In a place outside the time...
In a place outside the time...

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

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

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

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

Базовыми механиками устройства ввода

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

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

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

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

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

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

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

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

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

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

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

Платформы?

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

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

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

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

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

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

Тезариус

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

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

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

У нас был термин Боксинг, который означал установить на уровне триггер квестового скрипта для уровня и соединить его со скриптовой системой квестов. И мы с коллегами понимали друг друга.
Уилл Шен, GDC.

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

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

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

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

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

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

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

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

Строительные стандарты

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

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

Размеры дверей в реальности, в ВР игре  HLA и  HL2
Размеры дверей в реальности, в ВР игре  HLA и  HL2

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

Так как все когда-то были детьми, то вы даже НЕ ЗАМЕТИТЕ что с дверью что-то не так. Пока я вам не показал.
Так как все когда-то были детьми, то вы даже НЕ ЗАМЕТИТЕ что с дверью что-то не так. Пока я вам не показал.

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

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

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

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

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

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

Строение мира игры.

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

Ранний концепт Морровинда, изначально лавы было ГОРАЗДО Больше. 
Ранний концепт Морровинда, изначально лавы было ГОРАЗДО Больше. 

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

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

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

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

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

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

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

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

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

ЛОГИКА ИГРЫ (Глобальные системы и локальные механики)

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

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

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

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

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

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

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

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

Системы

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

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

Механики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Наполнение
  • Тестирование
  • Балансировка
  • Тестирование
  • Переделки
  • Тестирование
  • ... (и так по кругу)

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

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

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

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

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

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

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

Для игр Ultima от первой до пятой у меня были записные книжки — иногда я даже заводил парочку папок, в одной была линейная история, в другой — список персонажей по алфавиту, в третьей — города и их обитатели, но, по сути, я повторял информацию трижды, потому что это помогало мне думать:
“Так, никого нет в городе Луны, кого я могу туда поместить? Или какую часть истории я могу переместить туда?”

Ричард Гэрриот

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Немного послесловия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я НЕ ЗНАЮ КУДА ЭТО ВПИХНУТЬ

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

Вопрос Авторства

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

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

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

Тони Гудман, Ensemble Studios

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

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

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

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

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

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

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

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

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

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

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

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

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

Исследования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эссе и раскадровки приключения

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

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

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

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

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

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

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

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

  • Прокрутите игру в голове - тщательно обдумайте идею.
  • Обдуманную идею запишите все в документацию
  • Сделайте наброски дизайна и интерфейсов для иллюстрации обдуманной идеи.
  • Держите под рукой «ударную команду» тестеров которым будете скармливать ваши идеи.

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

Внешние ссылки

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

Библия Дума

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

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

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

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

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

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

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

Арт Гид Valve

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

Эссенция GDD

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

Канал Тима Кейна

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

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

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

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

Нужны ли GDD при разработке игр?
3535
33
11
70 комментариев

кто дочитал до конца?

5
Ответить

никто

5
1
Ответить

Я прочитал

2
Ответить

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

Я надеюсь это сознательное преувеличение. Потому что, конечно, во всем нужен взвешенный подход и аджайл с его "работающий продукт важнее документации" тоже не просто так придумали. Документация нужна и как способ структуировать собственные мысли, понять что именно будем разрабатывать, и как способ коммуникации между участниками команды, потому что все может быть понятно неправильно будет понято неправильно. Кажется, что в случае соло-разработчика вторая часть не актуальна (зато очень актуальна первая), но это тоже не совсем так: разработка длится месяцы, если не годы, и за это время у тебя из будущего появляются вопросы к тебе из прошлого: что ты собственно имел ввиду? И тут хорошо если от прошлой версии тебя пришла какая-то корреспонденция.

Но если быстрее что-то просто реализовать, оттестить и зафиксировать, чем это расписывать, то лучше реализовать и оттестить.

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

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

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

Этот прием часто используют при разработке визуальных новелл и линейных кинематографических игр, насколько я знаю, — собственно в кино раскадровки стандартный инструмент. Но в случае игр с открытым миром, с процедурной генерацией сюжетов песочниц — не очень понятно насколько такие эссе или комиксы полезны. Тут скорее можно было бы сказать о важности прототипа. Вернее о важности наиболее простого и эффективного прототипа. Для каких сюжетных игр это может быть действительно просто рассказ или текстовый квест собранный на twine, например. Я лично ink использую для этих же целей.

6
Ответить

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

1
Ответить

Про раскадровки. Я вставил пример из марио. Там довольно наглядно показаны механики в виде картинок.
Возможно ты этот пример пропустил, так как он вставлен раньше.

На ракадровках очень удобно показывать "механики игры" это будет более наглядно чем читать схемы.

1
Ответить

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

1
Ответить