So, my usecase is the following. I have a Game Client that communicates with our Backend Servers. The backend servers are responsible for maintaining the Game Config (such as store item costs, missions, talents, drops, etc). The game client fetches everything during initialization. When a player wants to claim a mission’s reward, for example, the client would send the mission_id to our backend and the backend would check what rewards it should give for the player based on the Game Config (which is stored in-memory). That behavior works the same way for every single operation that involves the Game Config.
We are thinking about moving the Game Config to a third-party service that could offer A/B Testing, Segmentation, and so on. Since we are already using Unity, using Unity’s Remote Config seems like a good option. The problem is that I did not see how to fit our usecase. The way I thought it would work was that Remote Config would have an api that received player’s parameters (like DSI, and some custom params) and would return the appropriate config for that player. However, I did not find that in the REST API Docs. The only available endpoint was to retrieve a config by ID, so we would kinda lose the ability to do A/B Testing and Player Segmentation.
Economy would handle all the Items and balances for your game. While Remote Config and Player Engagement/GameOverrides would handle the A/B testing/Segmentation. You could also include Analytics to really start learning more about your players.
Regarding integrating in your current setup. I would need to create a feature request so that the API would return more than just the config by id.
Please let me know if you need more information or guidance.
Its ok! We can’t really use Unity’s backend because we have some huge particularities in our game (it is web3) and we already have all of those setup. We just needed a way to know which config a player is currently placed in. For example, if the Client SDK returned the Config ID that the player is using, it could tell us through the API so we could get it from our backend by using the Admin SDK. That is not possible at the moment, right?
That isn’t possible right now but believe this is a good use case.
I will bring your feedback to the rest of the team. Keep your eye on the forums to see if this feature gets released.
I see. Ok!
Just to make it more “formal”, I would give two options that would make backend engineers life easier with the Remote Config:
Expose an API (or put this in an SDK) that would receive the player’s current attributes and evaluate its configuration. From what I saw, Unity’s RC store the player’s attributes in its DB and uses the auth header to know what player it is. From my experience, that seems like a poor design because it excludes many usecases (such as mine). It does not make much sense to force people to use Unity’s Authentication since they already have the player’s attributes in the device. For an example of what I am talking about, you can check the Flagsmith service. That is pretty much what I would say would be the ideal.
Return the Config ID when the Client SDK fetches the player’s config. This way, clients could send their config ids together to a backend server, and with that info the backend knows the correct config the player is using.
From the two options, the first one seems way more “engineered” and makes more sense since it would cover a lot of usecases.
Hi, I’m the product manager for Remote Config and I thought I’d clarify a few things. Remote Config has become a very powerful product but there are some things to take into consideration.
So remote config allows for stateless and stateful targeting. Stateful uses the data we have received from Unity Analytics so you can create an audience based on historic data and target that. Stateful uses the data that is sent along with the request and you can target based on that data using JEXL, you can send along any custom data you have available when you do the request. and it is sent in the assignSettings endpoint, you can find more information on that here. (Look at attributes>user for custom values to send along)
We have the dependency on authentication and the core package so we can identify the player in analytics and make sure that an a/b test assignment is sticky, if a player logs in on another device ideally they would get the same configuration. But if you would like to use another ID for A/B stickiness then that is possible, you just pass it in as the customUserId.
One feature you could use instead of the config ID is the configAssignmentHash this is a unique ID for the configuration and you can find more info on that here.
The way we do a/b testing is not by a/b testing a complete configuration, you would run an a/b test on a piece of content (e.g. level difficulty) this means you’ll be able to run another a/b test on a different key (e.g. the welcome message)
The A/B test uses overrides and creates a group where 50% doesn’t get a change while the other 50% will. Doing another A/B test will randomly assign from the total group meaning that there is no correlation between the two A/B tests. The configAssignmentHash is created to be able to link to an exact configuration that might be unique to that player.
If the dependency on core / auth is a concern you can use the 2.1.x package version documented here which does not have that hard dependency, however, using the most up to date version should not prevent your use case. Authentication can be done anonymously so no need for your users to sign in (this is the strategy promoted in the docs for Remote Config). Please correct me if I’m missing something but I believe the first option you described is possible with the current SDK or API.
To achieve this, you could:
Use the current SDK and sign in anonymously as seen in documentation or if that doesn’t work for your game use the 2.1.x package version to avoid authentication entirely