Player Sessions

Edgegap supports several managed and custom player session management models. When choosing a model, consider aspects like authority, duration, stickiness, and quality of service.

🚀 Getting Started

Consider a complex game design offering all possible session models. Most games start with a smaller subset and sometimes expand to include more session systems later.

See 📚 Key Concepts below for a clear-cut differentiation between session-related concepts.

Lobby to Session Flows

When testing new builds with developers or QA teams, the session step is often skipped and players connect directly to deployments while hard-coding or disabling session related features. This enables faster development iteration and isolates session side effects from server features.

Starting your Deployments manually and pasting URL and ports will not cut it for a live game.

Automate popular game flows for Player Sessions and server scaling with either:

Matchmaking:

• Competitive Games

• On-Demand Matches

• Skill Rating and/or Custom Rules

Server Browser:

• Persistent or Social

• Long Sessions

• Auto-Assign and/or Custom Search

Custom Backend:

• Migrate Live Games

• Deploy with v2 API

• Observe Webhooks

📚 Key Concepts

Review our clear-cut definitions to easily differentiate between complex session concepts.

Lobby

Lobby (also refered to as Party) refers to a short-lived and disposable group of players. Lobbies start with a friend invite (or join request), most commonly before a session (server connection) is established - to allow a group of friends to join the same game session together, and configure various parameters like character/role choice, game mode preference, map preference, or other.

Lobbies often span through multiple sessions, keeping the same set of friends together.

Lobbies requesting allocation to a Session (new or existing) are often referred to as Groups.

Lobbies rely heavily on social & friend features native to distribution platforms. Edgegap services integrate your preferred Lobby service instead of replacing it.

Game Backend (incl. third party Lobby Service)	Unreal Engine	Unity	Godot
Epic Online Services Lobby (Epic Games)
Steamworks Lobby (Valve Corporation)
Nakama Group (Heroic Labs)
Playfab Lobby (Microsoft)
brainCloud Lobby (bitHeads)
noray (Netfox)
Gamekit Friends (Apple)
Custom Lobby (your company)

Lobby should not be confused with a Social Hub server (often called "Lobby Server").

Social Hub

Social Hub is a special dedicated game server offering a social experience, often while waiting to fill the Session with enough players to start the main game mode. Social Hubs are sometimes disabanded or filled with bots, as a fallback in case of long wait times.

Social Hubs are similar to Persistent Servers which can run for extended periods of time.

Session

Session is a short-lived and disposable entity defined by a set of parameters:

• Connected Group(s) - one or more Groups, each identified by a set of unique player IDs.

• Deployment - a single server instance holding player connections for the session's duration.

Sessions on Edgegap can utilize managed services, a third party solution, or your custom backend.

🔀 Stacking Sessions

Most game engines require at least 0.25 vCPU to run servers, benchmark using Container Metrics.

Custom game servers sometimes require less than the minimum 0.25 vCPU per session:

• Lockstep Simulation games (e.g. turn-based, TCG/CCG, or strategy games).

• 1v1 Fighting Games - usually using Custom Smart Relay with cheating detection (e.g. lightnet).

This results in deployments with idle headroom, inflating your hosting cost. To reduce that headroom, try stacking multiple sessions in each deployment. This will require some server modifications.

Stacking sessions is not recommended if your server requires 0.25 vCPU or more. This approach adds session management complexity, which is typically provided by effortless Deployment isolation.

Session stacking brings three new challenges:

1. Fill available deployment capacity with active sessions to reduce idle headroom.

   1. Using Matchmaking Backfill or Server Browser to reuse empty sessions in deployments.

2. Drain empty or near-empty deployments and migrate long running sessions.

   1. Stop empty deployments to reduce cost. For the last few long running sessions, offer players to move to another deployment to consolidate sessions and reduce your cost.

3. Prevent an unexpected error in one session from affecting the whole deployment.

   1. Implement multiple safety nets to catch exceptions at the session level. Partial error handling is advised, though restarting the match is often much easier with shorter sessions.