Skip to content
RallyHere Docs

Session Overview

Vision

Sessions are their core are a grouping of players, with the ability to add on functionality to that group (primarily gameplay). They are themselves a generic container that can be configured via a Session Type to have varying functionality. This includes concepts like parties, gameplay matches, open world areas, and many other possible uses.

Anatomy of a Session

At a high level, Sessions are composed of a few different elements, some of which are listed below. Note that many of the top level elements (including the Session itself) have Custom Data fields, which are String->String maps that can be used to store any data you wish.

  • Session Type: The name of a Session Type, which is configured in the Developer Portal. This type specifies many things about how the session operates.
  • Session ID: The session’s unique identifier.
  • Region: the region the session will be hosted in or match made into
  • Teams: groups of players within the session (Note - many sessions may have only a single team)
  • Platform Session Info - A list of information about Platform (ex: Steam) sessions that are associated with this session. This is used for things like inviting friends to a session, or joining a friend’s session.
  • Instance: a hosted connection point that users can connect to (for use in things like gameplay matches) — Host Type / Info: the type of host (ex: Dedicated Server, Player, etc) — Join Status / Info - information on how to connect to the host — Startup Params - parameters passed in during startup such as the initial map and gamemode — Version - compatibility version to check before attempting to join

Session Types

Session Types are a configurable template, that is used to determine characteristics of a session within your game. While the specifics of your configuration can be wide ranging, and should refer to the Session Type Configuration documentation on the Developer Portal, the goal is to encapsulate as much as possible about how a session works into the Session Type configuration so that that logic can be reused or consulted as needed.

A few examples of Session Types, used by our Example Game reference implementation:

  • Party: this session type is used for a group of players preparing to play together. It does not have much that is special about its configuration beyond being set to default to Private, but can be used for both a social screen, or for launching gameplay with your party members.
  • Game: this session type is used for a gameplay match. While it does not have a lot special about specifically, it does have the ability to have multiple teams, for example.
  • Hub/City/Open World (naming TBD): this session type is used for an open world area. The big difference about this session type relative to others is that is has the Hub joining rule. This means that when a player tries to create or join a session of this type, they will be rerouted to an existing session (if there is one with space) or create a new one if not. It also has a set of auto-launch parameters for a gameplay instance, so that when a new session is created it will automatically initiate the gameplay elements for it.
    Note - Currently, this clustering is determined by Session Type, so if you wanted to have a second city area for example, you would need a second Session Type to represent it.
  • Browser Game: this is a variant of Game that is configured to automatically register with the Session Browser, which is one mechanism that can be used for finding and joining sessions. To help support this, these sessions are also Public by default.

Session Formation

RallyHere’s session system supports multiple methods for forming and joining sessions, with more being added over time. These include but are not necessarily limited to:

  • Direct creation: a user (player, server, etc) directly asks the API to create a session. Players can then join that session based on its joinability rules (Public, Private / Invite only, etc).
  • Session Browser: a session can be configured (via Session Type) or manually registered with the Session Browser. Sessions that are registered can then be searched for and joined (still based on the joinability rules). While the Debug Tool browser functionality presents options to the user, it is entirely possible to use the browser under the hood. For example, a game may choose to register Open World type Sessions with the browser so that users can hop between variants of that Open World area (sometimes referred to as “layers”).
  • Matchmaking: a session can be queued into matchmmaking, which once matching is complete will result in a new session of a configured type (ex: Game), and all players will be invited to that new session.

Joinability

Currently only two joinability types are supported, but we are planning to add more. The current ones are Public (anyone can join if they have the Session ID), and Private (requires a user to be invited)

Instances

A Session’s Instance represents a hosted connection point for users to connect to. This is used most commonly for gameplay, where the instance would have information on how to connect to a server or peer to peer host. However, it can be used for other things, such as specifying a utility endpoint that (for example) can be used to run specialty scripts in a special environment (ex: running a highly specialized crafting system).

Instances are owned by the session they are created in, but a session can create and destroy them as needed. This allows you to reuse the same session object (and group of players) across multiple gameplay elements, as needed.

When an instance is created, you must specify a set of startup parameters, which include things like the Host Type. If a dedicated server host is requested, one will be allocated, otherwise if a player hosted instance is requested one of the players will be designated as the host. Additional parameters include version, maps, modes, etc. Once created, the instance will not be joinable until the host marks it as such (there are several states that instances can be marked to be in, such as pending, joinable, and closed)