Реліз пройшов, білд у сторах — і ви розумієте, що хочете змінити баланс: збільшити вартість ресурсу, знизити шкоду боса, скоригувати частоту спавну. Без віддаленої конфігурації це тижневий цикл: патч, рев'ю Apple/Google, очікування. З ним — виправлення значення в консолі та миттєве застосування для потрібного сегменту гравців. Середній час доставки змін — 1–2 секунди після публікації. Використання Remote Config скорочує час випуску змін у 10 разів порівняно з традиційним патчем. За 8 років роботи з геймдев-проєктами ми впровадили віддалену конфігурацію у більш ніж 20 ігор, від гіперказуалок до RPG. Економія часу на патчі — до 90%, зниження витрат на QA при A/B-тестуванні ігор — до 60%.
Firebase Remote Config — не просто key-value сховище. Правильно спроєктована схема параметрів перетворює його на повноцінний інструмент A/B-тестування та Managed Rollout. Відповідно до документації, кешування за замовчуванням становить 12 годин.
Чому віддалена конфігурація критичний для live-операцій?
Типова помилка при самостійній інтеграції — складати всі параметри в один Default Config без структури. Через три місяці активної роботи з балансом у консолі Firebase накопичується 80+ параметрів з іменами на кшталт enemy_dmg_2, enemy_dmg_2_new, enemy_dmg_final. Жодного namespacing, жодної документації, параметри дублюються. У 95% проєктів-новачків ми знаходимо цю проблему.
Друга проблема — ігнорування кешу. remoteConfig.fetchAndActivate() за замовчуванням кешує значення на 12 годин. У продакшені це нормально, але в режимі розробки команда втрачає години, не розуміючи чому зміни в консолі не застосовуються. Мінімальний інтервал для dev-середовища виставляється через remoteConfig.settings.minimumFetchIntervalMillis = 0, і це потрібно робити через #if DEVELOPMENT флаги, а не забувати прибирати перед релізом.
Третя — відсутність fallback-значень на клієнті. Якщо віддалена конфігурація недоступний (офлайн, помилка мережі), гра повинна працювати з вшитими 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.
Як працює Managed Rollout?
Managed Rollout — поетапне застосування конфігурації: спочатку на 1% аудиторії, потім збільшення до 5, 20, 50, 100%. Якщо на якомусь етапі метрики (retention, revenue, crash rate) просідають, відбувається автоматичний відкат до попередньої стабільної версії. Це знижує ризик від поганих налаштувань і дозволяє безпечно експериментувати навіть із критичними параметрами балансу.
Які інструменти використовуємо?
На 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-файл у білді.
Гарантуємо сумісність з Unity 2022+ та Unreal Engine 5. Над проєктами працюють інженери з сертифікацією Firebase. За 8 років досвіду та 5 років на ринку ми виконали понад 20 проєктів, середня оцінка клієнтів — 4.9/5.
Етапи роботи
- Аудит поточних хардкодів — шукаємо в проєкті значення, які повинні бути конфігурованими. Зазвичай це баланс юнітів, параметри економіки, feature flags, інтервали показу реклами. Економія часу на патчі — до 90%.
- Проєктування схеми — namespacing параметрів, JSON vs flat keys, версіонування конфіга.
- Інтеграція SDK — правильна ініціалізація, обробка офлайну, dev/prod конфіг інтервали.
- Налаштування умов та аудиторій — підключення до Firebase Analytics для сегментації.
- A/B тест пілот — налаштування першого експерименту, перевірка івентів у DebugView.
- Документація схеми — таблиця параметрів з описом, діапазонами значень, власником (геймдизайнер/програміст).
Що входить у результат
| Складова | Опис |
|---|---|
| Схема параметрів | JSON-структура з namespacing, версіонуванням та fallback-значеннями |
| Інтеграція SDK | Коректна ініціалізація, обробка офлайну, dev/prod конфіги |
| Налаштування умов | Сегментація за країною, версією, аудиторією Analytics |
| A/B-експеримент | Пілотний тест із метрикою retention/purchase |
| Документація | Таблиця параметрів із власниками, діапазонами |
| Підтримка | Консультації 2 тижні після впровадження |
Вартість інтеграції починається від $1,500, економія ресурсів — до $8,000 на місяць. Часта помилка: дублювання хардкодів. Якщо в проєкті вже є часткова інтеграція Remote Config, часто виявляємо: параметри дублюють хардкоди в коді (значення з Remote Config ігнорується через помилку в ключі), умови в консолі налаштовані неправильно (відсоток аудиторії не сумується до 100), метрики A/B тесту не пробрасовуються в Analytics. Лікувати накопичений хаос довше, ніж вибудувати схему з нуля.
Зв'яжіться з нами для оцінки вашого проєкту. Замовте консультацію з інтеграції Remote Config — наші інженери проаналізують код і запропонують оптимальну схему.