Matchmaking, Lobbies, and Parties: How Multiplayer Sessions Form

How game matchmaking, lobbies, and parties put the right players in the same match and split the work.

In video games, matchmaking is how a multiplayer game puts the right players into the same match. It is not dating, and it is not the Steam friends list. Game matchmaking is a backend job. It looks at who wants to play, what they want, and where they are, then forms a session everyone can join.

Most players never see it. They tap Play, wait a few seconds, and land in a match with a squad and opponents. Behind that tap sit three systems that share the work. They are the matchmaker, the lobby, and the party. This guide covers what each one does, how they differ, and how they combine to form a session. For the wider architecture under a live game, read our guide on how to make an online multiplayer game.

How do multiplayer sessions form?

A session forms in three moves. First the matchmaker picks who plays together. Then a lobby holds those players while they load, ready up, and lock the match settings. Then the match starts and the lobby becomes live play. A party rides along the whole way, keeping a group of friends together as one unit.

1. Queue. A player or a party joins the matchmaking pool with what they want, like ranked mode at mid skill on EU servers.
2. Match. The matchmaker forms a group that fits everyone’s criteria, pairing that party with solo players at a similar rank.
3. Lobby. The formed group lands in a room to load in and lock settings, picking characters and voting a map while the server spins up.
4. Play. The match starts and the session goes live, with the round running and the backend tracking state.
5. Regroup. After the match the party stays intact, so the squad can requeue in one tap as a unit.

What is game matchmaking?

Game matchmaking is how a backend groups players into a match using rules you set. Skill, region, and game mode are common examples.

That is the matchmaking algorithm game backends run: it reads each player’s request and compares it against everyone else waiting, then forms the group that best fits the shared criteria. A game matchmaking system usually runs this as a repeating pass over a pool of waiting players, not a one-off search, so it can weigh many requests at once.

When nobody fits, the ticket stays in the pool for the next pass. Studios then wait longer, widen region or skill, or drop the search. Tight criteria make fairer matches. Loose criteria make faster ones.

The criteria are yours to define. Common inputs are a skill rating, a connecting region, and a chosen mode. You also set the player counts and a free-text query, so a small duel and a large team battle use the same system.

Once a group is formed, the match still has to run somewhere. Some games use an authoritative game server that holds the true game state and checks every input, which is the model competitive titles use against cheating. Others relay data through a server that does not inspect payloads, for speed on trusted-client titles. Authoritative matches run a fixed simulation loop, or tick rate, to keep the world moving at a steady pace.

Here is how the two server models compare.

What is a lobby vs a party in a multiplayer game?

A lobby is a temporary room for one upcoming match. A party is a lasting group of players who queue together and stay together across matches.

So what is a lobby in gaming? It is the waiting room for a single session. Players gather there after matchmaking. They load in, pick a character or map, and ready up. Then the match begins and the lobby turns into live play. A game lobby system can also let players browse open rooms and join one directly, which is how server-browser and custom-match flows work.

A party is different. It is a small group of friends who want to play together no matter who else joins the match. The party forms before matchmaking and survives it. When it queues, the party enters the matchmaker as one block, so the whole group lands in the same match and the same lobby. When the match ends, the party stays, and the group jumps into the next one together.

The fastest way to hold lobby vs party vs matchmaking in your head is by the job each one owns.

Which matchmaking model should you pick? SBMM vs EOMM

Studios debate one choice more than any other in session formation, and it is skill based matchmaking vs EOMM.

Skill-based matchmaking, or SBMM, groups players by a rating so matches stay close. That rating math traces back to the Elo system from chess and to modern successors like Glicko. Engagement-optimized matchmaking, or EOMM, asks a different question. Instead of the fairest match, it forms the match most likely to keep a player engaged. Research on data from a popular Electronic Arts game showed EOMM can improve engagement over skill-only matching.

Neither model wins on its own. They optimize for different outcomes. Plenty of live games blend the two, with tight skill matching in ranked modes and looser, pace-driven matching in casual ones.

Here is how the two compare on the things that matter.

Should you build or buy the backend?

Before you build any of this, look at where it can live. The market splits into three shapes. Open-source self-host backends hand you the source and full control, and you run and scale them yourself. Managed game backend-as-a-service platforms run the servers for you and trade some control for less operational work. Engine-tied cloud services bake backend features into one game engine, which helps if you are all-in on that engine and limits you if you are not.

The matchmaker, the lobby, and the party travel together on that choice. Build in-house and you write all three. Buy managed and you rent all three. Hybrid means you hold the source for all three and decide how much ops you run.

The deeper question is build vs buy, and it turns on time and ownership more than features. Building your own gives total control and no lock-in, and it costs you the longest path to ship and a team that owns the backend for the life of the game. Buying gets you to players faster with far less operations work, and it hands some control to a vendor. A hybrid path, an open-source core you host or have managed, sits between them.

The real test is not a feature list. It is whether the backend is part of what makes your game different, and whether you can carry it for the decade after launch. We wrote the six-question version of that test in when to build your own game backend, a plain-language primer on the layer itself in what is a game backend, and the five-check buyer framework in how to choose a game backend.

Where our stack fits

If the hybrid path fits, that is where our Nakama comes in. Nakama is our open-source game backend. It runs the matchmaker, the lobbies, and the parties on one server. You own the whole session-formation layer instead of stitching three services together.

The matchmaker runs a pass over the pool at an interval you set, 15 seconds by default, and forms the groups that satisfy everyone’s rules. When a party queues, it passes its party ID so the matchmaker reserves room for the whole group.

Lobbies use match listing. Players browse active matches by label and join one directly. A group the matchmaker just formed joins with the match token or match ID from the matched event.

Parties keep a group of friends together. Any player can open a party, invite friends, and set it to open or invite-only, for up to 256 players.

You choose how each match runs. Relayed forwards match data through the server without inspecting it, for speed on trusted-client titles. Authoritative runs your game loop on the server at a tick rate you set from 1 to 60 Hz. You run thousands of matches on a single server, all open source under Apache 2.0.

Our Nakama already handles over 1 trillion requests a month for more than 1 million developers, studios, and publishers.

Larger studios, publishers, and enterprise teams keep the same Nakama code as a title grows and move operations to Heroic Cloud. It is our managed enterprise game backend path. It adds production ops, multi-region hosting on AWS and GCP, and a private cloud option, with no rewrite.

Matchmaking, lobbies, and parties are three jobs, not one. Put them on a single backend you own, and the session-formation layer stays in your hands. See how our matchmaker, lobbies, and parties fit together on Nakama.