question

Best Answer
Brendan Vanous said on Wed, 25 February 2015 at 2:56 PM

Indeed, User Data would be the way to go. And since the game is asynchronous, it is also the case that Cloud Script could be used to drive the decision-making on key factors (to prevent cheating).

One key question was about having a score which is modified by wins and losses, which is used for matchmaking. This is similar to an ELO-type system, variations of which are used by a number of games for matchmaking. It's also possible to manage this using Cloud Script by having a Shared Group Data object tracking the "open" sessions, and negotiating creation of a session (represented with Player Data on both players - the recommendation being to use Player Internal Data, so that again, the client is blocked from cheating it directly) with a player whose session is listed in Shared Group Data with a ranking close to that of the current user. You would also want to use Title Data to hold the factors used for this matchmaking (like the acceptable delta between the ranks, how much to adjust rank on a win/loss, etc.).

We'll have an example of managing asynchronous games via Cloud Script post-GDC (we're working on it now, but we'll be very heads-down until after the conference). It won't show rank-based matchmaking, but that would be a straightforward addition, as described above.

---

3 Comments
deadstarcgs said on Wed, 25 February 2015 at 6:10 AM

At a guess, I'd say you would use the Player Data functionality which can be read using the GetUserData request and changed using the UpdateUserData request.

---

Brendan Vanous said on Wed, 25 February 2015 at 2:56 PM

Indeed, User Data would be the way to go. And since the game is asynchronous, it is also the case that Cloud Script could be used to drive the decision-making on key factors (to prevent cheating).

One key question was about having a score which is modified by wins and losses, which is used for matchmaking. This is similar to an ELO-type system, variations of which are used by a number of games for matchmaking. It's also possible to manage this using Cloud Script by having a Shared Group Data object tracking the "open" sessions, and negotiating creation of a session (represented with Player Data on both players - the recommendation being to use Player Internal Data, so that again, the client is blocked from cheating it directly) with a player whose session is listed in Shared Group Data with a ranking close to that of the current user. You would also want to use Title Data to hold the factors used for this matchmaking (like the acceptable delta between the ranks, how much to adjust rank on a win/loss, etc.).

We'll have an example of managing asynchronous games via Cloud Script post-GDC (we're working on it now, but we'll be very heads-down until after the conference). It won't show rank-based matchmaking, but that would be a straightforward addition, as described above.

---

Brendan Vanous said on Tue, 31 March 2015 at 11:50 AM

Quick follow-up: Our asynchronous game example has been posted. Here's a link to the forum post that walks through this, and provides links to the resources:

https://playfab.com/blog/2015/03/24/creating-turn-based-asynchronous-matchmaker-without-dedicated-server