Introduction to multiplayer sessions
Learn how multiplayer sessions manage connected players, session ownership, and game state in Unity Multiplayer Services.
読み終わるまでの所要時間 6 分最終更新 3時間前
Sessions provide an abstraction layer for managing connected players, session ownership, and gameplay state across multiplayer experiences. In Unity Multiplayer Services (MPS SDK), a session acts as the shared coordination point for players, host election, data updates, and connection setup.
A session represents a group of connected players and manages their interactions through different connection types, including client-hosted solutions like Relay and Distributed Authority, or dedicated game servers. Sessions work with either the Netcode for GameObjects or the Netcode for Entities networking libraries.
What sessions are
A session is the shared container that coordinates a multiplayer game. It keeps track of connected players, session metadata, and game state, and it exposes the operations needed to create, join, modify, and leave a multiplayer match.
The MPS SDK combines the underlying functionality of Lobby, Matchmaker, and Relay into a single API centered on sessions. This single interface reduces boilerplate code and standardizes UGS usage, automatically managing features like Lobby heartbeating and, when enabled, the Lobby/Relay integration, allowing developers to focus on unique game features.
The following diagram shows the flow for a typical session-based setup from the host's point of view point of view:
How sessions work
Sessions manage the lifecycle of a multiplayer match from creation to shutdown. They can create a lobby, assign a host, manage connection data, and handle player join and leave events as the session evolves.
The session model supports several important concepts:
- Session ownership: One player or service-owned session can act as the authoritative host for a match.
- Player membership: Each connected player is tracked as part of the session and can have per-player state.
- Connection setup: Sessions can use different networking options, depending on the runtime architecture you choose.
- Session data: Session metadata and player properties can change while the match is running.
When a session starts, the MPS SDK can create a lobby, allocate relay resources, and pass the relevant connection data to your networking layer. This reduces the amount of service-specific coordination you need to implement in your game code.
The following diagram shows the flow for a typical session-based setup from the client's point of view point of view:
Session lifecycle and state
A session doesn't exist only as a container for players. It also manages state and behavior across the full match lifecycle. For example, the session can track player joins and departures, keep host ownership up to date, and support reconnection or migration when needed.
The lifecycle commonly includes:
- Create or find a session.
- Authenticate players and validate access.
- Establish networking and connection data.
- Start gameplay and update session information.
- Handle disconnects, host migration, or session cleanup.
This SDK lets you focus on game logic while the session API manages the supporting multiplayer infrastructure.
For more information, refer to Session states
Session data
Sessions include the information needed to identify the match, track its current members, manage access rules, and connect players to the active network.
A session contains the following data:
- : The unique identifier for the session.
Id - : The generated join code that players can use to enter the session.
Code - : The human-readable name of the session.
Name - : The session type used to distinguish different session contexts and reconnect flows.
Type - : The player ID of the player currently holding host authority over the session.
Host - : The players currently in the session.
Players - : The session-level metadata and state that the host or service can read and update.
Properties - : The current lifecycle state of the session.
State - : The maximum number of players allowed in the session.
MaxPlayers - or
PlayerCount: The current occupancy or remaining capacity of the session.AvailableSlots - : Whether the session is hidden from public queries.
IsPrivate - : Whether the session prevents additional players from joining.
IsLocked - : Whether a password is required to join the session.
HasPassword - : The connection information used for relay or networking setup.
Network
For more information, refer to Session properties and the package documentation.
When to use sessions
Use sessions when your game needs a shared multiplayer state with consistent player membership and service-managed coordination. Sessions are useful for games that need to do the following:
- Create a match and keep it organized around a single host or service-owned session.
- Let players join and leave without manually reworking lobby or relay setup.
- Share per-session or per-player data during the match.
- Coordinate networking flows between connection, matchmaking, and gameplay logic.
Sessions are especially useful when you want to unify Lobby, Matchmaker, and Relay behavior under one programming model while still retaining access to service-specific APIs when needed.
Additional resources
- Create a session
- Find and join a session
- Match players
- Manage session data
- Monitor and debug sessions
- Connect players through a relay