Дизайн-документ игры: зачем он нужен до того, как писать код

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

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

Что на деле представляет собой GDD#

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

Конкретно в GDD попадают:

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

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

Почему документ пишут до кода#

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

Именно поэтому большинство первых проектов проваливается. Дело не в том, что разработчик не умеет программировать; дело в том, что масштаб так и не определили. Новичок открывает движок с расплывчатым замыслом — «RPG с открытым миром» — и начинает строить, и проект тонет в море незаконченных функций, никем не расставленных по приоритетам. Настоящая цель GDD — добиться, чтобы это решение о масштабе было принято до появления хотя бы одного ассета, пока «уменьшить масштаб» ещё ничего не стоит.

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

Современный GDD — живой, а не монолитный#

Образ GDD как двухсотстраничной папки пришёл из 1990-х, когда студии писали толстые дизайн-«библии» заранее, а потом наблюдали, как те рассогласуются с самой игрой. Эта модель по большей части ушла. Принцип agile — ценить работающее ПО выше исчерпывающей документации — добрался до разработки игр и дал более здоровый ответ: короткий живой документ, меняющийся всякий раз, когда меняется дизайн.

На практике это значит:

• вики или общий документ (Notion, Confluence, репозиторий с markdown) вместо одного замороженного файла;
• короткие спецификации по каждой функции вместо единого документа, пытающегося описать всё сразу;
• документ, который правят непрерывно, с проставленной датой, так что он всегда отражает игру такой, какая она есть.

Проверка хорошего современного GDD проста: если новый человек прочтёт его сегодня, поймёт ли он, какую игру делают прямо сейчас? Спецификация на двести страниц, написанная восемь месяцев назад, эту проверку не проходит. Живой документ на четыре страницы — проходит.

Минимум, необходимый GDD для первой игры#

Сольному разработчику или крошечной команде не нужны все разделы, которые использует AAA-студия. Нужен самый небольшой документ, который всё же заставляет принять дорогие решения. Обычно это одна-пять страниц:

Раздел	На что отвечает	Почему это важно
Формулировка в одном предложении	Что такое игра, одним предложением?	Если не получается — идея ещё не созрела
Основной цикл	Что игрок делает снова и снова?	Это и есть игра; всё остальное служит ему
Целевой игрок	Для кого она?	Задаёт сложность, длительность и масштаб
Управление и платформа	Как в неё играют и где?	Определяет схему ввода и технические рамки
Художественное и звуковое направление	Как она выглядит и звучит?	Держит проект цельным и конечным
Масштаб (что входит и что нет)	Что выйдет в v1, а что нет?	Сильнее всего предопределяет, доведёте ли вы игру до конца
Критерий готовности	Когда она закончена?	Превращает бесконечное хобби в выпускаемую игру

Эта таблица — бо́льшая часть рабочего GDD. Если нужен реальный образец для подражания, публичные дизайн-документы известных игр скупы на философию и щедры на конкретные списки. Оригинальный дизайн-документ Grand Theft Auto — написанный в DMA Design, когда игра ещё называлась Race'n'Chase, — и Doom Bible Тома Холла стоит прочесть именно потому, что они конкретны, однозначны и явно написаны, чтобы разрешать споры, а не производить впечатление.

Частые ошибки в GDD#

Ошибка	Чем вредит	Чем заменить
Писать всё заранее	Закрепляет решения, не проверенные в игре	Сначала сделайте прототип основного цикла, затем документируйте
Считать его неизменным	Спецификация, которую нельзя менять, устаревает и игнорируется	Ведите его как живой; обновляйте дату при каждой правке
Описывать всё подряд	Объёмный GDD описывает игру, которую ещё не решили делать	Пишите минимум, фиксирующий масштаб и готовность
Без критерия готовности	Без него у проекта нет условия завершения	Запишите точное состояние, которое считается законченным
Без списка того, что не войдёт	Без явных сокращений масштаб растёт вечно	Перечисляйте то, чего не будет в v1, так же чётко, как то, что будет
Давать ему разойтись со сборкой	GDD, который расходится с игрой, хуже отсутствующего	Сверяйте его при каждом изменении дизайна

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

Роль Egmatic#

GDD снижает цену проектных решений, перенося их на бумагу. Визуальный редактор снижает её ещё сильнее, позволяя увидеть решение в тот момент, когда вы его принимаете. Egmatic — это IDE и движок для 2D-игр на базе MonoGame: вы выстраиваете сцены, размещаете объекты и связываете логику через узлы в живом редакторе, так что расстояние от «решения на странице» до «играбельной реакции на него» измеряется секундами, а не циклом пересборки.

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

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

Итог#

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