Design a FlexMatch matchmaker - Amazon GameLift

Design a FlexMatch matchmaker

This topic provides guidance on how to design a matchmaker that fits your game.

Configure a basic matchmaker

At a minimum, a matchmaker needs the following elements:

  • The rule set determines the size and scope of teams for a match and defines a set of rules to use when evaluating players for a match. Each matchmaker is configured to use one rule set. See Build a FlexMatch rule set and FlexMatch rule set examples.

  • The notification target receives all matchmaking event notifications. You need to set up an Amazon Simple Notification Service (SNS) topic and then add the topic ID to the matchmaker. See more information on setting up notifications at Set up FlexMatch event notification.

  • The request timeout determines how long matchmaking requests can remain in the request pool and be evaluated for potential matches. Once a request has timed out, it has failed to make a match and is removed from the pool.

  • When using FlexMatch with GameLift managed hosting, the game session queue finds the best available resources to host a game session for the match, and starts a new game session. Each queue is configured with a list of AWS Regions and resource types (including Spot or On-Demand Instances) that determine where game sessions can be placed. For more information on queues, see Using multi-region queues.

Choose an AWS Region for the matchmaker

Decide where you want matchmaking activity to take place, and create your matchmaker (matchmaking configuration and rule set) in that Region. All requests for the matchmaker are sent to a ticket pool there, where they are sorted and evaluated for viable matches. Once matches are made, players can then be directed to game sessions in any location that is supported your hosting solution.

When choosing AWS Regions for your matchmakers, consider how location might affect their performance and how to optimize the match experience for intended players. We recommend the following best practices:

  • Place a matchmaker in an AWS region that is close to your players—and your client service that sends FlexMatch matchmaking requests. This approach decreases the latency effect on your matchmaking request workflow and makes it more efficient.

  • If your game reaches a global audience, consider creating matchmakers in multiple regions and routing match requests to the matchmaker that is closest to the player. In addition to boosting efficiency, this causes ticket pools to form with players who are geographically near each other, which improves the matchmaker's ability to match players based on latency requirements.

  • When using FlexMatch with GameLift managed hosting, place your matchmaker and the game session queue that it uses in the same AWS Region. This helps to minimize communication latency between the matchmaker and queue.

The FlexMatch resources MatchmakingConfiguration and MatchmakingRuleSet can be placed in the following GameLift-supported AWS Regions: US East (N. Virginia), US West (Oregon), EU Central (Frankfurt), EU West (Ireland), Asia Pacific Southeast (Sydney), Asia Pacific Northeast (Seoul and Tokyo), and China (Beijing).

Add optional elements

In addition to these minimum requirements, you can configure your matchmaker with the following additional options. If you are using FlexMatch with a GameLift hosting solution, many features are built in. If you're using FlexMatch as a standalone matchmaking service, you might want to build these features into your system.

Player Acceptance

You can configure a matchmaker to require that all players who are selected for a match must accept participation. If your system requires acceptance, all players must be given the option to accept or reject a proposed match. A match must receive acceptances from all players in the proposed match before it can be completed. If any player rejects or fails to accept a match, the proposed match is discarded and the tickets are handled as follows. Tickets where all players in the ticket accepted the match are returned to the matchmaking pool for continued processing. Tickets where at least one player rejected the match or failed to respond are put into a failure status and are no longer processed. Player acceptance requires a time limit; all players must accept a proposed match within the time limit for the match to continue.

Backfill Mode

Use FlexMatch backfill to keep your game sessions filled with well-matched new players throughout the life span of the game session. When handling backfill requests, FlexMatch uses the same matchmaker as was used to match the original players. You can customize how backfill tickets are prioritized with tickets for new matches, putting backfill tickets to either the front or end of the line. This means that, as new players enter the matchmaking pool, they are more or less likely to be placed in an existing game than in a newly formed game.

Manual backfill is available whether your game uses FlexMatch with managed GameLift hosting or with other hosting solutions. Manual backfill gives you the flexibility to decide when to trigger a backfill request. For example, you may want to add new players only during certain phases of your game or only when certain conditions exist.

Automatic backfill is available only for games that use managed GameLift hosting. With this feature enabled, if a game session starts with open player slots, GameLift begins automatically generating backfill requests for it. This feature allows you to set up matchmaking so that new games are started with a minimum number of players and then quickly filled as new players enter the matchmaking pool. You can turn off automatic backfill at any time during the game session life span.

Game Properties

For games that use FlexMatch with GameLift managed hosting, you can provide additional information to be passed to a game server whenever a new game session is requested. This can be a useful way to pass game mode configurations that are needed to start a game session for the type of matches being created. All game sessions for matches that are created by a matchmaker receive the same set of game properties. You can vary game property information by creating different matchmaking configurations.

Reserved Player Slots

You can designate that certain player slots in each match be reserved and filled at a later time. This is done by configuring the "additional player count" property of a matchmaking configuration.

Custom Event Data

Use this property to include a set of custom information in all matchmaking-related events for the matchmaker. This feature can be useful for tracking certain activity unique to your game, including tracking performance of your matchmakers.