Best practice for getting user data and account info on login
Hello,
I want to do the following when a player logs:
-Add items and a default user data (if logging in for the first time)
-Get the account info
-Get user data
-Get inventory of player
I need all of these as we show user's display name in lobby (received in account info), some basic stats like level & xp (stored in userdata), and his equipped items in a 3d scene.
In another topic, it was suggested to use playstream events to add default items and user data, but I don't think that approach would work for me, since my client APİ calls and cloudscript function called by playstream event would not be synchronous.
What I got so far:
1) When login is successful, call a single cloudscript function from client. The function initializes inventory & basic data if it is first login(not sure how to check this in cloudscript). Then, it calls server API functions to get account info, user data and inventory, then returns them to the client in a single response. Not sure how to accomplish this part in cloudscript, though.
2) After a successful login, call a single cloudscript function that only initialized inventory & basic data if it is the first login. Then, use client API to get other necessary data from Playfab. Would making 3 simultaneous client API calls be a problem?
What would be the best approach here?
Best Answer
Your best bet would be to have an "OnLogin" Cloud Script that you call from the client after the login returns, and use it to request the data you need, as described in 2 (since you can get user data and stats from the client directly, there's no need to put that in the Cloud Script call). To determine if it's the player's first login, you could use any statistic that you track as part of your game - if the player has it, it's not their first login. Make sure to set the stat to a default value only at the end of setup, so that you can make sure everything else is complete first, of course.
The one caution is that if you're doing a lot of things for the player on start (it's a lot of inventory items, for example), you may need to stage this out over a short period of time, as it may be too much work for a single Cloud Script call. Alternately, if you're using custom game servers for multiplayer, you could also use them to process setup logic for new players by having the players matchmake into them and provide a distinct setup request (having the server check their statistics, to make sure they're new).
Simultaneous calls are usually not a good idea, since you have no way of determining in what order they'll be processed. If the three calls are completely distinct from one another - meaning there's zero overlap between the things they're reading/writing - then it should be fine.
Thanks for the reply.
"Simultaneous calls are usually not a good idea, since you have no way of determining in what order they'll be processed. If the three calls are completely distinct from one another - meaning there's zero overlap between the things they're reading/writing - then it should be fine."
For me, order does not matter, I only need all of them to be completed, in whatever order. They would all be reading 3 different things, so as long as Playfab does not block simultaneous calls from a single client, it should be okay?
Another question is, what exactly is a simultaneous call? Same frame? Would waiting 1 frame between calls be enough?
In addition, would making the 3 simultaneous calls in cloudscript cause any issue? How limiting is the 1 second limit in this case, assuming we just read data from 3 api calls?
What frame you make a call on is irrelevant. Every Web API call is a call made over the internet, and is going to have unique latency, based on how it is routed. If you make a call to an endpoint, then make another one or two frames later, the second call could easily arrive at the endpoint before the first - there's literally no way to guarantee that short of waiting on the response from the first call. So the concept of "simultaneous" really means "without waiting on a response".
The issues you'll run into with backend services (through PlayFab or otherwise) are going to be if you issue multiple calls that could change the same data row multiple times without waiting on a response. The problem is that since you have absolutely no control over the delivery time of each packet, you cannot control the order in which they arrive. So if they affect the same row, the total change is indeterminate.
