Hello CubeCrafters,
Today in this Behind the Cube, we will be exploring the complex matchmaking solution we have. This is a system that nobody really gives much attention to and is a lot more complex than most people give credit.
When joining a game, many calculations are all happening to get you the best game as quickly as possible.
For this post, we will only be explaining the matchmaking behind our largest games, like SkyWars and EggWars. Our matchmaking for things like Duels and Skyblock is slightly different.
Recently, we've introduced a lot of complexity into our matchmaking systems. For example, now, when you join a game on Bedrock, you are matchmaked with other players based off:
When matchmaking, we also need to take a few other things into account as well.
Well, when you click to join a game, all of your matchmaking options are gathered. The list is as follows:
Following this, we need to figure out which game parameters we need to send you and your party to. For this, we take the most common region and the highest input device (Mouse and Keyboard > Controller > Touch) of the party.
Once we know this information, we need to figure out if a queue can be started for this game. Now, if there are only 20 players in the NA region, and you're trying to join an NA game, there isn't going to be enough players for this game to start quickly, so we need to group you in the EU instead. The system looks at the last minute's data, and if enough players joined that game for a game to start within approximately 20 seconds, we would deem this a sustainable mode.
If there are less than enough players, we need to do some grouping.
When there are not enough players on a specific region or input device, we need to group certain options. For example, if enough people join the NA and EU regions, we run these regions simultaneously. However, if there are not enough players on Mouse and Keyboard input devices to keep queue times short, we'll group them with Controller players. We've also ensured that our systems will never group Mouse and Keyboard players with Touch players unless necessary. We also group with regions, so when there aren't enough players in the NA, they will join our EU games instead, to keep queue times down. When there aren't enough players on either region, and they're grouped, you'll always be sent to the region with the most players joining that game at that specific moment in time.
Another interesting challenge that we ran into was cross-region input-based matchmaking. For example, if our NA region doesn't have enough players to support quick queue times, it needs to be grouped with our EU region. When this happened originally, it sort of broke input-based matchmaking. This meant that we needed to add support for input modes to split into different queues on a single region when certain regions were disabled.
I am sure that I could talk about many edge cases we encountered and how we patched them. In the end, we wrote tons of automated tests for these algorithms and stress-tested them a lot to make sure that they were suitable for running on CubeCraft.
However, I'm sure you're all here for pretty pictures. Here are some pictures of the graphs that our systems make. They show start times for specific regions and input devices. It also shows us how much traffic is going to that game too. This allows us to tweak our values in case queue times are getting too long.
SkyWars Solo at EU peak. Notice how no modes are being grouped.
This is NA off-peak. As you can see, in the Average Game Start Times By Region and Input Device graph, the NA Controller and NA Mouse games have a start time of 0 seconds. This means they're not active and are grouped with the NA Touch games to keep queue times low.
This is SkyWars Mega. Since SkyWars Mega is such a large game and doesn't have the most players on our network, it means that it groups across Regions and Input Devices, because as you can see, even in its current state, queue times are approximately a minute per game.
Thanks for reading - I hope this clarifies the labyrinth of our matchmaking system. It never was this complicated before, but over the last half a year, we've had to consider both regions & input devices, while maintaining our short queue times without constant monitoring.
Let us know if there's anything you're curious about regarding our infrastructure or processes and we'd love to share how it works!
Today in this Behind the Cube, we will be exploring the complex matchmaking solution we have. This is a system that nobody really gives much attention to and is a lot more complex than most people give credit.
When joining a game, many calculations are all happening to get you the best game as quickly as possible.
For this post, we will only be explaining the matchmaking behind our largest games, like SkyWars and EggWars. Our matchmaking for things like Duels and Skyblock is slightly different.
Why is Matchmaking so complicated?
Recently, we've introduced a lot of complexity into our matchmaking systems. For example, now, when you join a game on Bedrock, you are matchmaked with other players based off:
- Your region
- Your input device (Platform based matchmaking - Categorised into Touch, Controller and Keyboard & Mouse)
- The map you selected (If you used the map selector)
When matchmaking, we also need to take a few other things into account as well.
- If there aren't enough servers in a certain region, we can no longer matchmake onto those servers and need to failover to a different region.
- If someone has the "Challenge Queue" option on Bedrock enabled, we need to tailor their games to send them to more difficult games, if that is possible.
- We also need to factor in if a player is in a party. If a player joins in a game in a party, with 2 members in the NA region and 1 in the EU, we'll always send that party to the NA region. If there is 1 in the EU and 1 in the NA, which region is selected is slightly more unpredictable and based on current demand.
So, how does this all work?
Well, when you click to join a game, all of your matchmaking options are gathered. The list is as follows:
- Your current region
- Your current input device
- Your current party
- Your parties members' input devices and regions
- If you have the challenge queue setting enabled
Following this, we need to figure out which game parameters we need to send you and your party to. For this, we take the most common region and the highest input device (Mouse and Keyboard > Controller > Touch) of the party.
Once we know this information, we need to figure out if a queue can be started for this game. Now, if there are only 20 players in the NA region, and you're trying to join an NA game, there isn't going to be enough players for this game to start quickly, so we need to group you in the EU instead. The system looks at the last minute's data, and if enough players joined that game for a game to start within approximately 20 seconds, we would deem this a sustainable mode.
If there are less than enough players, we need to do some grouping.
What is grouping?
When there are not enough players on a specific region or input device, we need to group certain options. For example, if enough people join the NA and EU regions, we run these regions simultaneously. However, if there are not enough players on Mouse and Keyboard input devices to keep queue times short, we'll group them with Controller players. We've also ensured that our systems will never group Mouse and Keyboard players with Touch players unless necessary. We also group with regions, so when there aren't enough players in the NA, they will join our EU games instead, to keep queue times down. When there aren't enough players on either region, and they're grouped, you'll always be sent to the region with the most players joining that game at that specific moment in time.
Another interesting challenge that we ran into was cross-region input-based matchmaking. For example, if our NA region doesn't have enough players to support quick queue times, it needs to be grouped with our EU region. When this happened originally, it sort of broke input-based matchmaking. This meant that we needed to add support for input modes to split into different queues on a single region when certain regions were disabled.
I am sure that I could talk about many edge cases we encountered and how we patched them. In the end, we wrote tons of automated tests for these algorithms and stress-tested them a lot to make sure that they were suitable for running on CubeCraft.
However, I'm sure you're all here for pretty pictures. Here are some pictures of the graphs that our systems make. They show start times for specific regions and input devices. It also shows us how much traffic is going to that game too. This allows us to tweak our values in case queue times are getting too long.
SkyWars Solo at EU peak. Notice how no modes are being grouped.
This is NA off-peak. As you can see, in the Average Game Start Times By Region and Input Device graph, the NA Controller and NA Mouse games have a start time of 0 seconds. This means they're not active and are grouped with the NA Touch games to keep queue times low.
This is SkyWars Mega. Since SkyWars Mega is such a large game and doesn't have the most players on our network, it means that it groups across Regions and Input Devices, because as you can see, even in its current state, queue times are approximately a minute per game.
Thanks for reading - I hope this clarifies the labyrinth of our matchmaking system. It never was this complicated before, but over the last half a year, we've had to consider both regions & input devices, while maintaining our short queue times without constant monitoring.
Let us know if there's anything you're curious about regarding our infrastructure or processes and we'd love to share how it works!