Developers want to focus on connecting players together for online multiplayer game sessions, not gaming infrastructure. Google has worked alongside developers and publishers to create Open Match to solve this issue. This open source matchmaking framework provides developers with tools to build a scalable matchmaker without the overbearing tasks of managing their infrastructure when hit with a sudden surge of players. In this talk, we will explore Open Match, its features, and the benefits of building Open Match in open source.
2. Jon Foust
● Cloud Developer Advocate: Google
Cloud for Games
● STEM Instructor
● Plays a ton of multiplayer games with
long queue times
T: @syntxerror1
3. What is Matchmaking
Matchmaking enables players to be grouped together, to play a
game together. Ideally they should be grouped together by some
combination of skill level, social graph, and other factors to ensure
that players get a fair and enjoyable experience, increasing and
maintaining player retention
5. Matchmaking Issues
● Service Can Become Overwhelmed
● Long Queues
● Bad Logic
○ One-Sided Matches
● Boosting/Smurfing
6. Open Match is an open source
matchmaking framework co-founded
with Unity. It is focused on flexibility,
scalability, and extensibility. It is
written in Go and runs natively on
Kubernetes.
7. Benefits of Open Match on Kubernetes
● Breaks the monolith matchmaker into maintainable services
● Scalability
● Autorecovery
● Extensibility
8. Why Open Source?
● Collaboration results is a better solution for everyone
● Build with flexibility in mind
● No need to reinvent the wheel
10. Tickets
Tickets are the most fundamental structure of Open Match that will go through most of its
services to match players. Tickets represent matchmaking requests for a player or group
of players.
message Ticket {
string id = 1;
Assignment assignment = 3;
SearchFields search_fields = 4;
...
google.protobuf.Timestamp create_time = 6;
}
message SearchFields {
map<string, double> double_args = 1;
map<string, string> string_args = 2;
repeated string tags = 3;
}
11. Profiles
Profiles are the template for match criteria. Tickets that meet the criteria will be placed
in ticket pools.
12. Open Match Core Services
Frontend - Handles initial matchmaking
request or creating tickets, deleting tickets or
cancelling a matchmaking request, and getting
ticket details.
13. Open Match Core Services
Backend - Responsible for creating matches
and assigning dedicated game servers to
Tickets when invoked by the Director.
14. Open Match Core Services
Query - Query service will look at Ticket
pools for Tickets that have met
constraints set for matches. It will
trigger the match function to select the
Tickets that fit the mold
15. Open Match Custom Services
Match Function - Match functions are
your logic that connects players in Open
Match. Open Match will execute match
functions on ticket pools that have met
the defines match criteria
Evaluator -The Evaluator can be
customized to deal with Tickets that
meet multiple match requirements. It
will determine the quality of a match
based on a calculated score and select
the best.
17. Ticket Lifecycle: Match Request
Game
Frontend
Platform
Services
Match
Function
Machine Cluster
Dedicated
Game
Server
Dedicated
Game
Server
Game
Backend
Player Data
18. Ticket Lifecycle: Assignment
State Store
(Redis)
Game
Frontend
Match
Function
Machine Cluster
Director
Dedicated
Game Server
Dedicated
Game Server
Dedicated
Game Server
Frontend Backend
DataAccess
20. Summary
Open Match:
● Provides the core features of a matchmaker and the customizable components
that allow you add your own matchmaking logic.
● Scalable and extensible features of Kubernetes allow it to grow with your game
● Open Source good
Hi and welcome to Open Match, An Open Source Matchmaking Framework. Thank you for joining me while we explore matchmaking services, why it can be a challenge and a solution built by a community
Developer Advocate for 2 and a half years at Google and previously a software eng working on Medical software so a big yet fufilling career change
Stem Instructor for students aging from 11-18 teaching programming fundamentals using Python and C#
I’ve played a ton of games, each with their own matchmaking issues
Matchmaking enables players to be grouped together, to play a game together. Ideally they should be grouped together by some combination of skill level, lactency, and other factors to ensure an enjoyable experience
And if your players are happy they will stick by your game for a while
Firstly, Matchmaking is one of the hardest problems to solve for an Online Multiplayer Game.
Looking at the graphic, the matchmaker, depicted by the blue square, takes players connected to your game to form ‘groups’ termed as matches and connect them to game servers.
Creating a good match is critical to your games success and what constitutes a good match changes game to game.
In general, making a good match for a game is hard but is core to your game design.
Running this at a global scale for your player population presents a whole different set of challenges
Designing a matchmaking service that can run at high scale reliably is hard - and may not be an interesting problem to solve for a Game Developer
This typically means you’ve exhausted compute resources for your matchmaker and the solution isn’t “just add more servers”
No one enjoys waiting long stretches of time for matches. I personally have waiting roughly 7-10 minutes for a match which caused me to cancel my request and leave the game. A bit extreme but some players will drop games if this is recurring issue
Nothing is more enjoyable, and this is sarcasm, than playing someone with experience leagues above your own.
Easily tracks bugs, and performance issues for each service through logging and metric
When we talk about scale, we are addressing whether your matchmaker can grow with an increasing number of players. Kubernetes provides and autoscaler which can horizontally scale based on CPU and RAM usage
If a pod/service fails, containers will restart pretty quickly
Kubernetes exposes endpoints for your services which makes allows you add functionality such as load balancing and securing network traffic between services
Say all points first
A matchmaker is unique for everyone so building it for one use case won’t benefit developers. I’ve been using the term framework often because Open Match was built in mind for any developer who wants the core functionality in any matchmaker without having to build it from scratch. This give the developer more time to spend on the logic that connects your players together
The blue blocks are the external services that developers need to create to work with Open Match. This means accessing player data and authentication for matchmaking request and assigning game servers
The white blocks represent the core service of Open Match or the core functionality of the matchmaker you will build
The Pink
The custom match functions you create are the brains behind what make your matchmaker unique. You will likely spend most of your time here ensuring your players are getting into competitive matches.
The query service triggers the matchfunction and will look for tickets in the pool that will meet any match requirements.
I used the word “any” because a ticket can be selected for multiple matches which is ideal if you want to shorten queue times but how do you select the best match?
This is where the evaluator comes in. It will look at proposed matches and determine quality based on a score.
A fundamental example is the evaluator will look at the tickets selected for matches and get an average total queue time for them all and use its value as a score. The evaluator will then select the matches with the highest average queue times to get those players out of the queue fastest.
Here is the flow of what you can expect when you submit a matchmaking request through Open Match
Your clients will connect to your game frontend to submit the request to Open Match once it has access the players data
The ticket will then find its way into Open Match where it is stored in a state store, which for open match is Redis, along with all the other tickets that come in
Your ticket will then be filtered into a ticket pool along with all other tickets that meet this criteria for this match
The match function which is triggered by the query service will then create proposed matches and which will await assignment
So now for the assignment, the director will provide game server addresses which are assigned to tickets in the backend
Once the tickets are updated in the state store, the frontend will listen for tickets that have been assigned and send a response or the assignment to the game frontend and ultimately the client
For resources on Open Match, check out Open Match . dev which provides documentation, tutorials, samples, and links to the Open Match GitHub. There are also links to join the Open Match slack channel and a monthly community meeting
If you want to check out the solutions that Google is working on, check out our cloud gaming solutions page
And if you have no experience with Kubernetes I highly recommend visiting Kubernetes.io for a look at all Kubernetes has to offer