Настройка удаленного управління параметрами (Remote Config) ігор
Релиз пройшов, білд в сторах — і розуміємо, що хочемо поміняти баланс: підвищити вартість ресурсу, знизити шкоду босса, скорегувати частоту спавну. Без Remote Config це патч, ревю Apple/Google, очікування. З ним — правка значення в консолі та миттєве застосування для потрібного сегменту гравців.
Firebase Remote Config — не просто key-value сховище. Правильно спроектована схема параметрів перетворює його в повноцінний інструмент A/B-тестування та managed rollout.
Де звичайно ломається «очевидна» інтеграція
Типова помилка при самостійній інтеграції — складувати все параметри в один Default Config без структури. Через три місяці активної роботи з балансом у консолі Firebase накопичується 80+ параметрів з іменами вроде enemy_dmg_2, enemy_dmg_2_new, enemy_dmg_final. Ніякого namespacing, ніякої документації, параметри дублюються.
Друга проблема — ігнорування кешу. remoteConfig.fetchAndActivate() за замовчуванням кешує значення на 12 годин. В продакшені це нормально, але в режимі розробки команда втрачає години, не розуміючи чому зміни в консолі не застосовуються. Мінімальний інтервал для dev-окруження встановлюється через remoteConfig.settings.minimumFetchIntervalMillis = 0, і це потрібно робити через #if DEVELOPMENT флаги, а не забувати убирати перед релізом.
Третя — відсутність fallback-значень на клієнті. Якщо Remote Config недоступний (офлайн, помилка мережі), гра повинна працювати з вшитими defaults, а не падати або видавати нульові значення баланса.
Як будуємо схему параметрів
Для середньої мобільної гри з кількома класами юнітів та кількома ігровими режимами оптимальна JSON-структура всередину одного параметра замість сотні плоских ключів. Один параметр balance_config містить JSON з вкладеною структурою:
{
"enemies": {
"goblin": { "hp": 120, "dmg": 15, "spawn_weight": 0.4 },
"troll": { "hp": 400, "dmg": 35, "spawn_weight": 0.1 }
},
"economy": {
"coin_multiplier": 1.2,
"ad_reward_gems": 10
}
}
На клієнті JSON парсується один раз при старті сесії та розкладається в ScriptableObject або статичний клас конфіга. Це зручніше, ніж 40 окремих викликів remoteConfig.GetValue("key").
Умови та персоналізація. Firebase Remote Config підтримує умови по платформі, версії додатку, аудиторії (через Firebase Analytics), країні. Типовий сценарій: параметр first_purchase_bonus повертає 50 для нових користувачів (аудиторія new_user в Analytics) та 20 для решти. Це не A/B тест — це сегментирована конфігурація, й настроюється вона без змін клієнтського коду.
A/B тести через Remote Config. Google Optimize застарів, Firebase A/B Testing інтегрований нативно. Створюємо експеримент прямо в консолі: варіант A — spawn_interval: 8.0, варіант B — spawn_interval: 5.0, метрика — retention D1. Розподіл 50/50, запуск на 10% аудиторії. Клієнтський код не знає про експеримент — просто читає параметр spawn_interval.
Стек та інструменти
На Unity-проектах використовуємо Firebase Unity SDK 11.x. Ініціалізація асинхронна — чекаємо FirebaseApp.CheckAndFixDependenciesAsync() перед першим fetch. На Unreal-проектах Firebase Remote Config доступний через C++ SDK або плагін FirebaseFeatures (Epic Marketplace).
Для ігор на власному сервері замість Firebase піднімаємо GrowthBook або власне рішення на Redis + API: параметри зберігаються в Redis з TTL, клієнт отримує їх через REST при старті сесії, fallback — вшитий JSON-файл в білді.
Етапи роботи
- Аудит поточних хардкодів — шукаємо в проекті значення, які повинні бути конфігурованими. Зазвичай це баланс юнітів, параметри економіки, feature flags, інтервали показу реклами
- Проектування схеми — namespacing параметрів, JSON vs flat keys, версіонування конфіга
- Інтеграція SDK — правильна ініціалізація, обробка офлайну, dev/prod конфіг інтервали
- Настройка умов та аудиторій — підключення до Firebase Analytics для сегментації
- A/B тест пілот — настройка першого експерименту, перевірка івентів в DebugView
- Документація схеми — таблиця параметрів з описом, діапазонами значень, власником (геймдизайнер/програміст)
| Масштаб задачі | Термін |
|---|---|
| Інтеграція Remote Config у готовий проект (до 30 параметрів) | 2–4 дні |
| Проектування схеми + інтеграція + перший A/B тест | 1–2 тижні |
| Повна система з сегментацією, експериментами та документацією | 3–5 тижнів |
Вартість розраховується індивідуально після аналізу проекту та поточної архітектури.
Що варто перевірити перед початком
Якщо в проекті вже є часткова інтеграція Remote Config — спочатку аудит. Часто обнаруживаємо: параметри дублюють хардкоди в коді (Remote Config значення просто ігнорується через опечатку в ключі), умови в консолі настроєні неправильно (відсоток аудиторії не сумується до 100%), метрики A/B тесту не пробрасуються в Analytics. Лічити накопичений хаос довше, ніж вистроїти схему з нуля.