Как создаются игры

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

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

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

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

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

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

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

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

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

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

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