Підтримка та розвиток гри після релізу
Реліз — це не фінальна крапка. Для більшості проектів саме тут починається основна робота: перші живі користувачі знаходять баги, які не відтворювалися на QA, метрики утримання показують падіння на певних екранах, а аудиторія чекає на новий контент. Без налагодженої системи підтримки проект починає деградувати протягом перших тижнів після релізу.
Що входить у підтримку
- Виправлення багів і патчі — оперативне виправлення критичних дефектів, збирання та публікація гарячих патчів в App Store / Google Play / Steam
- Контентні оновлення — нові рівні, персонажі, події, балансування
- Технічні оновлення — міграція на нові версії Unity/Unreal, оновлення SDK (Firebase, Adjust, AppsFlyer), відповідність новим вимогам платформ
- Поліпшення онбордингу — доробка навчання на основі даних аналітики
- Механіки утримання — щоденні нагороди, push-повідомлення, сезонні події
Live Ops Pipeline та Remote Config
Найцікавіша частина підтримки після релізу — це не патчі, а live ops: здатність змінювати поведінку гри без перевидання додатку. Правильно побудований pipeline дозволяє змінити баланс, включити подію або протестувати нову монетизаційну механіку за 15 хвилин, не чіпаючи збірку.
Архітектура Remote Config
Типова схема виглядає так:
Dashboard / CMS
↓
Remote Config Provider (Firebase / PlayFab)
↓
Game Client (fetch на старті сесії + періодичний 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, кастомні native плагіни). Backtrace краще декодує символи для native крашей і зручніший для команд, де кілька людей працює над native кодом.
Для 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 годин. Усі зміни проходять через staging-окруження перед деплоєм у прод — це стосується як Remote Config, так і кодових змін.