Possible Interesting use for Characters (Design advice and Limits)
We are building a prediction game. At its core each player has to make a set of predictions per round. We can have up to 40 rounds and each round has its own set of data called an event. where an event is the actual item you will be providing predictions against.
Looking at this I would like to use characters to store round data per player and use the round name as the class of character so each player would have 1 character of each class.
Then setup up leaderboards per class. So if the class is round_1 there would be a leaderboard of class round_1
The reason for looking at characters is due to the limit on player data. So this may be a way for us to not get limited depending on if a player can have 40 or 50 characters. I do not see any specification on character limits.
Also would the leaderboard in that scenario show the characters name or the players display name?
I also just noticed that I can have more than 10 read only player data kvps. Is the limit just the ability to only set 10 values or is there a hard limit to only allow 10 kvps on player data?
Best Answer
No, I can pretty much guarantee that anytime you find a "workaround" to bypass limits, it's something we would tell you not to do. The Character system, in specific, is designed to manage characters - similar to what you see in ESO or WoW. So, a player has a small number of characters - usually up to 5 or 6 - and they have distinct stats, inventory, and data. Trying to use it as a way to simply have more data per player is going to result in an excessive amount of resource consumption, which we'd then be asking you to fix so that we don't have to throttle your title to prevent issues.
Think of it this way: costs for any backend service are primarily tied to the amount of data being read/written, and the frequency it is read/written. To your point about player data KVPs, we don't strictly limit you to only 10 total - we limit the number you can write in a single call. But if you were to write a large number of KVPs and then use the default behavior of the read call to read them all at once, that would be a very expensive operation which would violate our fair use policy (especially if you're doing it frequently on a per player basis).
Instead, it's best to just describe the actual gameplay you're trying to implement, and we can advise you on the best approach. In your case, what is a "prediction" in your game? Why can't predictions be resolved one by one? Why can't all predictions for a round be stored in a single KVP?
Using Soccer/Football as an example
- In the WorldCup there is Group Stages which has matches
- A round could be the Group Stages or certain number of matches over a day or more
- Each Group Stage could have 20 matches we consider a match an event.
A user makes a prediction per event but we store that in a bigger object which is the round so that we do not work at 2 small a detail to avoid chattines and lots of calls to playfab as a user continuously makes his prediction per match in a round.
Based on that we would need more then 10 kvp per player that would store relatively small data usually we limit to 10 events or less per round that would be read infrequently. Basic flow
- User logs in
- User goes to Selections at this point we would
- Identify current round using title data
- Load a single KVP for that round for the user
- User then makes some selections etc and saves
- We generate an event in playstream
- The event execute clousscript which makes sure he cant cheat
- and makes a call to save a single kvp to the player data
- The user then navigates to the next round
- We then load a single kvp for the next round
So we would never really update more then 1 kvp at a time and round data would be well under 300kb limit per kvp
- Also the likelihood of a user doing all the rounds in one session would not happen. generally a user only makes predictions for the current round so he is interacting with a single kvp. this limits both CloudScript and client calls to 3 (2 for title data to identify the current round) and 1 for getting his actual single kvp that we want to read or write. This is also the most effective solution for us entirely as all our scoring is on a round basis.
So if we were to have 40-50 kvp on a player(worse case) 1 for each round but we only ever interact with 1 player kvp and 2 title kvp at a time we shouldn't have a limit issue?
The only other item that fits would be catalogs but that would make sense if we scored per event in a round as event is only small enough to fit in an item, but then scoring would be impossible to do in a cloud script and we want to keep this simple and fast as scoring pr player should run in well under a second.
The only busy times are before a round closes (User will check/make changes before a round closes and no longer allows changes)
After we have scored a round of predictions (user will check their score(stored in statistics) and leaderboards.
It's really going to come down to the worst-case for read and write. I understand the intent of what you're describing, but what is the theoretical limit of what the player could do for each? If it's reading and writing a max of one KVP every few seconds, that wouldn't be an issue. If the client will ever be reading all the KVPs in a single call, and it might do that several times a minute (or worse), we should talk through this in more detail.
So from within the client the theoretical limit is 1 kvp for player data and 2 kvp for title data and 2 statistics for read
Write is only ever via a triggered custom event action which triggers a max of 4 api calls 1 title single kvp read, 1 playerdata single kvp read, 1 player date single kvp update, 1 single statistics update.
The game engine would never need to do more then that and this is based off browser navigation where a user have to navigate to the next round.
