Hi there -
How can I recover account information in cases where the user installs the game, authenticates anonymously at first and using Facebook later, deletes the app, and then installs it again and repeats the same process? If I use ForceCreate == true for LinkFacebookAccountRequest, that just creates a duplicate account with none of the information carried over; if I leave it to false, then I encounter error 1011. Detailed steps below - what do I do?
With ForceCreate == true
Steps:
With ForceCreate == false
Steps:
Answer by Brendan · Sep 04, 2017 at 03:20 AM
The key point is that if you create an account (CreateAccount = true in the login call), that's a distinct account. It's important to have your FTUE guide the player to the correct login. Have a look at our login best practices guide, to get started with that: https://api.playfab.com/docs/tutorials/landing-players/best-login. The key is to make sure to offer the opportunity to get to their existing account, if they have one, from the start. There will still be players who won't read anything you put in front of them, and wind up with multiple accounts. For those players, you either leave the account separate, or else offer to merge some part of account A to account B, by signing the player into the first one, reading the details you need, then signing into the second and writing them there.
Hi @Brendan -
This worked swimmingly, as usual!
Another question, and slightly off-topic - the game I'm working on is an incremental game, which means that some values can go up to 1e308 (I have to use doubles to handle them within the game).
Since one of the main benefits of linking accounts is the ability to restore data when switching devices or what not, it would be useful to store this data in the cloud - however, I'm not sure if there are limits as to the size of things that can be stored (e.g., another service I worked with ignored everything that was greater than a long).
What, if any, are PlayFab's limits and, if they're less than 1e308, is there a workaround?
Cheers,
George
Well, for compatibility across all the SDKs we support, statistics are 32-bit, so you wouldn't be able to have a leaderboard that has those numbers at full fidelity. We have quite a few clicker games on the platform - in general, they store the player's values in player data, updating the backend on a timer so that the player scores are updated in the service every minute or so (with the occasional extra save when key things occur in-game). A double-precision value (up to 1.8 * 10^308) only needs 64 bits, and even if you use some of the specialized large math libraries, values generally aren't that long. Player data values are measures in thousands of bytes, minimally - so there's plenty of room to work with.