Траектория «Геймдев» · линия A · конспект 1 из 13

Дизайн-документ: от концепта к GDD

О чём эта тема
Проектная документация игры: какие документы пишутся до начала разработки, чем концепт-документ отличается от дизайн-документа (GDD) и почему без них командная разработка быстро теряет управляемость.
Аннотация
Конспект начинается с определения игрового дизайна и роли геймдизайнера в команде. Затем рассматриваются три основных документа проектной документации — концепт-документ, дизайн-документ и документ-предложение — и их назначение на разных стадиях жизни проекта. Основная часть посвящена дизайн-документу: его цели, свойству «живости», примерной структуре и типичным ошибкам при описании механик и визуальной части. Завершается конспект разбором структуры концепт-документа, с которого начинается любой студенческий проект траектории, и интерактивным конструктором для самопроверки собственного концепта.
Пререквизиты
Первый конспект траектории — специальных знаний не требуется. Полезен собственный игровой опыт: примеры опираются на известные игры.
Мотивация
Допустим, в описании проекта сказано: «игрок сражается с врагами, убивает монстров и захватывает замки». Под это описание подходят и Heroes of Might and Magic, и World of Warcraft — игры, не похожие друг на друга почти ничем: ни жанром, ни управлением, ни темпом. Команда из трёх человек, прочитав такую фразу, сделает три разные игры. Документация нужна, чтобы все участники — и программист, и художник, и сам автор через месяц — понимали под проектом одно и то же.

1. Игровой дизайн и геймдизайнер

Игровой дизайн (геймдизайн, англ. game design) — процесс создания формы и содержания игрового процесса (геймплея) разрабатываемой игры. Игровой дизайн определяет: набор возможных вариантов, из которых игрок выбирает во время игры; условия победы и поражения; способ, которым игрок контролирует происходящее и взаимодействует с игровым миром; сложность игры.

Геймдизайнер — человек, разрабатывающий правила игры. Ему нужны навыки аналитика, психолога, технического писателя и игрока, умение работать в команде; из дополнительных навыков полезны любые, применимые в разработке: художественный вкус, рисование, 3D-моделирование, базовые математика, физика и программирование. Основная задача геймдизайнера — выработать целостное видение игры и зафиксировать его в дизайн-документе: во время активной разработки все технические спецификации базируются именно на этом видении.

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

2. Три документа проектной документации

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

Проектная документация игры
Концепт-документ
2–6 страниц; основные особенности игры и оценка ресурсов на разработку
Дизайн-документ (GDD)
максимально полное описание игры; «игра на бумаге»
Документ-предложение
краткое описание без внутренних деталей — для инвестора: почему игра принесёт прибыль

Порядок появления документов отражает жизнь проекта. Сначала пишется концепт-документ — короткий текст, по возможности разбавленный иллюстрациями, из которого видно основные особенности игры и приблизительно понятно, какие ресурсы потребуются. Когда становится ясно, что этап препродакшена будет пройден, концепт-документ начинает обрастать деталями и превращается в дизайн-документ. Документ-предложение (англ. proposal document) адресован не команде, а потенциальному инвестору или издателю.

У крупных студий выделяется ещё технический дизайн-документ (technical design document): полигональный бюджет, целевая частота кадров, объём памяти, портируемость, противодействие читам, используемые языки и утилиты. У небольших российских разработчиков он, как правило, отдельно не выделяется — технические требования включают разделом в GDD.

3. Дизайн-документ (GDD)

Дизайн-документ (GDD, Game Design Document) — детальное описание разрабатываемой игры; максимально полное «описание игры на бумаге», позволяющее составить план действий по превращению задуманного проекта в реальный. Цель документа — однозначно описать коммерческие аспекты, целевую аудиторию, игровой процесс, графику, дизайн уровней, сюжет, персонажей и пользовательский интерфейс: каждое требование должно быть достаточно подробным для соответствующего специалиста. Документ намеренно разделяется на части, которые разные участники команды могут поддерживать независимо; в целом его принято делить на функциональную и техническую спецификации.

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

Типичная ошибка Считать GDD «сданным отчётом», который пишется один раз. Обратная ошибка — бесконечно переписывать документ вместо разработки. Рабочий режим: документ меняется вместе с проектом, и каждое изменение доносится до команды.

3.1. Примерная структура

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

3.2. Механики описываются точно

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

Таблица взаимодействий: строки — действия (уклонение, блок, атака), столбцы — способности (магнезис, бомба, стазис и другие), в ячейках — результат сочетания
Таблица взаимодействий механик (пример из The Legend of Zelda: Breath of the Wild). Источник: habr.com/ru/articles/876560 (см. «Источники»)

На разделы документа прикрепляются перекрёстные ссылки, чтобы членам команды было удобно ориентироваться. Раздел, на который никто не ссылается, — кандидат на удаление.

3.3. Карта игрового процесса

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

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

К этой схеме мы вернёмся в конспекте A08: главное меню, экран игры и переходы между сценами будут реализованы в Unity через SceneManager.

3.4. Визуальная составляющая: цель, а не спецификация

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

Неудачно Элементы игры:
  • полоса здоровья — красная полоса разрешением 250 × 50 пикселей, в верхнем левом углу экрана;
  • полоса энергии — синяя полоса разрешением 250 × 50 пикселей, в верхнем левом углу экрана.
Лучше Визуальная часть должна создавать ощущение сказки и способствовать погружению в фэнтезийный мир. Интерфейсы — иммерсивные (например, при открытии инвентаря персонаж снимает рюкзак с плеч — и игрок видит его содержимое). Проработать элементы:
  • индикатор здоровья;
  • индикатор энергии;
  • индикатор перегруженности.

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

Типичная ошибка Путать точность описания механик с избыточной детализацией визуала. Механика «захват замка» требует исчерпывающего описания правил; кнопка меню — цели и референса, а не пиксельных размеров. Указание «что должно получиться» в механиках — ошибка; указание «как именно рисовать» в визуале — тоже.

4. Концепт-документ

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

Типовая структура концепт-документа:

  1. Концепция. Введение (идея игры в одном-двух предложениях); жанр и аудитория; основные особенности (USP — свойства, отличающие игру от других в том же жанре); описание игры с точки зрения игрока; предпосылки создания; платформа.
  2. Функциональная спецификация. Принципы игры: суть игрового процесса, ход игры и сюжет, физическая модель, персонаж игрока, элементы игры, «искусственный интеллект», многопользовательский режим. Интерфейс пользователя: блок-схема экранов, функциональное описание и управление.
  3. Графика, видео, звук. Двумерная и трёхмерная графика и анимация, анимационные вставки; звуковые эффекты и музыка; описание уровней и график введения новых объектов.
  4. Контакты. Авторы и способы связи.

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

Тренажёр · конструктор концепт-документа

Отметьте разделы, которые уже написаны в вашем концепт-документе. Щелчок по названию раздела показывает, что в нём должно быть. Индикатор внизу оценивает полноту концепта.

Для самостоятельного погружения полезен «диздок-десятистраничник» — шаблон по книге Скотта Роджерса с разобранным примером (см. источники).

Контрольные вопросы

Источники

  1. Диздок: гайд для начинающих разработчиков // Хабр : [сайт]. — URL: https://habr.com/ru/articles/469971/ (дата обращения: 19.09.2025).
  2. Дизайн-документ: зачем применяется, как составить и какие сервисы использовать // Хабр : [сайт]. — URL: https://habr.com/ru/articles/876560/ (дата обращения: 19.09.2025).
  3. Игровой дизайн // Википедия : свободная энциклопедия. — URL: https://ru.wikipedia.org/wiki/Игровой_дизайн (дата обращения: 07.07.2026).
  4. Дизайн-документ // Википедия : свободная энциклопедия. — URL: https://ru.wikipedia.org/wiki/Дизайн-документ (дата обращения: 07.07.2026).