Last updated on October 23, 2024
AccelByte Gaming Services (AGS) Matchmaking has been upgraded. The list below shows the differences between the old version (v1) and the new version (v2). Expand the topics to see more information.
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. |
|---|