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