Как создаются игры. Основы разработки для начинающих игроделов - Григорий Радовильский

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты

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

ИНСТРУМЕНТЫ ДЛЯ ДОКУМЕНТАЦИИ

Так как мы рассматриваем разработку игр именно с точки зрения игрового дизайна, то начнем с главного для любого гейм-дизайнера инструмента: текстового редактора.

Для работы с текстами есть три инструмента разной сложности и распространенности.

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

• Сервисы типа Office 365 и Google Drive позволяют работать с файлами онлайн. Это удобно для работы в небольшой команде и позволяет иметь доступ к файлам в любое время с любого устройства, а также безопасно по сравнению с хранением файлов на своем компьютере. Но это также несет некоторые риски: требует подключения к интернету и ставит в зависимость от аккаунта в сервисе, который может стать по тем или иным причинам недоступным.

• Бизнес-приложения, предназначенные для отдельного ведения документации, или являющиеся частью более сложного комплекса сервисов. К первым относятся такие сервисы, как Notion и Confluence, – эти сервисы позволяют вести документацию в структуре, похожей на «Википедию». Есть также бесплатные сервисы для этого. Подобная структура значительно удобнее работы с отдельными файлами. Она позволяет создавать автоматические шаблоны разделов и ссылки внутри документов, а также часто имеет более глубокую интеграцию с сервисами, предназначенными для менеджмента проектов.

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

Единственным серьезным недостатком бизнес-приложений является то, что они крайне редко имеют достаточно развитый редактор таблиц уровня Excel (для работы с локальными файлами) или Google Sheets (для работы с файлами онлайн). Без табличного редактора практически невозможно ни рассчитывать баланс, ни хранить характеристики предметов. К сожалению, из-за этого недостатка часто необходимо вести работу с несколькими различными программами и сервисами одновременно.

Очень важной частью работы над документацией является создание различных схем – визуализация алгоритмов. И для этих целей могут использоваться как встроенные в текстовый редактор инструменты рисования, так и внешние. В профессиональном пакете MS Office есть программа Visio, а в комплексе Google Drive доступен сервис Diagrams.net.

ИНСТРУМЕНТЫ ДЛЯ МЕНЕДЖМЕНТА

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

• Trello – лишь один из множества, но необычайно популярный сервис для управления проектами по методике SCRUM или KANBAN. Он позволяет