Example of alias/queue setup across regions

Hi there,

We’re looking to launch with GameLift for our dedicated servers in a few months, and are hoping to have a few regions around the world.

We’re planning to have our own web service that makes the calls to the GameLift API (as recommended), but have got a proof of concept working by calling FlexMatch directly from the game client (with a single region/queue/alias/fleet).

After reading through the documentation (and trawling the forums) I’m still a bit unclear as to what the best practice is for setting up the actual GameLift side of things is though.

Would you be able to walk me through an ideal configuration for the following example requirements? Eg.:

  • We want to have fleets in at least 2 or 3 regions, eg. one in Virginia, one in Frankfurt and one in Sydney.

  • We have a single game client that we deploy worldwide via eg. Steam (and maybe consoles)

    • We expose our own identity/matchmaking web service to game clients, which will keep track of players’ MMR, rank etc. and make requests to FlexMatch
  • I assume this could be hosted in North America using eg. Lambda and DynamoDB

  • The game has 2 “game modes” that you can matchmake for, eg. Solo and Teams

1. In terms of matchmaking –
What sort of setup of queues/aliases etc. would you need to make that work?

Would you need a matchmaking configuration for each game mode in each region?

And if so, would that mean our web service would need to be sent the latency of the client for each region, and create a ticket for them on the appropriate region’s matchmaking configuration?

I know that Queues involve the concept of latency, but it doesn’t seem like that’d actually be very useful if there can only be one queue per region, and you need to tie a queue to a matchmaking configuration?

FlexMatch also incorporates latency per region, so maybe I’m misunderstanding, and these features are more for games with fleets in multiple nearby regions, despite matchmaking from a “main” region?

2. In terms of deploying game updates –
Ideally if someone has the game running when we release an update, then they should be able to finish the match they’re in, but when they try to enter matchmaking again the game will inform them that their game client is out of date and to restart it. When close it and try to re-open, Steam will force them to update.

I imagine this sort of setup would involve spinning up a new fleet for the new build in each region, while keeping the old fleet up until all matches have finished and thus all new players are on the new fleet.

If you had an alias per “branch”, eg. Live and Development, then when you update the game client you point the Live alias to the new build’s fleet (and repeat for each region)?
We’d then need to do the “version checks” in our web service, instead of using something like Terminal aliases?

So when we have a new release ready, we’d need to upload the build to each region of GameLift we want to have fleets in (eg. ap-southeast-2, us-east-1)

We currently have a tool that uploads our builds to a single region automatically as part of our CI pipeline, so would we just need to extend that to upload to more regions?

Are there any tools to keep the other stuff in sync across regions, particularly the matchmaking configurations etc.? Or would we just need to script things ourselves to remove human error?

3. In terms of security –
Say our web service only exposed a few basic methods to game clients, eg. StartMatchmaking, DescribeMatchmaking, CancelMatchmaking.

Clients would make a request to StartMatchmaking, and pass through enough info for us to authenticate that they own the game (eg. through Steam web API), and we could return the raw FlexMatch ticket id.

If we’re polling every 5 seconds to DescribeMatchmaking for the status of the ticket, would we need to re-authorise again for each request?

Or since ticket id’s are basically guid’s then no-one could really guess one, and we may as well save on execution time?

===

Sorry for the long post, I’d really appreciate even if you can only reply to a few things :slight_smile:

Thanks!
Geordie

Hey @geordie!

Thanks for all the interest in FlexMatch and setting up your GameLift infrastructure! Let me see if I can answer your questions here.

1. In terms of matchmaking –

The main question you need to answer is whether or not you want to separate your player base. Assuming that you do not, this is the recommended approach:

  1. Create Fleets in the regions where you want to place players.
  2. Create a single Queue with the Fleets created in the first step.
  3. Create a single matchmaking configuration in one of the GameLift regions where FlexMatch is supported (see FAQ for the regions)
  4. Create a latency rule in your FlexMatch ruleset that defines the latency restrictions in your match.
  5. Pass in the latency information of each of the regions where your Fleets are located for each of the player(s) in the matchmaking request
    This will allow you to match across your entire player population to help minimize player wait times (more players means more potential match candidates which results in faster matching). You can also create player latency policies in your Queue to further ensure that players are placed in the appropriate region.

Also, there is a 1:1 correlation between matchmaking configuration and rule set, and its the rule set that is the language that describes your game mode.

All of these concepts can be found in our developer guide.

2. In terms of deploying game updates –

Your understanding of aliases is correct, and you want upload your build and any updates to each region where you have created a Fleet, using the alias to switch over your clients to the latest build when you are ready. We do not currently provide tools to keep stuff in sync across regions, so you will need to manage this yourself.

3. In terms of security –

How you want to handle authorization between your game client, GameLift, and your game servers is really up to you. What I can say is that we do have throttle limits in place that restrict how often you can DescribeMatchmaking in a given time period. As such, we highly recommend that you use Notifications to ensure you get notified as fast as possible when a matchmaking request completes.

I hope this helps. Please let me know if you have any additional questions!

Hey @Geordie!

No problem.

It depends on how much you are willing to fragment your player base, and how geo-distributed your game is.

In the overall matchmaking process, the time to call into FlexMatch with the matchmaking request at most might be 200 - 300 ms from the farthest area of the world away from where you are calling FlexMatch. Depending on the complexity of your rule set, the number of players you have searching for matches, etc. finding a match could take many seconds. As such, where you put the matchmaking/queue combination isn’t as important because that call is a small fraction of the total matchmaking process.

You are correct in that FlexMatch currently has no consideration of how the Queue is processing latency or what regions the Queue has available to place matches in. Sorry for the confusion.

Currently, a match might go all the through the process of being created only to be rejected by the Queue via latency policies in the Queue, and we want to eventually short circuit this delay and reject the match up front. This is what I was alluding to regarding Queue latency policies being able to ensure players are placed in the best region. They are a safeguard, currently, against latency expansions in the rules allowing matches to be created with unacceptably high latencies.

Please do check out Notifications – they aren’t sent to the game client because the game client isn’t going to be interacting with the FlexMatch API. Your central service is. They would be managed by your central service so that it doesn’t have to use DescribeMatchmaking via polling and can instead be notified when a match is ready.

Let me know if you have any additional questions!

Hi Matchmaker, thanks a lot for the info!

Just to clarify - so you would set up a single Queue for the entire world? What region would you set up that Queue on? Just pick one as the “master region” arbitrarily? (since it can just magically see the aliases available across all GameLift regions?)

Oh right, so FlexMatch actually combines data from the player’s specified latency to each region as well as the regions available for the Queue? I think I’d assumed that FlexMatch only used the latency info provided by players and matched them optimally without taking Queue stuff into account.

Okay, will definitely look into using notifications instead then. I haven’t looked into detail at the docs, so if this is a basic question then feel free to ignore, but how would the game client actually receive said notification without some form of polling? Unless there’s a socket opened or something?

Cheers,
Geordie

Re: FlexMatch/Queues and latency - Yeah it’d be fine for all players to use a US server for matchmaking since 300ms is nothing like you say, as long as the game servers were closer to them.

So if we had a decent number of players online, and wanted to make sure that people in Europe were usually matched together (unless by some miracle someone had a better ping to the US), then we’d need to direct players to the appropriate region and then start matchmaking? Or since we provide region-specific ping info to FlexMatch it’d just prefer matching those in similar regions since they’d have similar pings to that region?

Re: Notifications - Ah okay I see, so game clients would still poll our server fairly often, but our server would have some endpoint (which is open to the internet, as opposed to game clients) that CloudWatch would hit when the ticket status changes?
Cheers,
Geordie

Hey @geordie!

I am pretty sure you are thinking about it correctly. To be specific:

Re: FlexMatch/Queues and latency

  • A matchmaker/Queue combination in Europe and a separate one in the US would ensure that you could keep players regionally grouped with no chance of players being paired with one another across regions. Your service would then be responsible for determining which matchmaker to send players to.

  • A single matchmaker with a single Queue setup with Fleets in the US and Europe would allow your matchmaker to evaluate passed in player latencies and then take care of placing players in the best region based on their latency. This means your service has less responsibility. FlexMatch/Queues will take care of looking at your global distribution of players and find the best location for each match.
    Re: Notifications

  • Yes – its an SNS topic that you subscribe to that gives you all the necessary information to pass on to game clients

Okay great, will let you know if I have any more questions :slight_smile:

Thanks for your help!