# How to Add Matchmaking to Your Game

> Add matchmaking to your game in Summer Engine. Quick play, ranked queues, fixed teams and an Accept prompt, with the real prompts and a server per match.

- URL: https://www.summerengine.com/blog/add-matchmaking-to-your-game
- Published: 2026-10-10T00:00:00.000Z
- Author: Summer Team
- Tags: Multiplayer, Matchmaking, Tutorial, Summer Engine, AI Game Dev

You can add matchmaking to your game in Summer Engine by telling your coding agent which queue you want. Quick play, ranked queues, fixed teams and an Accept prompt are built in. A player presses **Play**, waits a moment, and lands in a match with other people. Summer starts a server for every match.

This guide goes deeper than our overview of [how to make a multiplayer game with AI](/blog/make-a-multiplayer-game-with-ai). It covers what each matchmaking mode does, when to pick it, the exact prompts from the docs, how a match gets its server, and what you can and cannot test on your own computer.

## Why is matchmaking the hard part of a multiplayer game?

Most multiplayer prototypes stop at a lobby with an address or a code. That works for two friends on a call. It does not work for strangers who just want to press Play.

A real game matchmaking system has to do several things at once:

- keep a list of everyone who is searching, per game mode;
- group them fairly, by arrival order or by skill;
- split groups into teams without breaking up friends;
- handle the player who walks away from the screen;
- find a server for each match and send every player to the same one;
- tell the server who is on which team.

Each of those is its own piece of infrastructure. Your coding agent can write a search screen, but it cannot run a queue service or start servers on demand. That is why matchmaking usually gets left for later. In Summer it is part of the platform, so your agent writes the menus and the game, and Summer runs the rest. Our older guide to the [online multiplayer game maker landscape](/blog/online-multiplayer-game-maker) explains why this layer has always been the hard one.

## How does matchmaking work in Summer Engine?

According to the [matchmaking guide](https://docs.summerengine.com/build/matchmaking), you describe your game modes as **queues**. Summer groups the players who are searching, starts a server for each match, and sends every player in that match to it. Nobody shares an address or an invite code.

From the player's side there are three steps:

1. **Search.** The player picks a mode and presses Play. Your game shows the search progress, and the player can cancel at any time.
2. **Match found.** Summer has grouped enough players. If the queue requires accepting, the match starts once every player has accepted.
3. **Into the match.** Summer starts a server for the match, and every player joins that same World. On a team queue, your server already knows who is on which team.

Your game decides what each step looks like: the search screen, the prompt and any countdown. Summer handles grouping players, reserving the server and getting everyone into it.

Three words help here. A **World** is one running match, run by one server. A **session** is one player's seat in a World. A **queue** is how players find a World, such as "casual" or "ranked 2v2". The [multiplayer guide](https://docs.summerengine.com/build/multiplayer) explains how they fit together.

## Which matchmaking mode should your game use?

Each mode below is one queue. A game can declare several, for example a casual queue and a ranked queue. Pick based on how many players you expect and how much a single match means to them.

| Mode | How it groups players | Pick it when |
| --- | --- | --- |
| Quick play | First come, first served, no skill check | Casual modes, party games, a new game with few players |
| Ranked | Similar ratings first, range widens with waiting | Duels and competitive modes where skill matters |
| Fixed teams | Exactly enough players to fill every team | 2v2, 3v3 or 5v5 team modes, with parties kept together |
| Accept prompt | Every player confirms before the server starts | Long, committed matches where one absent player ruins it |

### Quick play

Players are matched in the order they started searching. There is no skill check. This is the right first queue for almost every game, because a new game rarely has enough players for skill matching to feel fast.

### Ranked

Summer keeps a rating for every player in the queue and matches players with similar ratings first. If a player waits a while, the range of ratings they can be matched with widens. So a player is not stuck searching forever just because nobody near their rating is online.

### Fixed teams

Every match holds exactly the number of players needed to fill every team. Summer splits them into teams, and friends who queued together as a party always land on the same team. In a ranked team queue, Summer picks the most even split of ratings it can find.

### Accept prompt

Before Summer starts the server, every player has to accept. The docs give the example of a 30 minute ranked game, where you do not want one player who is away from the keyboard to ruin it for nine others. A player who declines leaves the queue, and everyone else goes back to searching without losing their place in line. If the timer runs out, the match does not start. Your game can also skip the prompt and accept for the player as soon as a match is found.

## How do you add matchmaking to your game step by step?

Your game needs to be multiplayer first, with a client scene and a server scene. If it is not yet, start with our guide to [adding multiplayer to your game](/blog/add-multiplayer-to-your-game), then come back here. Every prompt below is copied from the docs. Replace the words in square brackets with your own values.

### 1. Plan your queues with no code

If you are not sure which modes fit, ask your agent for a plan first. It reads your project and changes nothing.

```text
Read my Summer project and help me plan its matchmaking. Use the Summer
`summer-matchmaking` skill; if you don't have it installed, find it in the
Summer library. Don't change any files yet.

Tell me:

1. which queues my game should have (quick play, ranked, teams, accept
   prompt) and how many players each holds;
2. what the player sees from the main menu to the first second of a match;
3. anything my design needs that matchmaking doesn't cover yet, and how we
   can build around it.
```

### 2. Add quick play

This gives you a Play button, a searching screen with Cancel, and joining the match.

```text
In my Summer project, add a quick-play matchmaking queue. Use the Summer
`summer-matchmaking` skill; if you don't have it installed, find it in the
Summer library.

* Matches hold between [MIN] and [MAX] players, first come, first served.
* Give the player a Play button, a status line while searching, and a Cancel
  button.
* When the join fails, show the player why and let them search again.

Read my project first and fit this into my existing menus and scenes rather
than adding new ones. Then test it with Local Play and tell me what you saw.
```

### 3. Add a ranked queue

Ranked needs a match ending, because the server reports who won so ratings can move. That is why this prompt uses a second skill.

```text
In my Summer project, add a ranked matchmaking queue next to any queue I
already have. Use the Summer `summer-matchmaking` skill, and the
`summer-match-results` skill for ending a match; if you don't have them
installed, find them in the Summer library.

* Match players by rating. [1v1 / two teams of N]
* When a match ends, the server reports who won so ratings update.
* Show the player their rating before and after a match.

Read my project first and explain where the rating appears in my UI before you
change anything. Then test it with Local Play and tell me what you saw, and what
only works once the game is hosted.
```

### 4. Add a team queue

Your server reads each player's team when they join, so spawn points and scoring can use it.

```text
In my Summer project, add a matchmaking queue with [COUNT] teams of [SIZE]
players. Use the Summer `summer-matchmaking` skill; if you don't have it
installed, find it in the Summer library.

* The server reads each player's team when they join and uses it for spawn
  points and scoring.
* Each player sees which team they're on, and who their teammates are.
* [Match by rating / first come, first served].

Read my project first and tell me what in my game needs to know about teams
before you change anything. Then test it with Local Play and tell me what you
saw.
```

### 5. Add the Accept prompt

Add this to any queue you already have.

```text
In my Summer project, make my matchmaking queue [QUEUE] ask every player to
accept a found match within [SECONDS] seconds. Use the Summer
`summer-matchmaking` skill; if you don't have it installed, find it in the
Summer library.

* Show Accept and Decline buttons and a countdown when a match is found.
* If the player declines, or anyone doesn't accept in time, go back to the
  menu and let them search again.

Local Play never shows this prompt, so make sure the rest of the flow still
works there, and tell me what I can only check once the game is hosted.
```

### 6. Let parties queue together

Players make parties in the Summer app. With the [parties guide](https://docs.summerengine.com/build/parties), the leader's Play button starts one search for the whole party, and every member follows. A player who is not in a party plays solo with the same Play button. Its prompt begins "In my Summer project, let players who are in a Summer party play together." Copy the full version from the docs.

## How does a match get its server?

When a match is found, and accepted if the queue asks for it, Summer starts a server for that match. Every player in the match joins that same World. No player is the host, so nobody ends the match by leaving. If someone quits or drops out, everyone else keeps playing.

You choose two things for that server, as the [server size guide](https://docs.summerengine.com/build/server-size) explains:

- **How many players a World holds.** Each kind of World sets its maximum, from 1 up to 1,024. A matchmaking queue for that World uses the same maximum, and its minimum is how many players it needs to start.
- **How much power the server has.** Sizes run from Small up to 8XL. Turn-based games can start on Small, real-time matches with physics on Standard. Different kinds of World can have different sizes, so a small 1v1 duel can run on Small while a bigger mode runs on a larger size.

Your choice is saved with each version of your game. Publishing a new version with a new size changes the servers for new Worlds, and running Worlds keep the size they started with.

## How do ratings move after a ranked match?

A match ends when your server says so. The server decides the outcome for every player: a win, a loss, a draw, or leaving early. Summer records that result once. If your server sends the same result again, for example after a network problem, Summer keeps the first one.

On a ranked queue, Summer then moves every player's rating with Elo. Beating a stronger player is worth more than beating a weaker one. New players start at 1200, or at a starting value you choose. If Elo does not fit your mode, your server can decide each player's rating change itself. The [ratings and leaderboards guide](https://docs.summerengine.com/build/leaderboards) covers both, plus a public top 50.

## How do you test matchmaking on one computer?

Local Play runs your server and several game windows on one computer, so you can test a queue without hosting anything. Our guide to [testing multiplayer on one computer](/blog/test-multiplayer-on-one-computer) walks through Local Play in full. For matchmaking, it differs from the hosted game in three ways:

- Players are placed straight away, with no real search.
- The Accept / Decline prompt never appears.
- Players are not grouped by rating. Teams are handed out in turn: first player, team 0; second player, team 1; and so on.

Parties also do not exist in Local Play, because they belong to players' Summer accounts. Every test window plays solo through the normal Play button. Build and test that solo path first. Your server can still end a match under Local Play and get test rating changes back, so you can test the whole end of a match.

## What are the limits today?

- **Searching, skill matching and the Accept prompt need a hosted game.** Local Play cannot show them, so check them after you publish.
- **Hosted matchmaking is for published games built with Summer 0.7 or later.** That is the release where multiplayer arrived, as the [0.7.0 release notes](https://www.summerengine.com/changelog/0.7.0) say.
- **Parties are hosted only.** Guest players, and younger players who are not offered social features, also play solo, so the solo path matters for them too.
- **A shared world that keeps running is not a match.** Matchmaking can still place players into it, but that world needs to be a persistent World rather than a match.
- **Local Play does not pick your server size.** Publish and play with as many players as you expect, then move up or down a size.

## What should you do next?

Start with one quick play queue. It works with few players, and you can add ranked, teams and the Accept prompt later without changing how players reach a match. When it plays well, publish your game. A multiplayer game goes to the Summer apps on iPhone, Mac and Windows, and Summer runs its servers from then on.

For a longer look at building multiplayer with AI, read [multiplayer games with AI](/blog/multiplayer-games-with-ai).

Tell your agent "Install Summer Engine and let's make a game."

---

## Machine-readable resources

- Site index for agents: https://www.summerengine.com/llms.txt
- Full inlined content: https://www.summerengine.com/llms-full.txt
- Porting catalog: https://www.summerengine.com/llms-porting.txt
- Structured catalog: https://www.summerengine.com/agent-catalog.json
- Sitemap: https://www.summerengine.com/sitemap.xml
- Developer resources: https://www.summerengine.com/docs