In this text, we use our game War Robots: Frontiers to demonstrate how matchmaking can work well in PvP games from the technical side!
Matchmaking is an integral — yet often mysterious — component of any online game. While every player may have an intuitive sense of how matchmaking might work, only a few truly understand the intricate mechanics behind it. I’m Dmitry Bratus, and I develop the matchmaking service for War Robots: Frontiers. In this article, I’ll explain the fundamental principles of matchmaking overall and give you some insight into how it operates in our game.
What Makes a Good Match?
The task of matchmaking may seem simple at first glance, but this simplicity is deceptive. To illustrate this point, let’s pose a question: what is matchmaking in the most general case? Players queue up (more precisely, groups of players, but more on that later) and there is an expected match “shape”, that is, the number and size of teams. It is necessary to divide players into matches by the criteria determined by the game design. Assuming that the order of players in a match is not important, the number of ways to assemble a match of size S from a queue of length L is equal to the binomial coefficient:
The factorials here hint at how quickly the number of possible combinations grows. For example, a 12-player match drawn from a queue of just 20 players yields 125,970 possible groupings. With a queue of 100 players, this balloons to a staggering 1,050,421,051,106,700 possibilities, which is, of course, far too many to brute-force in real time.
Thankfully, the system doesn’t need to exhaustively evaluate every option. In fact, the vast majority of potential match combinations are clearly unsuitable based on the game’s criteria. Instead, matchmaking relies on heuristics: intelligent shortcuts that swiftly reject poor match-ups and narrow the search space to a manageable size. That said, to design effective heuristics, we first need to define what good matchmaking means.
In competitive game design, the ultimate goal of matchmaking is balance: every player in a match should have a roughly equal chance of winning. Achieving balance means making sure that all participants are comparable across several key characteristics:
- Players should have compatible skill level and experience.
- Players must be in the same geographic region so that their ping values are roughly equal, ensuring fair latency conditions.
- Squads inherently have an advantage over solo players. Therefore, it is preferable that squads are matched against other squads, while solo players compete primarily against other solo players.
- Due to platform-specific crossplay policies, players who have disabled crossplay must only be matched with others on the same platform.
However, it’s usually impossible to guarantee that all players in a match are perfectly equal across these parameters. The player base naturally fragments into thousands of small groups or “cells,” each containing only a limited number of players. This means players in a given match will inevitably differ from one another. To maintain fairness, the system must at least organize teams so that they are balanced on average.
Another important factor is squad size: players can be organized into squads of varying sizes, and when assigning squads to teams, the total number of squad members on each team should not exceed the team’s limit. At the same time, it’s highly desirable that the teams themselves are of equal size. This constraint adds significant complexity to the matchmaking process, making it far from a trivial task.
But even that is not the full picture! In the quest for the perfect match, matchmaking algorithms can fall into subtle traps. Consider this scenario: an algorithm somehow always assembles an ideal match according to all of the criteria. There are plenty of players in the queue, matches form continuously, and the average wait time is less than ten seconds. Yet, some players end up waiting for many minutes.
Why does this happen? Queue entry is a random process, and while the matchmaker tries to create perfect matches, there is always a non-zero chance that any individual player will not be selected for a particular match. If this selection probability — a player’s chance of being included in the next match — does not adjust based on how long they have already waited, it is possible that some players experience a streak of “bad luck,” never getting chosen. As a result, their waiting times can grow indefinitely, skewing the average and leading to frustratingly long delays.
To avoid this, matchmaking systems must include the waiting time as a factor in their decision-making. In other words, players must be guaranteed entry into a match within a finite time frame as long as matches are forming. This principle is similar to the concept of fair queueing.
Matchmaking in War Robots: Frontiers
A key requirement for the matchmaking service in War Robots: Frontiers is high throughput. Horizontal scaling (scaling out) of the matchmaker — that is, splitting the player base across multiple servers — is nearly impossible without sacrificing matchmaking quality. This is because the larger the queue, the greater the pool of players to choose from, and consequently, the better the quality of matches formed. Splitting the audience purely for performance reasons would reduce this pool and degrade match quality, which we wanted to avoid.
This constraint heavily influenced our choice of algorithms. We rely primarily on greedy algorithms with linear time complexity. This approach strikes a balance between speed and effectiveness, enabling the entire matchmaking pipeline — even with a large number of players — to complete within an impressive 10 to 30 milliseconds.
In War Robots: Frontiers, matchmaking is performed by a single-instance service. Players join the matchmaking queue via a REST API, and the service processes match assembly in a batch once every second. This pipeline consists of three main steps:
Grouping
In general, players enter the matchmaker in squads of up to six people (a single player is considered a unit of one). We refer to these squads as units. Importantly, units are never split up and are always assigned to the same team. Each player has a set of features associated with them (such as region, platform, league, and other parameters relevant to matchmaking). The unit’s features are derived from the individual players’ features, and it is these aggregated unit features that the matchmaker uses during the matching process.
Different features are aggregated in different ways. For example, the region is determined by the group leader’s location (if you join a group, you play in the leader’s region), whereas the league is selected as the highest among all unit members (if there is at least one strong player in the group, the entire unit will be matched against similarly strong opponents).
Next comes categorization, which is a process where each attribute is assigned a category based on its value. Categorization translates raw game data into simplified, discrete categories that the matchmaking system can effectively use. For example, players with a progression level below 7 are considered newbies, and we want to separate them from more experienced players. To achieve this, we define two categories representing progression level ranges:
Level:
Type: Number
Select: Max
Categories:
Ranges:
New: { From: 1, To: 7 }
Expert: { From: 7 }
Typically, a category represents a range or an arbitrary set of property values. Categories can evolve over time: new ones can be introduced, or existing ranges adjusted. For instance, we might want to divide the player base into leagues so that each league contains roughly equal numbers of players. As the player distribution changes, we may need to redefine these category ranges to maintain balance.
This categorization system gives us flexibility: matchmaking rules can be updated simply by modifying configuration settings, without altering the underlying matchmaking mechanics. Of course, in some straightforward cases, the property value itself can serve as its category, such as a player’s region, which remains unchanged.
Eventually, each unit is associated with multiple categories across different properties. Importantly, a unit can belong to multiple categories simultaneously. For example, if category ranges overlap, a unit may fit into two adjacent categories.
A bucket is defined as a unique combination of categories where, for each property, exactly one category is selected. You can think of buckets like hash table buckets: for each unit, the matchmaking system computes the full set of buckets it belongs to.
For example, a unit with categories (Region: EU; Platform: PlayStation, CrossPlay) corresponds to two buckets:
- (Region: EU; Platform: PlayStation)
- (Region: EU; Platform: CrossPlay)
Buckets can be envisioned as discrete points in a multidimensional space, where each axis represents a player property (such as Platform, Region, League), categories define partitions along those axes, and buckets are the coordinates in this space. Units can be matched together if they share at least one common bucket.
Match Building
Each bucket corresponds to a queue that holds units in the order they entered the matchmaking system. This ordering is preserved almost entirely, ensuring fair queuing: players who’ve waited longer get priority.
Teams often need to be formed from units of varying sizes, which creates a one-dimensional packing problem: fitting “boxes” (units of different sizes) into a fixed-size container (the team) as efficiently as possible. This problem is NP-hard, which means finding an optimal solution is computationally infeasible in practice.
Additionally, team sizes are somewhat flexible; incomplete teams may be allowed if waiting times grow too long, increasing the complexity with more degrees of freedom. To handle this, we employ a simple but effective heuristic inspired by classic backpack-packing techniques: packing larger units first.
- Units are first sorted by decreasing size, then by decreasing waiting time. They are assigned to teams following this priority order.
- If the current team does not have enough space for a unit, the algorithm attempts to place smaller units instead.
- This process continues sequentially through each team until either all units are assigned or all teams are filled.
- If the teams end up uneven in size, units are removed from the larger teams to balance the teams as closely as possible.
- Once both teams reach at least the minimum required size, the match is considered assembled.
Additionally, units of the same size are further sorted based on chosen player properties — such as league or skill level — to reduce disparities within the match whenever possible.
It’s worth noting that War Robots: Frontier benefits from a particularly favorable team size. In a previous project featuring matches of 10 teams with 3 players each, groups of two players often experienced longer wait times than solo players or trios. This imbalance occurred because solo players and trios naturally form complete teams, whereas pairs require a third player to fill the team, complicating matchmaking. To mitigate this, some solo players had to be strategically held back to ensure fairness.
By contrast, a team size of 6 used is divisible by both 2 and 3 — reflecting the most common group sizes — which provides more flexibility in arranging teams. Generally, choosing a prime number as team size is problematic, since it reduces these fitting options and may increase wait times.
Equalization
During the final stage, once a match is assembled, the matchmaker attempts to balance teams based on player win rates (ratio of wins to losses). The reasoning is that, in a competitive match, one team is guaranteed to win; having teams with a wide variance in win rates allows players who have lost frequently to finally achieve a win, while those with high win rates experience a loss, contributing to overall fairness.
To achieve this, the matchmaker swaps units of the same size between teams in order to minimize the variance in win rates, creating a more even competitive environment.
Compromises
If a game had a large and consistently active player base, it might be possible to define a single, fixed set of matchmaking rules that would work well indefinitely. However, the number of players at any given time is rarely constant: fluctuations occur throughout the day, across seasons, and depending on the game’s overall popularity. Many of these factors, especially popularity trends, are difficult to predict. As a result, the matchmaking system must be flexible and able to adapt to changes in the player population.
Setting up matchmaking always involves balancing three key factors: precision, fairness, and waiting time.
- Precision refers to how well matches adhere to quality criteria, such as separating players by region, league, and ensuring balanced teams.
- Fairness means rewarding players for their patience; the longer a player waits, the higher their chances of getting into a match.
- Waiting time is simply the actual duration players spend in the matchmaking queue.
If we allow waiting times to be unlimited, theoretically, we could always be waiting for the perfect combination of player properties — assuming such combinations exist in the player pool at all.
Conversely, if we disregard fairness, we might speed up matchmaking by selecting players from the end of the queue rather than the beginning, which reduces waiting time for some players at the cost of significantly longer waits for others. This approach might lower average waiting time, but increases variance and player frustration.
Finally, if we completely abandon matchmaking rules and simply admit players strictly in a First-In, First-Out (FIFO) order, fairness is maximized and waiting time minimized, but match quality becomes completely arbitrary and potentially unbalanced. Ultimately, it is impossible to optimize all three characteristics simultaneously under a fixed player population.
Waiting time is one of the factors over which we have the least direct control, as it largely depends on player patience. Data from previous projects show that the rate at which players leave the matchmaking queue gradually increases over time, spiking sharply after approximately three minutes. This three-minute mark represents an average threshold of player patience.
In War Robots: Frontiers, we enforce a strict maximum waiting time. When this threshold is reached, the match starts regardless of the number of players currently queued. However, if this were the sole mechanism, it would lead to an excessive number of incomplete or unbalanced matches. To address this, the matchmaking rules themselves are designed to evolve dynamically over time. Some aspects that can change include:
- The width and boundaries of categories (for example, a league category might expand to include neighboring leagues).
- The structure of matches (such as reducing the number of players per team).
- The interpretation of player properties (for example, a player initially assigned to region A might gradually be considered part of region B as well).
Given that these rules often change, detailing them exhaustively is impractical. Instead, it helps to conceptualize matchmaking as a discrete, multidimensional space of buckets, where each point represents a unique combination of player properties. Every player initially occupies a specific point in this space. As the rules evolve, a player’s representation expands to cover an increasingly larger volume within this space. Consequently, their probability of being matched grows because it now aggregates across multiple bucket points. Simultaneously, some buckets gain more players, increasing the likelihood of forming complete, balanced matches.
Testing
A complex system like a matchmaker requires a tailored approach to testing. Standard methods do apply — unit tests cover individual components, integration tests ensure system coherence, and load tests validate performance under stress — but these alone are insufficient. Certain matchmaking behaviors emerge only at scale, over extended time periods and large player populations. Moreover, when experimenting with new configurations or heuristics, it’s essential to rapidly test and validate hypotheses.
In War Robots: Frontiers, we employ a suite of tools to simulate matchmaking in a controlled environment. Randomly generated input data feeds the matchmaker, and the outputs are analyzed using dedicated data tools and visualized through Jupyter Notebooks.
The testing framework for the matchmaker involves two interconnected processes running within a Jupyter Notebook, communicating via a pipe. The first process is the generator, a Python script responsible for producing player input data streamed to the matchmaker via standard output (stdout). Currently, two types of generators are in use: a random data generator, which samples player properties from configurable random distributions defined in a configuration file and a deterministic generator, which reads player data from an XLSX file to enable accurate, reproducible test cases.
The matchmaker runs inside a specialized console application. This application transforms the input stream (stdin) into service calls and replaces the real-time clock with a simulated timer. This speeds up execution by running the matchmaking pipeline at the highest possible frequency rather than once per second. The matchmaker outputs a large JSON object to stdout containing the assembled matches along with additional diagnostic information. This JSON data is fed back into the Jupyter Notebook, where it is subjected to comprehensive data analysis and visualization using Python’s rich ecosystem of data tools. This setup allows deep insights into the matchmaking process and its outcomes.
The exceptional speed of the matchmaker is a key advantage here, and an hour of real-time matchmaking can be simulated in about one minute. This rapid execution significantly accelerates iteration cycles and hypothesis testing.
A central notebook maintains key matchmaker metrics such as match sizes and compositions, waiting times, and team balance diagrams. Before any new configuration reaches players, it is rigorously tested using this notebook to ensure that matchmaking quality has not degraded.
Specialized notebooks support the development of new heuristics. The matchmaker is run multiple times on random input data with two configurations: the current heuristic and the candidate new heuristic. From these runs, sequences of key metrics — such as average waiting time and match size — are collected. These sequences are compared statistically using a permutation test. If the test indicates that the distributions are statistically indistinguishable, it means the new heuristic does not significantly impact those metrics.
Interestingly, many proposed improvements that seemed reasonable and promising showed no statistically significant effect. In fact, in some cases, they even worsened performance. Given the complexity of the matchmaker, the impact of individual changes is often subtle and difficult to quantify without rigorous hypothesis testing.
In addition to randomized testing, deterministic automated tests are employed primarily for regression testing. These tests typically consist of Python functions that assert specific conditions — ensuring that matches collected under certain data and configuration setups meet expected criteria.
from mmutils.tests import matchmaker
from mmutils import nb
@matchmaker(generator="excel", data="test_example", config="test_example")
def example_test(results):
"""Example test"""
units_df = nb.units_df(results)
matches_count = units_df.Match.dropna().drop_duplicates().size
assert matches_count == 2, "Matches count"
Match finished: a conclusion
The War Robots: Frontiers matchmaker was originally designed as a universal system, building on experience from previous projects. While it has proven to be extremely flexible, it is not a one-size-fits-all solution. The specifics of gameplay heavily influence what a matchmaker can and should do.
To illustrate, in our game, we enforce a strict maximum waiting time because missing players can be replaced by bots. Without this option, such a strategy wouldn’t be feasible; other games take different approaches — some allow players to join matches already in progress.
Different games can also have other requirements, like strict team composition rules (such as fixed ratios of damage dealers, supports, and tanks).
Each of these requirements introduces unique and complex challenges for matchmaking. Despite these differences, some principles are universal. The size of the player base remains the single greatest constraint on match quality. With a sufficiently large audience, even a simple matchmaker can produce good matches. The true distinguishing factor between an effective matchmaker and a poor one is adaptability, that is, its ability to adjust to fluctuations in player population. However, no matchmaker can fully solve the problem of a critical shortage of players. Sometimes, games suffer from shrinking audiences, leading to longer queues, poorer matches, frustrated players, and accelerating decline. In such cases, it’s important to ask: is the matchmaker truly at fault?
It’s possible that the issues stem from the game design. For example, requiring too many players to start a match without bot replacements, lengthy match durations that prevent adding players mid-game, or an uneven distribution of players across skill ratings. Often, what appears to be a matchmaking problem is actually a symptom of deeper design challenges. Recognizing and separating these issues is essential for both developers and players to understand how to address matchmaking woes effectively.
And performance matters! At first, it might seem irrelevant whether the matchmaker’s pipeline takes 10 or 100 milliseconds to run, as long as it executes roughly once per second. However, this difference becomes critical when you need to iterate rapidly — making changes and verifying their effects. In these scenarios, the total test runtime can stretch to minutes or even tens of minutes. Naturally, shorter runtimes translate to faster feedback loops and more efficient development, making every millisecond count.
Observability and controllability are also essential. The matchmaker must never become a “magical black box”, and this is a temptation that’s especially strong when relying on third-party solutions. So, it’s crucial to ask:
- Can I always explain why the matchmaker formed a particular match?
- Can I simulate matchmaker behavior at various loads like 100, 1,000, or 10,000 CCU?
- Can I modify configurations dynamically, without interrupting live gameplay?
- Can I perform advanced configuration tweaks, such as merging regions, adjusting player divisions based on wait times, or applying specific rulesets to subsets of players?
- Can I easily balance match quality against wait times through configuration alone?
Perhaps the most important lesson is this: the matchmaker is not a peripheral system that can be stubbed out and deferred until after release. Neglecting its design and quality poses a serious risk because a poorly functioning matchmaker can destroy the overall player experience and undermine the entire game’s reputation. If players actually notice the matchmaking process, it’s a sign of failure — a well-designed matchmaker is invisible!
