Skip to main content

Introduction to Session

Last updated on November 20, 2023


The AccelByte Gaming Services (AGS) Session service provides developers with functionality for setting up and organizing multiplayer experiences, so players can connect and engage with each other. It also acts as the core of our multiplayer functionality, managing requests for dedicated servers, party management, and enabling chat rooms.

The main component of the service is a Session, which defines the properties of a game for a group of players. A typical example is a game session, where players are connected to participate in a multiplayer match through matchmaking. As they are matched together, they will be connected to the game session and host machine, where they can compete to win the match.

However, it's important to note that the service is designed to support a wide variety of sessions through the use of templates. This enables you to define additional player experiences, such as player waiting rooms, raid teams, and other features.

Key Concepts

There are some important concepts used in the design of the Session service.

Session Templates

The Session service uses templates to define default properties. This is intended to make it easy for you to conceptualize the different player experiences you want to enable in your game. The configurable properties for a template are as follows:

  • Session Template Name: this is the human readable name of the session, such as “Party”, “5 vs 5 Deathmatch”, or “Raid Team”.

  • Session Capabilities: settings that define how the session will interact with other AGS services. This includes Chat room support, which type of game host it can connect to, and which server deployment it will use.

  • Player Counts: settings that specify the minimum and maximum number of players that can be connected to the session.

  • Timeouts: settings that control how long inactive session members or member invites can exist before they are removed.

  • Joinability: a setting that defines how players are allowed to join the session.

  • Persistence: a setting that controls if a session will be automatically deleted if there are no players connected to it. By default, sessions will be deleted, however, if your game design requires a session to continue to exist even with no connections, this can be enabled. This is currently only configurable through the API.


Parties are managed as part of the Session service and will need to have their own session template configured with session type set to None.

Session Joinability

Session joinability defines how players are allowed to join a session, based on the configuration set in the session template. The configurable options are:

  • Open: allows any player to connect to the session through either matchmaking, or a Session Browser if it is enabled.

  • Invite Only: allows only players who have received an invitation to join the session through either matchmaking, a player in the session requesting to add another player, or a join code that is automatically generated for the session.

  • Closed: prevents any player from being able to join the session unless they were purposefully added there as part of matchmaking, or by the game client that requested the creation of the session.

Session Capabilities

Multiplayer capabilities are managed by multiple AGS services, with the Session service acting as the coordinator between them. In order to specify how a session will interact with other services, you can configure these parameters as part of the session template:

  • Session Type: a setting that determines if the session will connect to a host machine and the type of host it will be. The options you can choose from are:

    • Dedicated Server (DS): indicates that the session and its players will connect to a dedicated server to play the game. The session will request a dedicated server from the Dedicated Server Manager, once the minimum number of players have connected to the session.
    • Peer-to-Peer (P2P): indicates that the session and its players will connect to one of the player's computers, which will act as the host during game play.
    • None: indicates that the session is not intended to connect to a host machine. This setting is meant to be used by sessions such as parties, raid teams, or regional chat rooms.
  • Deployment: a setting that informs which game server image should be deployed to the dedicated server, once it is requested. This setting is only available if the Session Type is set to DS.

  • Enable Chat: this allows you to enable/disable a chat room for the session. If enabled, players will be able to message each other through the session chat room, while they are connected to the session.

  • Requested Regions: defines which data center a dedicated server should be requested from by the Dedicated Server Manager, once a session is ready to connect.

Session Timeouts

To prevent sessions from becoming stale, or incomplete due to unaccepted invites, the service provides the ability to configure the following timeouts. The parameters are configured as part of the session template, and include:

  • Invite Timeout: defines how long an invitation to join a session will exist before it is either accepted or removed.

  • Inactive Timeout: defines how long a member of a session can remain in an inactive state before they are removed from the session.

In the case that a player becomes inactive, or an invite times out for a session that is participating in matchmaking, a backfill ticket can be generated (automatically or manually through the SDK) letting the Matchmaking service know to find additional players to fill the empty session spots.

Session Browser

Using our session query APIs, you can build a Session Browser for players to view and filter the list of game sessions available to join. The APIs will only return the list of both Dedicated Server and Peer-to-Peer hosted sessions that have a joinability setting of Open. The APIs can also be used by developers to access the session history, including participating party information, membership changes, and matchmaking updates.

Examples of Supported Sessions

Because the Session service allows for multiple session templates to be defined, it is possible for you to create many different types of sessions. This enables you to provide a wide variety of player experiences. Here are some examples:

  • Game Sessions: enables one or more players to connect together to play a game on a dedicated server, or peer-to-peer hosted match.

  • Parties: enables a group of friends to connect together to chat, and coordinate which multiplayer game mode they will want to play together.

  • Waiting Rooms: enables one or more players to interact with each other prior to the game starting.

  • Regional Chat Sessions: enables players in a specific region of the world to be connected with each other to chat.

  • Raid Teams: enables multiple parties to band together temporarily to take on a raid boss.

Next Steps

A session is configurable both through the Admin Portal, and the Game SDK.