I can think of at least three ways to model experience points using PlayFab:
Which of these, if any, is the one that PlayFab intended to be used for the purpose of storing a player's (or character's) experience points?
There's no single "right" answer, but in general I'd recommend using a Statistic (as long as you don't need more than 32 bits to represent the value). That way, you can use it in user segmentation as a measure of user engagement. Total time spent playing the game is also a good one to use.
Also, I wouldn't recommend updating anything at a high rate. In general, aggregating values for some period of time before "committing" them to the service is a good best practice to help keep your costs down. And in many cases, it makes the cheat evaluation part of your script or server logic easier, since you don't have to carry as much info from previous reported values from the client.
You rob me of the ability to accept your answer every time.
I like the independent nature of a statistic - although an object is relatively independent, too. Anyway, a statistic was my first guess, so this makes sense to me.
Batching up writes sounds like an optimization that can be made later and I wonder what the price tag on the batching actually is. So I make an Azure Durable Function to wait for a while and accumulate some state changes before writing to PlayFab. Isn't that just moving write calls to Azure Function calls and adding some storage costs on top of it?
Or are you talking about having the client do the batching? I guess I could see that for some games.
What I really mean is aggregating values per "key" over time. So, instead of writing to a summed statistic 5, then another 5, then 6, then 4, then 8 over a session, you'd wait until the end and just write 28.
I can see how that would make sense if you already have a process running, like if you have the client maintaining that information for you. If you're using a web service to do it, the ROI probably drops as the gap between "natural" writes increases. Right?
I've been researching the same thing and I believe most of the time I see it set as player/character data. In the Unicorn battle demo, they used title data to set the overall experience required for each level. I'm sure they paired that with data saved to player/character also. I'm still looking into specific reasons why, but I look forward to seeing what you find!
My suspicion is that it's supposed to be player/character data. I don't much care for that, though, as that doesn't seem to be a good place for a frequently-written value. What if there were two frequently-written values?
This link seems to be informative: https://docs.microsoft.com/en-us/gaming/playfab/features/data/playerdata/.
It contains this sentence: "To provide the most flexibility and best performance, we recommended that all new titles use Entity objects."
That link contains a pretty clear-cut example of how you would use entity objects to solve this problem. So it seems like the official answer is going to be "use entity objects", which are the successor to player/character data, I think.
I'll wait for someone from PlayFab to chime in with the official official answer. ;)
Feels like if you want to reduce the # of write calls, you should use entity objects. You can model multiple fields inside one object and only make 1 write call.
If you use statistics or something and make 1 call with 2-3 statistics, that is still gonna be 1 write per statistic, even if you included them together.
I'm not trying to reduce write calls. I'll start worrying about costs when I get up to one returning player a day.
You can write multiple statistics at the same time, too, right? I thought the suggestion @Brendan was making in the other answer was to batch up the calls over time, which is easy if you're making the statistics-write decisions on the client but I think probably costs enough to do on the server that it's more effective to just keep PlayFab up to date.
Yeah, you can write multiple statistics at the same time but you will be billed for each one individually.
https://docs.microsoft.com/en-us/gaming/playfab/features/pricing/consumption-best-practices#profile
See the part about 'data and statistics'
When evaluating your usage of User Data, the same approximation logic as for events applies–each 1 KB increases the meter count by 1–though keep in mind that each "element" of a call should be thought of as distinct for purposes of this calculation. Each key value pair in a call to update User Data is counted separately. For reads, this 1 KB calculation applies to the total data returned, regardless of the number of key value pairs. This means that writing 10 keys of 100 bytes each is 10 "ticks" of the profile write meter, since each key value pair write is a minimum of 1 KB, while a read of those 10 keys is 1 "tick", since it's a total of 1 KB.
That's why I think using entity object would be more efficient, as you can fully pack 1KB with different pieces of info and key/value pairs and only be charged for 1 write.
5 People are following this question.
