Flow Explanation

Document image

  • PlayFab requires a logged in user. In the example, a custom id is used, but any type of login should work. The result is only used for matchmaking, and this is not personal identifiable information.
  • Latencies are calculated by pinging the PlayFab QoS beacons on port 3075. These latencies are put into the matchmaking request.
  • MatchId, which is used for data storage in cloudscript and as a matchKey for the Gameye servers.
  • MatchId as an identifier. Clients then poll for this group, to find out which client should start the match. Note that the TicketId is used here instead of trying to identify the user.
  • The chosen client issues a call to cloudscript directly to start a Gameye match with the given match information.
  • matchKey to become available.
  • Once the Gameye server is available, the host information can be extracted and clients can use this to connect.

Playfab Settings

Do I need to enable "Server allocation"on my queue? No, this activates Playfab's own server solution which isn't needed when using Gameye.

Using multiple queues Playfab v2 matchmaking is a general matchmaking queue system. If you want to match with the same game mode, you'll need a queue for that mode. Our example only uses one queue, but it's not hard to add multiple. In our example the queue is a constant, not a parameter in the matchmaking, you can make it a paramater and allow the client to specify it on the API call.


  • The reason for triggering the game servers via a cloudscript execution are two-fold. Firstly, the free-tier timeouts in cloudscript event rules are too short to create a game server. These limits do not apply when using Azure functions. Secondly, by doing them in cloudscript, we obscure the token and gameye server urls from the client, preventing malicious users from abusing a token.