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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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