Создаем игры с нуля! 3 книги для старта в гейм-деве - Григорий Радовильский

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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