2. Детальный ГДД (англ. Detailed Design Document) – этот документ описывает все игровые механики и интерфейс в мельчайших подробностях. Данный документ преследует две цели: позволяет дизайнеру помнить все идеи, приходящие ему в голову, а также помогает ему передавать эти идеи программистам, пишущим по ним код, и художникам, оборачивающим эти идеи в визуальную оболочку. Поскольку данный документ редко показывается людям, не связанным с проектом, он часто составляется в виде черновика и без особой структуры. Достаточно того, что этот документ может положить начало дискуссии и не позволяет забывать о важных деталях. Как правило, это самый длинный документ, который, кстати, редко обновляется и доводится до логического конца. Дело в том, что на полпути к окончанию проекта о документе часто забывают: к этому моменту сама игра содержит большую часть важных деталей, а те, которых в игре еще нет, распространяются между членами команды при помощи менее формальных средств, таких как электронные письма или короткие записки. Но в начале проекта важно найти правильную структуру ГДД. В большинстве случаев гораздо удобнее иметь несколько небольших документов со ссылками на подсистемы, нежели один гигантский документ. Дизайнер Рич Мармура удачно высказал эту мысль следующими словами: «Я всегда адаптирую ГДД под ту команду, с которой работаю сейчас. ГДД – это не только возможность структурировать мои мысли, это источник информации для членов команды. Для каждой конкретной игры структура и стиль ГДД меняется, хотя основа остается неизменной. Вы не найдете двух одинаковых команд или двух одинаковых игр – так и с ГДД. Он всегда разный».

3. Обзор истории (англ. Story Overview). Во многих играх для написания основного сюжета и диалогов нанимают профессиональных писателей. Обычно они работают удаленно, то есть находятся далеко от всей остальной команды. Геймдизайнеру периодически приходится составлять короткий документ, описывающий присутствующие в игре сеттинги, персонажи и события. Случается и так, что у ознакомившихся с документом писателей возникают собственные идеи, которые в итоге могут значительно повлиять на дизайн игры.

Технологии

4. Технический дизайн-документ (англ. Technical Design Document). Часто видеоигра включает в себя множество сложных систем, не имеющих ничего общего с механикой, но отвечающих за появление определенных элементов на экране, обмен данными и другие исключительно технические моменты. Обычно эти детали нужны только программистам, но если ваша инженерная команда состоит из более чем одного человека, будет полезно отмечать эти моменты в одном документе. В этом случае новые люди, присоединившиеся к вашей команде, сразу поймут, что и как должно работать. Так же как и ГДД, этот документ редко дописывают до конца, но его написание крайне важно для того, чтобы держать под контролем всю программную составляющую игры.

5. Пайплайн-документация (англ. Pipeline overview). Большая часть сложностей, сопряженных с разработкой игры, связана с правильной интеграцией графических элементов. Существует множество правил, которым должны следовать художники, если они хотят, чтобы их графика корректно отображался в игре. Обычно этот документ составляется инженерной командой специально для художников, и чем проще он написан, тем лучше.

6. Системные ограничения (англ. System limitations). Дизайнеры и художники часто не имеют ни малейшего представления о том, что возможно, а что невозможно в той системе, для которой они создают контент. Для некоторых игр программисты составляют специальные документы, где дают четкое представление о границах системы, которые нельзя пересекать: о количестве фигур, одновременно показанных на экране, количестве сообщений об обновлениях за секунду, количестве одновременных взрывов на экране и т. д. Системные ограничения редко описываются подробно, но если вы обозначите их (желательно в письменном виде), это впоследствии поможет вам сохранить немало времени. К тому же подобные документы могут подтолкнуть к новым дискуссиям, в результате которых часто находятся нестандартные решения, позволяющие выйти за существующие границы.

Графика

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

8. Обзор концептов (англ. Concept Art Overview). В команде есть немало людей, которым необходимо представлять себе игру еще до начала ее разработки. Для этого используется концепт-арт. Но одних рисунков недостаточно. Разумнее всего использовать концепты как часть ГДД, поэтому обычно художники работают с геймдизайнерами, вместе определяя список концептов, лучше всего передающих суть игры. Эти ранние изображения можно увидеть везде: в кратком ГДД, в ГДД или даже в технических документах, в которых они используются для того, чтобы лучше проиллюстрировать желаемый визуальный стиль.

Разработка

9. Бюджет (англ. Game Budget). Просто «работать над проектом от начала до конца» – мечта любого геймдизайнера, но экономическая реальность игрового бизнеса редко позволяет так расслабиться. Чаще всего со стоимостью разработки нужно определиться еще до начала работы над проектом, не до конца понимая, над чем именно вам предстоит работать. Стоимость проекта высчитывается в специальном документе, чаще всего это таблица, предназначенная для систематизации рабочего процесса по созданию игры. Данная таблица заполняется оценками сроков, которые переводятся в доллары. Продюсер или менеджер проекта самостоятельно высчитать эти цифры не может, поэтому, чтобы максимально точно провести расчеты, ему необходимо в течение некоторого времени поработать поочередно с каждой частью команды. Часто этот документ пишется одним из первых, поскольку без него трудно добиться финансирования проекта. Хороший менеджер работает с этим документом на протяжении всего проекта: стоимость разработки не должна выходить за границы выделенного бюджета.

10. Список ресурсов (англ. Asset tracker). Независимо от того, в каком виде вы представите этот документ – простой таблицей или более формально, – он должен отслеживать, какое количество контента было создано и в каком состоянии находятся материалы, над которыми команда еще работает. Сюда относится код, графика, уровни, звуки, музыка и дизайн-документы.

11. График проекта (англ. Product Schedule). В хорошо отлаженном проекте этот документ обновляется чаще всего. Мы знаем, что процесс дизайна и разработки игры сопряжен с большим количеством неожиданностей и непредсказуемых изменений. Тем не менее без планирования не обойтись – в идеале этот документ подразумевает периодическое внесение корректировок, по крайней мере раз в неделю. В хорошем графике проекта перечислены все задачи, которые нужно выполнить, выделенное на это время, а также люди, отвечающие за выполнение каждой из задач. Желательно, чтобы в этом документе учитывалось, что один человек не может работать больше сорока часов в неделю, а также то, что к выполнению некоторых задач нельзя приступить до завершения предыдущих. Иногда этот график ведется в электронной таблице, а иногда – при помощи специфических утилит для менеджеров проектов. Если вы работаете над крупным проектом, резонно нанять отдельного специалиста, который будет вести этот документ.