Поддержка и развитие игры после релиза
Релиз — это не финальная точка. Для большинства проектов именно здесь начинается основная работа: первые живые пользователи находят баги, которые не воспроизводились на QA, метрики удержания показывают провалы на определённых экранах, а аудитория ждёт новый контент. Без выстроенной системы поддержки проект начинает деградировать в течение первых недель.
Что входит в поддержку
- Баг-фиксинг и патчи — оперативное исправление критических дефектов, сборка и публикация хотфиксов в App Store / Google Play / Steam
- Контентные апдейты — новые уровни, персонажи, события, баланс
- Технические обновления — миграция на новые версии Unity/Unreal, обновление SDK (Firebase, Adjust, AppsFlyer), соответствие новым требованиям платформ
- Ачивменты и туториалы — доработка онбординга по данным аналитики
- Retention-механики — ежедневные награды, push-уведомления, сезонные события
Live Ops Pipeline и Remote Config
Самое интересное в пост-релизной поддержке — это не патчи, а live ops: способность менять поведение игры без перевыпуска приложения. Правильно выстроенный pipeline позволяет изменить баланс, включить ивент или протестировать новую монетизационную механику за 15 минут, не трогая сборку.
Архитектура Remote Config
Типичная схема выглядит так:
Dashboard / CMS
↓
Remote Config Provider (Firebase / PlayFab)
↓
Game Client (fetch on session start + периодический polling)
↓
Local Cache (fallback при отсутствии сети)
Firebase Remote Config — наиболее распространённое решение для мобильных игр. Ключи хранятся в консоли, клиент получает их при старте сессии через RemoteConfig.FetchAndActivateAsync(). Важный момент: Firebase кэширует значения на 12 часов по умолчанию, и в продакшне нужно явно настраивать minimumFetchInterval — иначе изменения в конфиге не дойдут до пользователей вовремя. Для живых ивентов используем minimumFetchInterval = 0 с ручным throttling на клиенте.
PlayFab даёт больше возможностей для game-специфичных сценариев: Title Data, Player Data, CloudScript. Удобно для серверной валидации покупок, хранения прогресса игрока и A/B-тестирования сегментов. Если у игры есть серверная составляющая (PvP, leaderboards, инвентарь), PlayFab часто выгоднее Firebase по совокупности функций.
Типичная структура ключей Remote Config
| Ключ | Тип | Пример значения |
|---|---|---|
event_halloween_active |
bool | true |
event_halloween_end_ts |
long | 1730332800 |
iap_sale_multiplier |
float | 2.0 |
tutorial_skip_enabled |
bool | false |
daily_reward_sequence |
JSON | [10, 20, 50, 100, 200] |
ads_interstitial_cooldown_sec |
int | 120 |
Хранить в Remote Config стоит только то, что реально меняется. Константы геймплея, которые не трогались год — не кандидаты для Remote Config, они только засоряют схему.
A/B-тесты через Remote Config
Firebase поддерживает A/B-тестирование нативно через Firebase A/B Testing. Настраивается группа экспериментов с разными значениями ключей, платформа сама распределяет пользователей и собирает статистику по целевым метрикам (retention D1/D7, revenue, custom events).
Важно: один пользователь должен всегда попадать в одну и ту же группу. Firebase это гарантирует через привязку к Installation ID. Если тест завязан на монетизацию — дополнительно проверяем через Unity Analytics или Amplitude, что распределение покупок между группами случайное, а не артефакт сегментации.
Crash Reporting и мониторинг стабильности
Без crash reporting вы узнаёте о критических багах от пользователей в отзывах, а не из дашборда.
Firebase Crashlytics — стандарт для мобильных игр. Интегрируется через Firebase SDK, автоматически фиксирует необработанные исключения C# и native crashes (включая IL2CPP). Ключевые метрики, за которыми следим ежедневно:
- Crash-free users rate — должен быть выше 99.5% для стабильного проекта
- ANR rate (Android Not Responding) — частая проблема при тяжёлых загрузках на главном потоке
- Top crashes по количеству затронутых пользователей — не по количеству событий
Backtrace используем для проектов с нативным кодом или сложной C++ составляющей (Unreal, кастомные нативные плагины). Backtrace лучше декодирует символы для нативных крашей и удобнее для команд, где над нативным кодом работают несколько человек.
Для Unity-проектов также настраиваем Unity Cloud Diagnostics — даёт дополнительный контекст по ошибкам движка.
Аналитика и итерация контента
Unity Analytics (бывший Unity Gaming Services Analytics) используем для трекинга воронок и событий внутри игры. Для более сложных сценариев — собственный event pipeline с отправкой в BigQuery или ClickHouse.
Минимальный набор событий, который должен быть в любой игре с поддержкой:
-
session_start/session_end(длина сессии) -
level_start/level_complete/level_fail -
tutorial_step_N -
iap_purchase/ad_watched -
feature_unlocked
По этим данным видно, где аудитория отваливается, какой контент не работает и куда вкладывать силы следующего апдейта.
Процесс работы
Для проектов на поддержке используем выделенный ритм: еженедельные отчёты по метрикам, спринты по 2 недели для контентных апдейтов, дежурный инженер на критические баги с SLA до 24 часов. Все изменения проходят через стейджинг-окружение перед деплоем в прод — это касается и Remote Config, и кодовых изменений.