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

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

1. Краткий ГДД (англ. Game Design Overview) – документ, описывающий основные цели и функционал игры, который может занимать всего несколько страниц. Обычно этот документ создается для начальства команды, чтобы те, не углубляясь в детали, могли понять, что представляет собой ваша игра и для кого она предназначена. Обзорный документ может быть полезен и для всей остальной команды, потому что помогает им лучше представить полную картину.

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). В хорошо отлаженном проекте этот документ обновляется чаще всего. Мы знаем, что процесс дизайна и разработки игры сопряжен с большим количеством неожиданностей и непредсказуемых изменений. Тем не менее без планирования не обойтись – в идеале этот документ подразумевает периодическое внесение корректировок, по крайней мере раз в неделю. В хорошем графике проекта перечислены все задачи, которые нужно выполнить, выделенное на это время, а также люди, отвечающие за выполнение каждой из задач. Желательно, чтобы в этом документе учитывалось, что один человек не может работать больше сорока часов в неделю, а также то, что к выполнению некоторых задач нельзя приступить до завершения предыдущих. Иногда этот график ведется в электронной таблице, а иногда – при помощи специфических утилит для менеджеров проектов. Если вы работаете над крупным проектом, резонно нанять отдельного специалиста, который будет вести этот документ.

12. Руководство по сюжету игры (англ. Story Bible). Можно подумать, что история в игре определяется исключительно работающими над проектом писателями (если таковые имеются), но часто бывает так, что каждый из членов команды вносит осмысленные изменения в сюжет. Разработчику движка может показаться, что определенный элемент истории будет слишком сложно реализовать в техническом плане, и в связи с этим он может внести предложение об изменении этого элемента. У художника может возникнуть интересная визуальная идея для абсолютно новой части истории, которую писатель даже не мог себе представить. Геймдизайнер может придумать новую механику, потребующую изменения истории. Руководство по сюжету игры, в котором четко описываются все возможности и ограничения в мире вашей игры, упрощает задачу для желающих внести свой вклад и в итоге помогает создать сильный сюжет, согласованный с графикой, технологией и механиками.

13. Сценарий (англ. Script). Если неигровые персонажи (от англ. Non-Player Character, NPC) в вашей игре будут разговаривать, их диалоги должны быть где-то прописаны! Для этого нужен сценарий, который может быть как отдельным документом, так и дополнением к ГДД. Очень важно, чтобы геймдизайнер лично проверял все диалоги: существует высокая вероятность того, что некоторые реплики могут противоречить правилам игры.

14. Учебные пособия к игре (англ. Game tutorial and manual). В сложных видеоиграх игрокам необходимо обучение. Интерактивные инструкции в самой игре, интернет-форумы и печатные руководства – самые распространенные средства обучения. Крайне важно содержание этих обучающих материалов: игроки не смогут получить удовольствие от игры, которую не понимают. Скорее всего, детали дизайна вашей игры будут меняться вплоть до последнего момента разработки. Убедитесь, что кто-то в вашей команде постоянно проверяет содержимое учебных пособий и поддерживает их в актуальном состоянии.

15. Прохождение игры (англ. Game walth-through). Разработчики – не единственные, кто пишет документы об игре! Если игрокам нравится ваша игра, они будут писать собственные документы и выкладывать их в сеть. Изучая эти тексты, вы сможете в подробностях узнать, что им нравится, а что – нет, какие части игры слишком сложные, а какие слишком простые. Конечно, к тому времени, когда игроки напишут прохождение, скорее всего, будет уже поздно что-то менять, но вы можете использовать полученную информацию в следующий раз!

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