Dynamically Assemble and Match Players
Dynamically Assemble and Match Players
Connect Cross-Platform Accounts and Identity Management
Grow and Commercialize Your Game
Build a Vibrant Community
Track Player Progression and Game State Across Platforms
Track, Engage, and Retain Players
Player Portal, Launcher, and Patcher
Make Informed Decisions with Player and Game Telemetry
Get a 360 view on game health by combining crash reporting, performance analytics, build quality and binary distribution into one toolbox
Want to Kickstart Your Early Game?
Foundations is our free offering for indie studios with big ambitions
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 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:
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:
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.
With the simplified architecture of Multiplayer v2, these are the new things you can enable from the game:
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.
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.
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.
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.
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.
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:
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!
Reach out to the AccelByte team to learn more.