LiveOps для игр: когда подключать и какие задачи решает команда

Что такое LiveOps в игровой разработке

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

Если основная production-команда отвечает на вопрос «как выпустить игру», то LiveOps работает с другим вопросом: «как поддерживать её после выхода».

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

Для одного проекта LiveOps-команда состоит из нескольких разработчиков и QA. Для другого это отдельное направление с backend, game design, аналитикой, art production и release management.

Поэтому универсального состава здесь нет. Он зависит прежде всего от того, как часто игра должна меняться после релиза.

LiveOps лучше подключать до релиза, а не после него

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

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

Поэтому LiveOps желательно обсуждать ещё до запуска.

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

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

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

Что делает LiveOps-команда после запуска

Работа обычно начинается с довольно прозаичных вещей.

Игроки находят проблемы, которые не встретились во время внутреннего тестирования. Появляются особенности конкретных устройств. Где-то ломается интеграция SDK, где-то новая версия операционной системы меняет поведение приложения.

Поэтому первые недели после релиза часто проходят под знаком стабилизации.

Но по мере того, как проект становится устойчивее, акцент смещается. LiveOps начинает заниматься уже не только исправлениями, но и развитием продукта.

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

Игровые события и новый контент

Для live-service проекта недостаточно один раз выпустить хороший набор контента.

Игрокам нужен повод возвращаться.

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

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

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

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

Баланс и игровая экономика после релиза

До запуска невозможно идеально предсказать, как реальные игроки будут взаимодействовать с экономикой.

Какие предметы они получают слишком быстро? Где возникает дефицит? Какие награды перестают ощущаться ценными? На каком этапе игроки перестают прогрессировать?

После появления реальных данных часть предположений приходится пересматривать.

LiveOps-команда помогает вносить такие изменения без разрушения уже работающей игры.

Особенно аккуратного подхода требуют free-to-play проекты. Слишком резкое изменение цены, награды или прогрессии может непосредственно повлиять на поведение аудитории.

Поэтому баланс после релиза — это не разовое исправление таблицы, а постоянная работа с продуктом.

Техническая поддержка и обновления

Игра продолжает существовать в меняющейся среде.

Выходят новые версии Android и iOS, обновляются консольные SDK, меняются сторонние сервисы и требования магазинов.

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

LiveOps-команда следит за такими зависимостями и поддерживает проект в рабочем состоянии.

Сюда же относится обновление рекламных, аналитических и платежных SDK, серверных библиотек и других внешних компонентов.

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

Почему QA остаётся важным после релиза

Чем чаще выходит новый контент, тем выше риск сломать что-то уже работающее.

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

Поэтому QA после релиза никуда не исчезает.

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

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

Причём полезно выстраивать этот процесс ещё до запуска. В материале «QA до content lock: что тестировать раньше» как раз разобрано, почему откладывать полноценную проверку до последней стадии разработки рискованно.

LiveOps и backend

Для онлайн-игры значительная часть LiveOps происходит вообще за пределами клиента.

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

Чем больше таких параметров можно безопасно менять удалённо, тем меньше зависимость от очередного обновления приложения.

Но здесь появляется и обратная сторона.

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

Поэтому иногда одна из первых задач после запуска — не новый пользовательский контент, а улучшение внутренних инструментов.

Игрок этого напрямую не увидит, зато следующие обновления станут заметно быстрее и безопаснее.

Кто должен заниматься LiveOps

Необязательно сохранять всю production-команду после релиза.

Во многих проектах это просто невыгодно.

Во время активной разработки могут одновременно работать gameplay developers, несколько художников, аниматоры, level designers и другие специалисты. После запуска потребность в части ролей снижается.

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

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

Другой вариант — передать поддержку внешней команде почти полностью, оставив внутри компании product owner и людей, принимающих ключевые решения.

Когда LiveOps можно передать на аутсорс

Такой формат особенно удобен, когда основная команда уже переходит к следующему проекту.

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

Внешняя команда может постепенно принять кодовую базу, release pipeline и текущий backlog.

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

Если же игра уже выпущена, но накопила технические проблемы, перед обычным LiveOps иногда стоит сначала провести аудит и доработку существующей игры.

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

Как понять, что проекту уже нужна отдельная LiveOps-команда

Самый очевидный признак — production после релиза перестаёт помещаться между другими задачами.

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

Ещё один сигнал — зависимость от нескольких ключевых разработчиков. Если только один человек знает, как выпустить сервер или собрать новую версию, проект становится слишком хрупким.

В этот момент LiveOps перестаёт быть «небольшой поддержкой после релиза» и становится самостоятельным production-процессом.

И лучше признать это раньше, чем очередное обновление снова придётся собирать в авральном режиме.

LiveOps не нужен каждой игре

Не любой проект должен превращаться в бесконечный сервис.

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

Создавать полноценную LiveOps-инфраструктуру в таком случае необязательно.

Другое дело — multiplayer, free-to-play, мобильные игры и проекты, которые рассчитывают на долгий жизненный цикл. Здесь способность быстро менять продукт становится частью самой разработки.

Поэтому решение о LiveOps лучше принимать исходя не из модного термина, а из того, как игра должна жить после запуска.

Что в итоге решает LiveOps для игр

Хороший LiveOps для игр делает пострелизную работу предсказуемой.

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

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

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

Если игра уже находится в эксплуатации или только готовится к долгому post-launch периоду, можно обсудить LiveOps и поддержку проекта с NoPanic Studio.