Настройка удаленного управления параметрами (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. Лечить накопленный хаос дольше, чем выстроить схему с нуля.