Matchmaking (Legacy) and new Matchmaking (V2) comparison

Last updated on October 24, 2024

Overview

AccelByte Gaming Services (AGS) Matchmaking has been upgraded. The list below shows the differences between the legacy version (v1) and the new version (v2). Expand the topics to see more information.

Matchmaking (Legacy) and new Matchmaking (V2) comparison

Service architecture

What's in V1	Multiplayer services' logic is done within the Lobby service via websocket.
What's in V2	Multiplayer services are now appropriate microservices with public and admin HTTP endpoints.
Why you should care	You can use the Server SDK to build server-to-server (S2S) functionalities with a friendlier request-response API model.

Developer-defined sessions templates

What's in V1	No support for developer-defined session templates.
What's in V2	Developers can define various session templates and customize all aspects of the session, such as min and max players, joinability, etc.
Why you should care	You can define multiple session behaviors like Game Session, Zone, Fireteam, Squad, Room, etc. that work for your game experience. You can build more complicated logic around multiplayer, such as supporting matchmaking and session browsers against the same running sessions.

Matchmaking and session browser against same-session SDK and Unreal OnlineSubsystem (OSS) support

What's in V1	Matchmaking and Session design is embedded in the same service, causing issues in supporting more advanced scenarios. Limited support.
What's in V2	Matchmaking and Session are decoupled and running as separate microservices. Full support for both Game Client and DS.
Why you should care	Easier developer onboarding with better tutorials.

First-party Platform (1PP) automatic sync to Party, Presence, and Invites

What's in V1	No support.
What's in V2	Session service will be able to synchronize the 1PP Party, Session, and Presence information for joinable information to Xbox, Steam, and PlayStation.
Why you should care	Synchronizing Party, Session, and Presence information is part of TCR for various 1PP such as Xbox and PlayStation, and this will save you a substantial amount of time. Developers can write their own gRPC server by following our tutorial to customize the out-of-the-box matchmaking behavior, such as: - Ticket hydration behavior - Ticket filtering and verification - Matching function

Extending and customizing matchmaking behavior via code

What's in V1	Only supports customization via matchmaking configuration; cannot customize at code level.
What's in V2	Matchmaking service will have multiple "customization" endpoints that you can override with your own server code running as a gRPC server (either hosted by you or on our Extend platform). For example, you can override where the match ticket is getting the player data from, or you can specify different ticket matching algorithms completely based on your own logic.
Why you should care	We do not believe in one size fits all, so we provide a way for you to plug in your own server code to override the default matchmaking behavior only on the areas you care about.

Auto-backfill

What's in V1	We support backfill by having DS call the enqueue session (if it's marked as joinable).
What's in V2	Auto-backfill will be a matchmaking service feature by honoring the settings configuration and automatically backfilling sessions that have empty seats without needing DS to submit it.
Why you should care	The v1 backfill mechanism might create a lot of sessions in situations of low population due the delay between Match Created and DS a submitting backfill request. With Auto-backfill v2, backfilling will be triggered automatically, which will reduce the chance of players getting separated into multiple sessions during a low player count situation.

Backfill resolution

What's in V1	There is no API for DS to intervene and make the final decision on backfill resolution.
What's in V2	DS will have API and callbacks to approve backfill candidates, putting the power and decision making in DS to deal with possible race conditions between backfill and direct joins.
Why you should care	For situations where cross-platform sessions are open to be joined via multiple ways, like backfill (matchmaking), session browser, friend invites, etc., DS will have the final say into anyone getting added into the session, including via backfill matchmaking.

DS notification

What's in V1	There is no notification for DS.
What's in V2	DS can subscribe to session changes notifications.
Why you should care	No more polling needed.

Session integration with dedicated server manager

What's in V1	Lobby integrates with Armada.
What's in V2	Session integrates with Armada as capabilities (if Session Template is defined as Type=DS).
Why you should care	Easier tracing and debugging to figure out if there are issues getting Dedicated Server out of Armada.

Session integrated with dedicated next generation server manager

What's in V1	No support.
What's in V2	Supported.