MatchMaking For Online Multiplayer Games
If you enjoy online games, I am sure you are familiar with the matchmaking system for multiplayer games. I would like to talk about this simple yet complex match-making system used in online games.
When multiple players gather together in the virtual space to play games, we need ways to have the players find each other. This “finding” other player is called matchmaking.
Many games have implemented their own take of this matchmaking system for their games and they still do. This critical system for multiplayer games seems simple, but it is notoriously difficult to get it right.
A good match-making system should be able to categorize the players by their attributes such as in-game ranking, skill levels, and in-game scores, etc.
Match-making profiles (rules for matchmaking) use these categories derived from the players to search for matches and create sets of matched players so that the game can group these matched players together to begin online multiplayer game sessions.
Traditionally, there are two most common ways to implement a matchmaking system for online multiplayer games. These two different implementations only differ in terms of data storage.
When using RDB (Relational Database), the player search is done by SQL.
The game will add players with category attributes to the database and search the players to create matches. The implementation using SQL is straightforward and simple, however, it is not as simple when it comes to scalability and availability.
Scaling the match-making system with RDB largely depends on the scalability of RDB.
It means that the scalability limit is the master-slave scalability of RDB.
Maintaining such a matchmaking system can be difficult and costly. Match-making data is by nature temporary, but stored data of RDB is persisted.
Along with scaling difficulty, this implementation approach also comes with potential single-point-of-failure. If the database fails, the entire matchmaking system fails and it is costly and complex to make this approach redundant.
Lastly, optimizing the performance completely depends on the performance of SQL and usually, this type of SQL execution can be slow and expensive.
In order to overcome the possible performance issue, the RDB approach typically uses a background process to scan the database to create matches instead of searching on the fly. By using the background process, it is easier to control the workload on the database. The trade-off of this approach is that the matchmaking search is not real-time so that the chance of matches not relevant anymore or stale by the time the players execute search is potentially high leading to longer waiting time etc.
An alternative approach to using RDB is to use server process’ memory as match-making data storage. Unlike using RDB, searching in memory is much faster and cheap. You also do not need to run and maintain massive database servers either.
This strategy seems great at first glance, however, it too has its own problems. The most obvious issue is scalability. You are limited to a server process’ memory, which means that you cannot possibly handle a large number of players as your performance limitation is your server’s performance.
How about use a key-value memory store such as Redis and set it up as a cluster so that it can scale more than a single server process? The answer is, of course, you can, but you now have to maintain external data storage servers just like maintaining database servers. Also, the key-value memory store is rather weak when it comes to querying and searching data because there is no query system (There are some exceptions, of course).
If your online multiplayer game does not have to scale, this approach might work, but usually online multiplayer games expect a large number of players, so this scaling issue could prove to be a fatal problem.
In conclusion, building a matchmaking system that both performs well and scales is rather difficult. Additionally keeping high availability can be challenging. In reality, we need to consider our options and make decisions based on what we need to achieve and the trade-offs that come with those decisions.
The matchmaking system that every gamer knows and loves/hates around the world takes considerable effort to make work smoothly without the players knowing. When you play an online game next time, it may be more enjoyable to think about what goes on behind the scene and appreciate the work and effort required for the game you are playing.
There is a new approach to the in-game matchmaking system that could be a complete game-changer. This new matchmaking system looks at the matchmaking system from a completely different angle and provides the solutions to almost all headaches when building a match-making system.
Diarkis MatchMaker is a solution that can be added to your existing online multiplayer games. As the name suggests, it is a matchmaking system that is scalable and failure resistant.
It uses distributed memory storage to manage the matchmaking data. Diarkis MatchMaker distributes and synchronizes matchmaking data across multiple servers that are auto-scalable. This eliminates a single point-of-failure and the scalability issue completely.
Extremely fast search is possible because everything is stored and managed in memory. Unlike the database approach, Diarkis MatchMaker stores and manages its data in memory so that searching and updating the data are both fast and cheap.
There is no need for a background process to create matches at all and this means true real-time matchmaking. The players are able to search for their matches on the fly instead of querying pre-matched, potentially outdated matches.
In the near future, an approach similar to Diarkis MatchMaker may become the new norm and change the way we play and enjoy online multiplayer games.
For inquiries about Diarkis introduction, employment entry, etc., click here.