Remote Config technology became widely popular thanks to Firebase, which made it accessible to a broad audience of developers. However, it is far from being the only solution on the market, not to say that it’s far from perfect. This article will reveal why Firebase Remote Config became obsolete and what you can do about it.
What is a Remote Config?
Remote Config is a cloud service that helps developers change the appearance or functionality of their apps remotely (without requiring users to download an app update). This technology is actively used in the gaming industry, especially for LiveOps.
Remote Config, as you know it, hasn’t changed for a long time. Usually, it’s simple key-value storage, which is very limited by definition. What would you say if I told you – there is much more advanced technology which makes Remote Config obsolete?
The most common workflow with the Remote Config looks the following: teams develop their game balance data using spreadsheets and later add Remote Config on the top of the implemented game.
And now, imagine a synergy of spreadsheets and Remote Config. Do you see it? You are thinking about Balancy right now!
Balancy vs. Firebase
Let’s compare Balancy and Firebase Remote Configs:
- Supported types
| Type | Number | String | Bool | JSON | Reference | List | Sprite | Enum | Date |
| Balancy | + | + | + | – | + | + | + | + | + |
| FireBase | + | + | + | + | – | – | – | – | – |
As you can see, Balancy supports many more parameters. The only type Balancy doesn’t offer is JSON because you don’t need to work with JSON when you have Balancy. You can read about it in the next section.
On top of the parameters listed in the table, Balancy has many other types, which were created for your convenience: duration, in-app product, unity addressable, and localized string.
- No need to work with JSON
JSON is a great format, but it’s time-consuming to work directly with it. Obviously, you can’t fit everything you need into simple type parameters such as number, string, and bool. That’s why Firebase introduced JSON parameters.
In Balancy, you just don’t need a JSON type. You think about JSON when it comes to complex data. It’s straightforward to create any kind of data with any complexity or depth and then use it as a reference.
- Convenience for programmers
Let’s assume you have a parameter called TestName of a string type in both Balancy and Firebase. Let’s assume both solutions were added to the game and properly initialized. Now we need to read this TestName parameter:
Firebase:
It’ll take around 30-40 lines of code to read the value because you need to hardcode default values and take care of all the exceptions. Take a look at this example if you don’t believe me.
Balancy:
Just one line of code will give you what you want:
Balancy.DataEditor.RemoteConfig.TestName
All that is possible due to our code generation feature. The code our system generates is responsible for loading and mapping all your data to convenient classes.
- Summary
| Feature | Balancy | Any Remote Config | Spreadsheets |
| History of changes | + | + | + |
| Safe Deployment | + | + | – |
| Simple Types | + | + | + |
| References, Date, Enum | + | – | + |
| Lists, Images, and Assets | + | – | – |
| A/B test | + | + | – |
| Personalization | + | + | – |
| Easy integration | + | – | – |
| Code Generation | + | – | – |
| Store Game Data | + | – | + |
| Real human Support | + | – | – |
Final thoughts
Even though we were comparing Balancy with Firebase, all other solutions – such as GameAnalytics or Unity – have absolutely the same remote configs as Firebase.
To summarize, you can almost avoid using spreadsheets and keep all your game data in Balancy. Engineers will be grateful because no additional work is required to bring this data to a game. Once your data is in Balancy, it becomes one huge Remote Config. This means you can change any parameter remotely, run A/B tests, or add personalization to any data stored in Balancy.