Introducing Multiplayer V2

We have been learning a lot with the different games that shipped using our existing (v1) Matchmaking, Lobby and Session Browser. And we have been listening to all the feedback that we’ve gotten from our fabulous clients on ways we can improve our multiplayer capabilities.

This blog post will outline what we’ve learned so far and how we’re continuously improving to provide more value to game studios.

Multiplayer Concepts

Multiplayer is really about playing, or doing an activity together, with other people, which can be your friends or random strangers on the internet.

Session is a way to track and facilitate online multiplayer activities.

Here are different ways a session can be useful:

• A party session, which is a group of players who are banding together from match to match.
• Pre-game waiting area session (sometimes called lobby) where players can interact each other before the match starts
• An online match session - for example: ranked and unranked matches
• A social hub session where players can interact with each other before heading into matches or gameplay server instances
  A game defined grouping of active players to do an activity together - a squad, a crew, a fire team, regional chat room, and so on

Matchmaking is a mechanism to find a session, based on some criteria. The matchmaking criteria will be different based on what kind of sessionor activities that the players are looking for.

For instance, searching for a ranked match session would be based on players skill rating, which will be different from searching for a social hub session, which will be finding the closest server with open seats, and preferably where the player’s friends are online at.

Matchmaking backfill is the mechanism to add players into active sessions which still need more players. The decision whether to backfill a session with more players is very much game-specific.

For example, a game might prefer to shorten the time players matchmaking by creating a waiting area session with low minimum players, and continue to backfill it with more players until a certain time window has passed (say, five minutes).

There are different ways for players to join a session, but these are the three most common ways:

1. Via matchmaking.
   For example: a party leader using a matchmaking to find the best unranked game that can facilitate her party of three.
2. Via session browser.
   For example: a player can browse all sessions, with the option to filter based on some attributes like map name, region, population count, etc.
3. Via invite or join via presence.
   For example: a player sends an invite to her friend to join her session, or a player to join his friend’s game session via Xbox Dashboard.
   Note that some platforms like Xbox and PlayStation require you to support invite and joining via dashboard for compliance.
   

Multiplayer Services, Evolved

We took all of our learnings and redesigned the multiplayer interfaces and APIs from the ground up - to make it easy and consistent, while keeping some of the battle-tested components, such as the core of the highly scalable matchmaking engine.

And so, we are introducing two new AccelByte services:

The new Session Service: responsible for party and game-defined session management. It also manages session member lifecycle within this session, including invite and timeouts.

The new Matchmaking Service: responsible for creating viable match sessions out of tickets and backfill tickets, based on the game-specific configuration and logic.

These two services will be leveraging existing Lobby service for notification and Armada for Dedicated Server orchestration.

Simpler Architecture = More Flexibility = Better Game Experience

With the simplified architecture of Multiplayer v2, these are the new things you can enable from the game:

Greater flexibility in defining Sessions and its behaviors

You can define what kind of grouping, and the behavior of the user grouping - like min/max and network topology - as Session Template via API or Admin Portal. You can also override some of the behavior of the session - including party session - via Game API, for instance: setting max members in a Party or Crew based on player input.

Greater flexibility in Matchmaking

We now make it easy and consistent to kick off solo matchmaking (without having to be in the party first), party matchmaking, or matchmaking on behalf of any session the user is a member of - for instance, matchmaking on behalf of a Fire Team.

And yes, if your game supports it, you can have multiple active Matchmaking tickets at any given time - for instance, your player might be searching for a Crew at the same time as searching for Social Hub to join.

Near-instant, painless Auto-Backfill

In v1, one complaint that we heard loud and clear is that it’s quite involved to kick off a Backfill process - you need the Dedicated Server to make the enqueue session call; which can be few seconds or minutes after the match was created.

In v2, we are enabling Backfill as a first class citizen of Matchmaking; which means that right after Matchmaking is able to create a viable Match Session, it can immediately enqueue the Session for backfilling process.

Out-of-the-box support for First Party Invite and Join

In v2, we are adding in built-in support to synchronize the player's Party and Match Session with various first party Party and Session. Supporting cross-platform invite and presence join is required by some of the first party certification processes, and we feel that this is something that will help you ship faster.

Notification for the Dedicated Server

In addition to Lobby that has been serving notifications to players, we are now introducing new capabilities to serve notifications to Dedicated Servers as well - so DS can listen to changes to Match Session; as well as managing Backfill process easily.

(Experimental) Code-level customization to override default Matchmaking Function

Due to overwhelming demand, we are working on enabling game devs to provide code-level override to the default matchmaking function from the Matchmaking v2.

The default matchmaking function supports a lot of per-game, per-match pool configuration that game devs can tweak - like time-based relaxing match rule

But sometimes one of your games need a very specific custom logic that can only be accomplished by overriding in the code level, such as:

• Relaxing min/max criteria of a match based on time, or some other criteria (like the number of tickets in the queue)
• Very game-specific team assignment for a match
• Moving toxic players into different match queue to ensure good experience for the rest of your player base

Timeline

Currently we are in the Early Preview phase, with GA and Load Testing in Fall 2022, and Launch Ready early 2023.

If you are interested in learning more - including load test numbers based on your game’s use cases, request a demo here!