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

• Бизнес-документация (описательная документация) – набор базовых документов, разрабатываемых на этапе концептирования проекта. Они предназначены для описания будущей игры и создания понятного ее образа. В основе этого набора документов находится концепт-документ, но может быть разработана еще группа документов типа вижена (vision – «видение») и питча (pitch – «презентация»). Описание игры, которое будет составлять эти документы, должно быть достаточным для понимания сути и перспектив игры даже неспециалистом. Эта документация ложится в основу всего проекта, становится его фундаментом и, соответственно, не должна меняться в процессе работы.

• Функциональная документация – это основная часть нашего дизайн-документа. Ее суть заключается в перечислении и описании игровых механик, компонентов, функций, фичей (feature – «особенность») и интерфейсов. Эти описания должны покрывать все элементы, из которых будет состоять игра, но при этом они могут разрабатываться и уточняться последовательно по мере необходимости. Основа диздока должна быть разработана еще на этапе прототипа. Сами описания должны быть достаточными для того, чтобы ответственные за распределение задач люди могли самостоятельно составить техническое задание для исполнителей.

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

Воркфлоу (workflow – «рабочий поток») и пайплайн (pipeline – «трубопровод») – это последовательность выполнения работы, необходимой для реализации отдельного компонента или целого продукта. Например, действия, которые необходимо выполнить для появления сюжетного персонажа на уровне, начиная с описания дизайнером, через проработку сценаристом и заканчивая созданием модели и установкой ее на локации. Воркфлоу и пайплайны прорабатываются в начале работы над проектом, чтобы оптимизировать процесс производства.

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

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

• Документация контента – в некотором смысле результат всей работы над игрой. Эта документация описывает, как в конечном счете должны быть настроены все элементы игры: камеры, персонажи, предметы, уровни, какие характеристики и цены должны иметь. Документация контента выступает промежуточным звеном между дизайн- и вспомогательной документацией и самой игрой.

* * *

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

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

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

1. Подготовительный этап

• Запрос – идея фичи или игровой механики, состоящая из короткого описания и целей: улучшение игрового процесса или каких-то бизнес-показателей. Запрос может исходить практически от кого угодно: от руководства студии или даже от игроков.

• Создание концепции – более детальное описание того, как идея должна быть встроена в игру, каким образом будут достигнуты поставленные цели.

• Первое обсуждение – проверка идеи на соответствие концепции игры в целом и возможности ее реализации, а также выполнения поставленных задач.

• Финализация концепции – в соответствии с появившимися на предыдущем шаге сомнениями и новыми данными.

• Технический анализ – оценка идеи с точки зрения технических ограничений и возможного влияния на техническую архитектуру игры в целом. Его должны производить технические специалисты, а не дизайнеры.

• Финальная оценка – определение трудозатрат, рисков и ценности идеи для проекта.

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

2. Производство

• Разработка дизайн-документации фичи – создание описания механики, персонажей, макетов и схем.

• Разбивка фичи на отдельные задачи (декомпозиция) – определение списка задач, которые необходимо выполнить для реализации фичи в полном объеме, и оценка времени на их выполнение.

В рамках одной фичи задачи могут делиться на взаимосвязанные логические блоки, для работы над которыми могут понадобиться очень разные навыки: арт, дизайн, программирование. В методике управления Agile эти блоки называются User Story (пользовательские истории, в данном случае это тоже производственный термин) и описывают буквально, что должен увидеть или иметь возможность сделать пользователь в результате окончания работы над этим блоком.

При создании блоков сама постановка задачи идет от лица пользователя: «как игрок (кто), я хочу управлять автомобилем (что), чтобы логично перемещаться по игровому миру (зачем)», а не от лица заказчика, коим в данном случае выступает дизайнер игры. Конечно, задачи могут ставиться и от лица дизайнера тоже: например, если необходимо разработать какой-то инструмент, облегчающий работу над игрой. «Как гейм-дизайнер, я хочу использовать удобную форму для создания новых предметов, чтобы не тратить на эту работу по 20 минут на предмет». Формулировка громоздкая, но позволяет сразу понять, что и для чего нужно сделать.

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

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

• Производство – собственно, выполнение задач, связанных с фичей.

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

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

3. Постпродакшн

• Анализ эффективности идеи – смогла ли она достичь поставленных изначально целей или нет.

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

* * *

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

В чистом виде в нашей игре, вероятно, будет только игровой процесс. По крайней мере, мы, скорее всего, будем думать об игре именно так.

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

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

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

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

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

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

* * *

Путь, который проходит игрок по получающейся таким образом схеме, называется уже встречавшимся нам термином «пользовательская история», или «пользовательский опыт». Но в отличие от пользовательских историй из управления проектами, пользовательская история на уровне дизайна не выделяет какой-то отдельной механики и тянется от момента первого знакомства игрока с игрой в магазине до момента, когда он принимает решение прекратить играть в игру и удалить ее. Отдельные шаги на этом пути можно уже выделить как задачи: загрузка ассетов, проверка наличия профиля игрока, экран пользовательского соглашения и т. п.

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

• Механика – отобразить окно пользовательского соглашения. В окне будет область для текста, кнопка для выбора языка и кнопки отказа и подтверждения.

– По умолчанию текст и надписи на кнопках должны отображаться на английском языке.

– Если текст не будет умещаться в пределах окна, то должен отображаться скроллбар и, соответственно, должна быть возможность прокрутить текст вниз.

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

– Список языков должен браться из базы локализации игры.

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

– При нажатии на кнопку отказа происходит выход из игры.

– При нажатии на кнопку подтверждения происходит переход к следующему действию в соответствии со схемой.

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

• Графика: для окна пользовательского соглашения должен быть разработан макет, который художники смогут обрисовать.

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

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

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

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

• Настройки: конкретно для окна пользовательского соглашения настройками будут используемые в этом окне тексты – само соглашение, названия языков для кнопки выбора и надписи на кнопках отказа и подтверждения. В данном случае тексты относятся к контенту.

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

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

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

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

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

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

Второй вариант – большие разделы – скорее всего, будет удобнее при использовании сервисов ведения документации. Этот метод подойдет для специалистов в конкретных областях. Например, дизайнеру интерфейсов комфортнее иметь собственный раздел в документации и работать в нем.

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