We've started testing experiments and have a few questions/requests.
In our game we have a function that syncs the local and server virtual good costs. When an experiment is running, I can see the values that come from the server changing which is great. However, the server could send different costs even if an experiment isn't running. For example, when we change the actual virtual good cost on the server and don't update our local settings file.
Is there a way to know if a specific experiment is running through code and not just by checking the virtual good cost changes?
Experiments don't seem to be saved as runtime/metadata/etc collections. If they were exposed, then we could check their status in code to see if they are running. This would be useful to know so in game we could change our store assets to reflect the value of the experiment (e.g. -20%)
Is it possible to receive notifications/callback when an experiment status changes?
At the moment experiments only support virtual goods.
It would be great if we could create an experiment that instead of using virtual goods, it would use a set of custom parameters. This way we would be able to create game Events using Experiments.
Custom parameters could be generic fields (e.g. image below) that we could then access in code.
Do you have any plans to support this sort of thing?
Any chance you guys could answer the question above?
Apologies for the delayed response here. We'll get someone to look into this for you and post an update soon.
1) - You can retrieve what segments of an experiment a player is taking part in though SparkPlayer.getExperimentSegments(). You can create an event that will check this for a certain player and experiment.
2) - Not traditionally no, unless experiments were altered manually (via the rest api for example) which would be followed by a custom ScriptMessage that you would send to all players, which is less than desirable.
If you would like to, please log your request on our Feature Requests forum! We are constantly improving the platform and are still fixing issues related to the new portal's release, but we will get to these as soon as we can.
Thanks for your reply.
I have created a separate post on the Feature Requests regarding the request above.
1) I tried your suggestion using the code below. However, this seems quite limited.
I assumed that getSegmentName() would return the actual experiment name. Instead it returned the name I added to the Player Pool's Variant Configuration.
Is there a way to retrieve the virtual good Ids used and the percentages of each currency slot?
Unless we give a very meaningful name to the variant configuration to include the virtual goods category and say -20%. We could then split the string to get that information. Otherwise, there doesn't seem to be another way to do this.
getExperimentId() only returns a number that doesn't seem to mean anything.
var experimentSegments = Spark.getPlayer().getExperimentSegments();
if (experimentSegments !== null)
for (var index = 0; index < experimentSegments.length; ++index)
var experiment = experimentSegments[index];
var experimentId = experiment.getExperimentId();
var experimentName = experiment.getSegmentName();
This was the documentation I could find:
2) I guess as a work around we just have to ask the server for the current player experiments every time we open the Shop screen for example. Is this correct?
Shall I just add these 2 points as feature requests too? It seems to be they should be part of the system as a given.
Any thoughts on this?
1) - While there isn't a way to retrieve the percentage differences between VG's in a request, you can still perform this operation. By doing a ListVirtualGoodsRequest, or finding the specific Virtual Good for that Player in Cloud Code, you'll notice that the items that have been segmented for experiments have both a currency cost and a "baseCurrencyCost", which is the original cost before the variant was initiated.
2) - Yes this seems like a likely solution. If you would like to add the above as feature requests, we are scheduled to discuss the further application of Experiments very soon and would love additional feedback.