Session #

The Session service is responsible for managing states attached to a given user session. Many services work in concert in order to get players in a 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.

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

This enables several features, including:

• Allowing players to reconnect to an in-progress game instance after a client crash or disconnect.
• Requiring that players reconnect to an in-progress game instance 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 game instance has been made and sent to the Game Instance service, all of the players within the game instance have their MATCHMAKING_ID removed and a GAME_INSTANCE_ID added.

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

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

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

Once a player makes it through this flow and reaches GAME_INSTANCE_ID status, the game client waits for a OnHostConnectionDetailsReceived or OnFailedToAllocateGameInstance event.