Как создаются игры. Основы разработки для начинающих игроделов - Григорий Радовильский
Шрифт:
Интервал:
Закладка:
Тестлонч (test launch – «технический запуск») – этап запуска игры, когда разработчик может проверить ее производительность и наличие багов, связанных с особенностями игровых устройств, которые могут быть у игрока. Это важно для разработчиков игр для РС и мобильных устройств, так как количество комплектующих и оригинальных моделей необычайно велико.
Ретлонч (retention launch – «запуск удержания») – тестовый запуск, предназначенный для проверки привлекательности для игроков основных игровых механик. Соответственно, версия игры на этом этапе может вообще не содержать ни каких-либо других метамеханик, ни монетизации. Основным показателем этого запуска является интерес игроков, выражающийся в возвращении на следующий день после первого запуска игры.
Софтлонч (soft launch – «мягкий запуск») – это релиз игры для ограниченной аудитории с целью сбора информации о показателях проекта. Обычно софтлонч проводят в какой-то одной или нескольких странах. На этапе софтлонча разработчик имеет возможность проверить работу игры на реальных игроках, при этом не вкладывая значительных средств в их привлечение. Это, по сути, тестовый запуск игры, который помогает проверить гипотезы о том, как лучше оптимизировать игровой процесс, кривую сложности игры и получаемые игроком награды, чтобы при запуске игры на мир, при полноценном релизе, иметь максимально подготовленную игру.
Работа с рекламой и аналитикой вместе с особенностью устройства магазинов приложений для мобильных устройств позволяют разделить релиз игры на несколько этапов: техлонч, ретлонч и т. п. Одним из важнейших является запуск в режиме софтлонча в тестовом регионе, в котором стоимость рекламного трафика минимальна, а поведение игроков похоже на поведение игроков из более дорогих и прибыльных регионов. Если софтлонч пройдет успешно и в результате оптимизации игровых механик получится достигнуть целевых показателей, можно будет запускать игру на мир.
После релиза игры на мир разработка мобильной игры не прекращается. В отличие от законченных игр для мобильных устройств, выпускаются не дополнения, а полноценные развития механик существующей игры. Это может быть добавление и социальных механик, и новых боевых режимов, не предусмотренных даже изначальной концепцией игры. И конечно, не должна останавливаться оптимизация существующих механик.
Однако может так случиться, что этапы релиза игры для мобильных устройств не достигают показателей, необходимых для продолжения работы над игрой. Рекламный трафик может оказаться слишком дорогим, а оптимизация имеющихся механик – недостаточно эффективной. И в этом случае появится необходимость закрыть проект, прекратить его развитие и поддержку, несмотря на уже набранную аудиторию. Чем раньше проблемы будут выявлены, тем больше возможностей у нас будет их исправить или успеть начать новый проект, который может оказаться более удачным. В западной культуре существует поговорка «fail fast, fail often», которую можно перевести как «проваливайся быстро и часто», чтобы поскорее прийти к успеху.
Документация
Документация, в целом необходимая для разработки игры, – это сложный комплекс различных отдельных и пересекающихся документов, в разработке которых может принимать участие очень большое количество специалистов.
• Бизнес-документация (описательная документация) – набор базовых документов, разрабатываемых на этапе концептирования проекта. Они предназначены для описания будущей игры и создания понятного ее образа. В основе этого набора документов находится концепт-документ, но может быть разработана еще группа документов типа вижена (vision – «видение») и питча (pitch – «презентация»). Описание игры, которое будет составлять эти документы, должно быть достаточным для понимания сути и перспектив игры даже неспециалистом. Эта документация ложится в основу всего проекта, становится его фундаментом и, соответственно, не должна меняться в процессе работы.
• Функциональная документация – это основная часть нашего дизайн-документа. Ее суть заключается в перечислении и описании игровых механик, компонентов, функций, фичей (feature – «особенность») и интерфейсов. Эти описания должны покрывать все элементы, из которых будет состоять игра, но при этом они могут разрабатываться и уточняться последовательно по мере необходимости. Основа диздока должна быть разработана еще на этапе прототипа. Сами описания должны быть достаточными для того, чтобы ответственные за распределение задач люди могли самостоятельно составить техническое задание для исполнителей.
• Инструкции – это вид технической документации, описывающей правила, по которым должна выполняться работа: различные воркфлоу и пайплайны, вырабатываемые на этапе вертикального среза или позаимствованные из уже имеющегося опыта. После этого инструкции не должны меняться. На основе инструкций может быть настроен сервис менеджмента проектов, либо за их выполнением должен следить отдельный менеджер.
Воркфлоу (workflow – «рабочий поток») и пайплайн (pipeline – «трубопровод») – это последовательность выполнения работы, необходимой для реализации отдельного компонента или целого продукта. Например, действия, которые необходимо выполнить для появления сюжетного персонажа на уровне, начиная с описания дизайнером, через проработку сценаристом и заканчивая созданием модели и установкой ее на локации. Воркфлоу и пайплайны прорабатываются в начале работы над проектом, чтобы оптимизировать процесс производства.
• Спецификации – вид технической документации, описывающей различные технические и дизайнерские ограничения игрового мира, за пределы которых не должны выходить ни художники, ни программисты, ни дизайнеры. К этим ограничениям относятся стиль и качество графических ассетов (цветовая палитра, размер текстур, количество полигонов), размер объектов игрового мира (чтобы предметы и персонажи были соответствующего друг другу размера) и, например, отсутствие лошадей в игре, о чем должны помнить сценаристы. Спецификации вырабатываются на этапах прототипирования и вертикального среза, после чего не должны меняться.
• Вспомогательная документация – расчеты баланса, математические модели поведения различных объектов и т. п. Эта документация выделяется из дизайн-документов, потому что, по сути, не является описанием каких-либо функций. В то же время вспомогательная документация является не частью контента игры, а лишь основой для работы над ним.
• Документация контента – в некотором смысле результат всей работы над игрой. Эта документация описывает, как в конечном счете должны быть настроены все элементы игры: камеры, персонажи, предметы, уровни, какие характеристики и цены должны иметь. Документация контента выступает промежуточным звеном между дизайн– и вспомогательной документацией и самой игрой.
* * *
Документация игры живая, она развивается по мере разработки игры вместе с самим продуктом. Мы начинаем с идеи, создаем описание механик для прототипа. К концу работы над прототипом мы получаем набор работающих механик и переходим к разработке списка контента, который будем разрабатывать на этапе вертикального среза. К концу работы над вертикальным срезом мы получаем набор технической документации, регламентирующей процесс разработки игры. На этапе производства мы, наконец, можем наполнить список контента свойствами, в чем нам помогают различные расчеты.
Если не считать каких-то специфических документов, составляемых менеджерами и техническими специалистами (в основном это инструкции), над документацией игры работают гейм-дизайнеры. Системные дизайнеры трудятся над механиками, математики создают баланс и боевую систему, дизайнеры уровней – схемы уровней, сценаристы – сюжеты и квесты, контентщики корпят над персонажами и предметами. Игра проходит через гейм-дизайнеров от начала и до конца, от концепции до контента, окончание работы над которым свидетельствует об окончании процесса производства игры. В результате этого у гейм-дизайнеров образуются собственные пайплайны решения конкретных задач и работы над документацией в целом. И этот пайплайн оказывается в основе всей работы над игрой, просто потому что решение каких-то конкретных задач (создание графики, кода, уровней и предметов) находится внутри него: между утверждением финальной документации и проверкой реализации на соответствие ей.
Следующий пример касается разработки отдельной механики или игровой фичи, хотя мы уже видели, что, в общем, процесс разработки любого отдельного элемента похож на цикл разработки всей игры. Этот пример максимально подробный, но остается всего лишь примером, а реальный пайплайн работы над фичей может и будет зависеть от состава команды.
1. Подготовительный этап
• Запрос – идея фичи или игровой механики, состоящая из короткого описания и целей: улучшение игрового процесса или каких-то бизнес-показателей. Запрос может исходить практически от кого угодно: от руководства студии или даже от игроков.
• Создание концепции – более детальное описание того, как идея должна быть встроена в игру, каким образом будут достигнуты поставленные цели.
• Первое обсуждение – проверка идеи на соответствие концепции игры в целом и возможности ее реализации, а также выполнения поставленных задач.
• Финализация концепции – в соответствии с появившимися на предыдущем шаге сомнениями и новыми данными.
• Технический анализ – оценка идеи с точки зрения технических
