Does the client side auto-refresh / update if values changed in the Dashboard ?

Hi,

I've just integrated the Remote Configs feature and so far so good! I'm curious whether modified Remote Config values (configs) will be automatically sent to the client when 1 or more config values are modified in the web dashboard?

In other words, will the event listening to ConfigManager.FetchCompleted automatically be fired on a config modification, or does my code have to periodically run ConfigManager.FetchConfigs and then the check the ConfigResponse parameter for a ConfigOrigin.Remote result (i.e. to indicate configs were updated from the server) ?

A follow-up question is if I call ConfigManager.FetchConfigs multiple times is there any way for me to know whether the config values have been modified since my last fetch? This is a very useful feature so I can check whether I have to run through all of my own update/refresh logic or not. Right now it looks like there is no way to know that.

Thanks,
Andrej

 

Hi @vd_unity,

Thanks for the reply. My understanding is the older Remote Settings feature would auto-update whenever a config value was changed, which was very useful at runtime. Remote Settings was integrated earlier by a colleague of mine and he demoed that feature.

Being notified at runtime of a config variable change is very useful. Some use cases that come to mind:

• Notification messages. Say I want to send a message to players about free loot. It would be great if players can get that message live, while playing the game, rather than just on app startup.
• You want to set some kind of bonus (e.g. 50% more ammo) and then scale it down at various intervals. You would want this to apply to players who are playing live.
• New service urls: you need to update the matchmaking service url for a particular region because it's getting overloaded.

In terms of how I would hope the system would work:

• When you launch your app you call ConfigManager.FetchConfigs to get all your configs (as it does now).
• Any subsequent time you call ConfigManager.FetchConfigs (while the game is running), it will get all the configs. This is if you really just want a complete refresh.
• If any configs are updated while the game is running then a separate callback/event is fired (e.g. ConfigsUpdated). The payload for this event would be json that contains only the updated config variables. This way the game gets notified at runtime and one can make an informed decision if there is any follow-up logic that needs to execute based on the updated config variables.

Cheers,
Andrej

 

Hi @rambod I'm double-checking with the colleague who demoed as to whether he did any custom code to make it happen and will get back to you.

In terms of how it would work, I imagine you would have a service that the Unity Engine would call regularly to see if there are any new changes to the Remote Config and the response would only include those kvps that changed. The response data could be sent as an event to the client code.

Cheers,
Andrej

 

Hi @rambod,

I'm not worried because if you're actively playing a game the sending of a RemoteConfig heartbeat every 30 sec or so is very minor in comparison. I'm not suggesting this heartbeat run as a background process, but only while a game is running (in the foreground). And most of the time I imagine the heartbeat would simply return a very small "no changes" response.

Pretty much all mobile games already run things like error reporting and analytics as well. In general it's probably a good idea to have a general Unity heartbeat method, which can be used to check on any of the services that a Unity developer might use/subscribe to from Unity (now or what may come in the future).

Cheers,
Andrej

 

Is there any new progress on your solution?

I wanted to understand how my code would know, which value from the remote server was updated, if it did from the multiple other values, so that I could work with it in other parts of my game.

 

Hello, we too would benefit from a config changed API.

Hey, we implemented converted our config object to json and then hashed it. Then we compare the hash of the original data with the current data to determine whether or not there has been a change.

I can give you our scenario. We store our Maintanance data in the config. If it's changed, we want to know so we can express it on the client. Sending ConfigFetches frequently and checking for changes seems a bit cumbersome, since our config is pretty large (nearing the 10k character limit).