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. The Session service tracks players by assigning each player session a set of 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 OnGameSessionChanged
event. These keys indicate which part of a game flow a player is in.
key | status |
---|---|
PARTY_ID | in a party |
MATCHMAKING_ID | entered matchmaking |
GAME_INSTANCE_ID | game instance found |
When players enter the Party service, they’re assigned a PARTY_ID
, which persists on the session until the party is shut down or the player is removed from the party. 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.
Once a player makes it through this flow and reachesGAME_INSTANCE_ID
status, the game client waits for aOnHostConnectionDetailsReceived
orOnFailedToAllocateGameInstance
event.
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
.