Session #

The Session service is responsible for managing state attached to a given user session. In the game flow, many services work in concert in order to get players in game. The Session service’s job is to be the system of record for which service a player’s session currently belongs to.

Players who leave an in-progress game create a bad experience for other players. In addition to systems deliberately tailored to prevent AFK and other disruptive behaviors, live-service games often want to manage the game flow such that players are not able to leave a match and start another.

The game flow services coordinate with the Session service to ensure the platform understands where the player is at all times, and the Session service tracks players throughout the game flow via assigning each player session attribute keys.

This enables several features, including:

• Allowing players to reconnect to an in-progress match after a client crash or disconnect.
• Requiring that players reconnect to an in-progress match rather than starting a new one.
• Preventing abuse cases such as filling up the matchmaking queue with stale records.
• Allowing clients to recover from intermittent network issues while players are going through the game flow.

Attribute Keys #

Within the Session service, players are assigned session attribute keys, which can be found within the OnGameSessionChangedV1Notification event. These keys indicate which part of a game flow a player is in.

When players enter the Party service, they’re assigned a PARTY_ID. When a party enters matchmaking, all player sessions owned by that party have a MATCHMAKING_ID added. Once a match has been made and sent to the Match Lifecycle service, all of the players within the match have their MATCHMAKING_ID removed and a MATCH_ID added.

The PARTY_ID persists on the session through both matchmaking and the match until the party is shut down or the player is removed from the party.

This session-based store of party/matchmaking/match IDs is used by the game flow services to prevent players from attempting actions that don’t make sense in the game flow.

For example, if a player disconnects during a match and has an assigned MATCH_ID, then later reconnects while the same match is still being played, the Session service informs the Match Lifecycle service that the player has returned. The Match Lifecycle service confirms that the match is ongoing, ensures the player’s new session is assigned the MATCH_ID, and resends match connection details to the player so they can rejoin the game. This behavior can be toggled via the configuration option MatchLifecycleServiceConfig.matchReconnect.

Once a player makes it through this flow and reaches MATCH_ID status, the game client waits for a OnMatchReady or OnFailedToFindMatch event.