Understanding the match ticket lifecycle
Overview
In this guide, you will gain an understanding of the match ticket lifecycle, that tracks the default end-to-end flow of a player, or party, after a request to start matchmaking has been submitted. However, it is possible to extend several stages of the flow to customize how matching will work for your game. Refer to our Extend guide to learn more.
There are several components used during matchmaking that you will need to be aware of:
Session Template: defines the characteristics a Session will be created with. This includes joinability, which game server deployment to use, player requirements, and team composition.
Match Ticket: defines a request for matchmaking, either by a solo player or a party, with the player information attached for evaluation.
Backfill Ticket: similar to a match ticket, but it is only created if auto-backfill is enabled in the match ruleset. In which case, when two or more players are matched they will be joined to the session and a backfill ticket submitted to the Matchmaking service, to continue to find matches until the minimum number of players have connected to the session.
Match Pool: defines a collection of match tickets that can be evaluated by the service for valid matches. Tickets end up in the same pool based on the selected game mode and preferences, if applicable.
Match Ruleset: defines the attributes and comparison criteria that will be used by the default match function to determine if tickets make a valid match. In the case that the match function has been overridden, the ruleset will still need to be configured with any attributes that are stored in the Statistics service that are required for evaluation.
Match Function: defines the logic that the service will use to evaluate match tickets. By default, the service will use the criteria defined in the associated match ruleset.
Match Ticket Lifecycle
Match tickets are a representation of a request to the Matchmaking service to find a match on behalf of a player. Once submitted, tickets will follow the flow defined below, until either a match is found, or the ticket has reached the timeout duration defined in the assigned match pool.
The player, or party, selects the desired game mode and requests matchmaking.
Players determine if they want to play solo, or in a party with friends, and select the desired multiplayer game mode. Players can be allowed to select preferences such as game map, spoken language, or difficulty. These can be included as parameters in the request to start matchmaking.
A new match ticket is created with player information and preferences.
When a request for matchmaking has been received, the service will create a new match ticket and attach the player information and selected preferences to the ticket. For parties, the service will create one ticket to represent the party with the party information, party ID, and individual player information attached.
The match ticket is validated and assigned to a match pool.
When a request to start matchmaking happens, the match pool the ticket should be assigned to needs to be passed in as part of the request which will prompt the service to add the ticket to that pool. However, this step in matching can be extended with custom logic to support a programmatic approach to pool assignment. Refer to our Extend guide for details on how to extend pool assignments.
The match ticket is hydrated, with the player attributes defined in the associated match ruleset.
Each match pool has an associated match ruleset that defines the player attributes and criteria that should be used by the match function to find appropriate matches from within the pool. If the ticket represents a party, the service will attach the attribute average of the members in the party. Hydration can also be extended to support custom logic such as adjusting attribute values before they are attached to the ticket. An example would be if you needed to add a weight to an attribute based on team or party composition. Refer to our Extend guide for details on how to extend ticket hydration.
The match ticket is evaluated with the other tickets in the match pool to find valid matches.
After the match ticket has been hydrated with the player attributes, the service will then call the associated match function to evaluate the tickets in the match pool in order to find a valid match. By default, the Matchmaking service will use the specified criteria in the associated ruleset as the logic to find a match. However, this can be extended with more complex logic if needed.
If a match isn't found during processing, the ticket will be added back to the pool to be evaluated again. If rule flexing is defined in the match ruleset, the flexed criteria will be used during the next evaluation.
The player receives the match results and a request to join the game session if a valid match was found.
If a valid match is identified, the players will receive an invite to join the game session. If backfill has been enabled, the service will create a game session after an initial match is identified with those players receiving an invitation to join the game session. At the same time, the service will also add a backfill ticket to the match pool to identify additional tickets to invite until the game session has the required number of players to start.
Next Steps
Once you have an understanding of how the Matchmaking service processes match tickets, you can begin reviewing documentation about integrating matchmaking in your game client.