Remote Config Parameter Management Setup
Release is out, build in stores — and realize want to change balance: increase resource cost, lower boss damage, adjust spawn frequency. Without Remote Config this is patch, Apple/Google review, waiting. With it — change value in console and instant apply for needed player segment.
Firebase Remote Config is not just key-value store. Properly designed parameter scheme turns it into full A/B-testing and managed rollout tool.
Where "obvious" integration usually breaks
Typical self-integration mistake — dump all parameters into single Default Config without structure. After three months active balance work accumulate 80+ parameters with names like enemy_dmg_2, enemy_dmg_2_new, enemy_dmg_final. No namespacing, no docs, parameters duplicate.
Second problem — ignore caching. remoteConfig.fetchAndActivate() by default caches values for 12 hours. Production is normal, but in dev mode team loses hours not understanding why console changes don't apply. Minimum interval for dev-environment set via remoteConfig.settings.minimumFetchIntervalMillis = 0, and must be done via #if DEVELOPMENT flags, not forget remove before release.
Third — no fallback-values on client. If Remote Config unavailable (offline, network error), game should work with embedded defaults, not crash or show zero balance values.
How we build parameter scheme
For average mobile game with several unit classes and game modes optimal is JSON-structure inside one parameter instead of hundred flat keys. One parameter balance_config contains JSON with nested structure:
{
"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
}
}
On client JSON parsed once on session start and laid into ScriptableObject or static config class. Handier than 40 separate remoteConfig.GetValue("key") calls.
Conditions and personalization. Firebase Remote Config supports conditions by platform, app version, audience (via Firebase Analytics), country. Typical scenario: parameter first_purchase_bonus returns 50 for new users (audience new_user in Analytics) and 20 for others. This not A/B test — segmented configuration, configured without client code changes.
A/B tests via Remote Config. Google Optimize deprecated, Firebase A/B Testing natively integrated. Create experiment right in console: variant A — spawn_interval: 8.0, variant B — spawn_interval: 5.0, metric — D1 retention. 50/50 split, launch on 10% audience. Client code doesn't know about experiment — just reads spawn_interval parameter.
Stack and tools
On Unity-projects use Firebase Unity SDK 11.x. Initialization is async — wait FirebaseApp.CheckAndFixDependenciesAsync() before first fetch. On Unreal-projects Firebase Remote Config available via C++ SDK or FirebaseFeatures plugin (Epic Marketplace).
For games on own server instead of Firebase raise GrowthBook or own Redis + API solution: parameters stored in Redis with TTL, client gets them via REST on session start, fallback — embedded JSON-file in build.
Work stages
- Audit current hardcodes — find values that should be configurable. Usually balance units, economy params, feature flags, ad show intervals
- Design scheme — parameter namespacing, JSON vs flat keys, config versioning
- SDK integration — correct initialization, offline handling, dev/prod config intervals
- Setup conditions and audiences — connect to Firebase Analytics for segmentation
- A/B test pilot — setup first experiment, verify events in DebugView
- Document scheme — parameter table with descriptions, value ranges, owner (designer/programmer)
| Task Scope | Duration |
|---|---|
| Integrate Remote Config in ready project (up to 30 params) | 2–4 days |
| Design scheme + integration + first A/B test | 1–2 weeks |
| Full system with segmentation, experiments, documentation | 3–5 weeks |
Cost determined individually after project analysis and current architecture.
What to check before start
If project already has partial Remote Config integration — first audit. Often find: parameters duplicate hardcodes in code (Remote Config value just ignored due to typo in key), conditions in console misconfigured (audience percentage doesn't sum to 100%), A/B test metrics not pushed to Analytics. Healing accumulated chaos takes longer than building scheme from scratch.