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

Софтлонч(soft launch – «мягкий запуск») – это релиз игры для ограниченной аудитории с целью сбора информации о показателях проекта. Обычно софтлонч проводят в какой-то одной или нескольких странах. На этапе софтлонча разработчик имеет возможность проверить работу игры на реальных игроках, при этом не вкладывая значительных средств в их привлечение. Это, по сути, тестовый запуск игры, который помогает проверить гипотезы о том, как лучше оптимизировать игровой процесс, кривую сложности игры и получаемые игроком награды, чтобы при запуске игры на мир, при полноценном релизе, иметь максимально подготовленную игру.

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

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

Однако может так случиться, что этапы релиза игры для мобильных устройств не достигают показателей, необходимых для продолжения работы над игрой. Рекламный трафик может оказаться слишком дорогим, а оптимизация имеющихся механик – недостаточно эффективной. И в этом случае появится необходимость закрыть проект, прекратить его развитие и поддержку, несмотря на уже набранную аудиторию. Чем раньше проблемы будут выявлены, тем больше возможностей у нас будет их исправить или успеть начать новый проект, который может оказаться более удачным. В западной культуре существует поговорка «fail fast, fail often», которую можно перевести как «проваливайся быстро и часто», чтобы поскорее прийти к успеху.

Документация

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

• Бизнес-документация (описательная документация) – набор базовых документов, разрабатываемых на этапе концептирования проекта. Они предназначены для описания будущей игры и создания понятного ее образа. В основе этого набора документов находится концепт-документ, но может быть разработана еще группа документов типа вижена (vision – «видение») и питча (pitch – «презентация»). Описание игры, которое будет составлять эти документы, должно быть достаточным для понимания сути и перспектив игры даже неспециалистом. Эта документация ложится в основу всего проекта, становится его фундаментом и, соответственно, не должна меняться в процессе работы.

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

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