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

Что может входить в дизайн-документ:

● название и игровой жанр,

● логлайн (кратко, в виде анонса, перечислить основные моменты игры),

● краткий обзор игры, ее философия (что это за игра и зачем она создается),

● сеттинг (время, место, атмосфера в игре),

● визуальный стиль (реализм, фэнтезийный, мультяшный, также 3D-или 2D-игра),

● движок,

● режим (многопользовательский, однопользовательский, кооперативный и т. п.),

● отличие от других игр (преимущества перед референтными играми),

● характеристики (для какой платформы и аудитории планируем выпустить игру),

● время прохождения (приблизительное количество часов или минут на все прохождение в среднем),

● геймплей (что и как контролирует игрок, примерное описание взаимодействия игрока с сущностями игрового мира),

● кор-механика и метагейм,

● игровой мир, карта, локации,

● интерфейс,

● камера (от первого лица, от третьего лица, изометрическая и т. п.),

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

● сюжет,

● музыка и звуковые эффекты,

● журнал заданий,

● схема переходов между экранами,

● свойства персонажа,

● инвентарь,

● внутриигровые тексты (дневники, свитки, заметки в ноутбуке и т. п.),

● настройки,

● загрузка и сохранение,

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

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