# How to Test Multiplayer on One Computer

> Test multiplayer on one computer with Local Play in Summer Engine. Press Play to run your server plus one window per player. No account, no server.

- URL: https://www.summerengine.com/blog/test-multiplayer-on-one-computer
- Published: 2026-10-10T00:00:00.000Z
- Author: Summer Team
- Tags: Multiplayer, Testing, Tutorial, Summer Engine, AI Game Dev

Testing multiplayer used to mean four laptops and a friend on the phone. Now you can test multiplayer on one computer. You press Play and get several players side by side, each in their own window, with your server running in the background. No account. No server.

This feature is called Local Play. This guide explains what it does, why it changes how you build a multiplayer game, how to start it yourself or through your agent, what to check in every test, and where it stops.

If you have not made your game multiplayer yet, start with [how to make a multiplayer game with AI](/blog/make-a-multiplayer-game-with-ai). This post assumes you already have a client scene and a server scene.

## What is Local Play?

Local Play runs your whole multiplayer game on one computer. According to the docs on [testing it on your machine](https://docs.summerengine.com/build/multiplayer#testing-it-on-your-machine), when you press Play, Summer starts:

- **Your server scene in the background.** It runs without a screen and owns the rules, exactly as it does for a real match.
- **One game window per player.** The windows open side by side, so you can watch every player at once.
- **A test player in each window.** Every window is signed in as a different test player, so your server sees separate people with separate seats.

You choose the number of players in **Debug > Local Multiplayer**. No account, server or extra tools are needed.

Each window joins the match through your game's own join code. There is no local shortcut that you have to remove later. As the [multiplayer guide](https://docs.summerengine.com/build/multiplayer) puts it, the same code runs on your machine and once the game is published.

## Why does testing multiplayer on one computer matter?

### A short loop

A multiplayer bug usually shows up only when two players do something at the same moment. If every test needs a second machine, a second person and a shared address, you test less often, and bugs pile up. With Local Play the loop is the same as for a single-player game. Change the code, press Play, look at every window.

### Your agent can check its own work

An AI agent is good at writing game code, but it is weak at things it cannot see. Local Play gives it something to look at. Your agent can start the test, play through a feature and tell you what each window showed. That is why almost every multiplayer prompt in the Summer docs ends with a line such as "Then test it with Local Play and tell me what you saw."

When the agent starts Local Play, every window attaches to the editor. The agent sees the first player's screen and can send it input. It reads the server's output in the editor console, and stopping the game stops every window at once. To learn more about how the agent works inside the engine, read [how the engine-native agent harness works](/blog/engine-native-ai-agent-harness).

### Test the real thing

Older approaches to multiplayer, like the peer-to-peer setup in our earlier post on [multiplayer games with AI](/blog/multiplayer-games-with-ai), make one player the host. With Summer, no player is the host, and the server owns the rules. Local Play tests that same shape, so a pass on your computer means something.

## How do you start Local Play?

There are two ways. Both run the same test.

### From the editor

1. Open your Summer multiplayer project.
2. Open **Debug > Local Multiplayer** and choose the number of players.
3. Press **Play**.
4. Summer starts your server in the background and opens one window per player.

Arrange the windows so you can see all of them. Play in one window, then look at the others.

### From your coding agent

If your game is not multiplayer yet, this prompt from the [multiplayer quickstart](https://docs.summerengine.com/quickstarts/multiplayer-game) sets it up and runs the first test with two players:

```text
Make my Summer game multiplayer. Use the Summer `multiplayer` skill first to
explain how it fits my game, then `multiplayer-project` to set it up; if you
don't have them installed, find them in the Summer library.

* Read my project and tell me which parts become the server and which stay on
  each player's device before you change anything.
* Set up the client and server scenes, the World and a queue, and joining.
* Start a Local Play test with two players and tell me what you saw.
```

After that, add a Local Play test to the end of every feature prompt. For example, this prompt from the [shared state guide](https://docs.summerengine.com/build/shared-state) shares facts and then tests them in every window:

```text
In my Summer multiplayer project, make [THE FACTS, for example "the score,
the round timer and the doors"] shared and owned by the server. Use the
Summer `multiplayer-state` skill; if you don't have it installed, find it in
the Summer library.

* The server keeps each value and changes it.
* Every player sees the same values, including players who join late.

Read my project first and list every fact in my game and who should see it
before you change anything. Then test it with Local Play and tell me what
every window showed.
```

Your agent can also pick a queue. If it names a queue without a player count, Local Play starts the smallest number of players that queue needs, so a queue for 4 players starts 4. It warns when the number of players is outside what the queue allows, and it can add spectator windows. The [run and test tools reference](https://docs.summerengine.com/mcp/tools/run-and-test) lists every option. For more ready-made prompts, see our [Summer Engine MCP prompt templates](/blog/summer-engine-mcp-prompt-templates).

## What should you check in a multiplayer test?

A test is only useful if you know what a pass looks like. The docs give clear checks for each part of a multiplayer game.

### Shared facts

Every window shows the same score, timer and doors. When the server changes a value, every window updates.

### Private facts

A hand of cards, a wallet or a secret role appears only in its owner's window. The docs prompt says it plainly: "check that no other window ever shows it."

### Two players at once

Have two players try the same thing at the same moment, such as picking up the same coin. Each should get one clear answer. This prompt from the shared state guide tests exactly that:

```text
In my Summer multiplayer project, let players [COLLECT / BUY / OPEN / READY
UP]. Use the Summer `multiplayer-state` skill; if you don't have it installed,
find it in the Summer library.

* The player's game asks the server; it never changes the game itself.
* The server checks [THE RULES, for example "the player is within 2 metres
  and the coin is still there"].
* If the server refuses, the player sees why.

Read my project first and tell me which actions in my game become requests
before you change anything. Then test it with Local Play and tell me what
happened when two players tried at the same time.
```

### Movement

Walk every character around at once. According to the [movement guide](https://docs.summerengine.com/build/movement), a good run looks like this: your own character never stutters or snaps back while moving normally, and the others glide smoothly in every window.

### The end of a match

Your server ends the match and gets test rating changes back, and every window shows its own result. In Local Play, players stay connected after the match closes until they leave. Drive your results screen from the result itself, not from the disconnect. See [ending a match and showing results](https://docs.summerengine.com/build/match-results).

### Progress between runs

Local Play keeps each test player's progress in files on your computer, with the same rules as the hosted game. Quit, play again and check that coins and unlocks came back. Delete a test player's folder to start them fresh. See [saving player progress](https://docs.summerengine.com/build/player-progress).

## What are the limits of Local Play?

Local Play runs your game, not the whole hosted service. It is not proof that sign-in, matchmaking or joining a hosted match work. Plan for these differences.

- **Matchmaking is simpler.** Players are placed straight away with no real search. The accept prompt never appears. Players are not grouped by rating, and teams are handed out in turn: the first player gets team 0, the second gets team 1, and so on. See the [matchmaking guide](https://docs.summerengine.com/build/matchmaking).
- **No parties.** Parties belong to Summer accounts, so every test window plays solo through the normal Play button. Build and test that solo path first.
- **No friends, chat or shop.** These report that they are not available, so check that your game hides them cleanly and keeps working. Owned items do work if you give your test players items in the Local Play test users file.
- **Leaderboards show real data only when hosted.** Under Local Play they report that they are not available, so make sure your screens handle that.
- **Persistent Worlds start empty.** Saves are kept in memory for the run. Saving works and returns a confirmation, but nothing is kept after the run ends. Coming back to the same World after a real restart happens in the hosted game.
- **It does not pick your server size.** Your server runs on your own computer, so publish and play with as many players as you expect to choose a size.
- **Your own computer has no real network.** All windows talk on one machine, so a smooth run here does not show how the game feels across the internet. Play the hosted game with real players before launch.

None of this means you must wait to test. Build the solo path, the hidden-feature path and the core match on one computer. Then check the rest once the game is hosted.

## What should you do next?

1. Make your game multiplayer with the quickstart prompt above, or read [how to add multiplayer to your game](/blog/add-multiplayer-to-your-game).
2. Run Local Play with two players and check shared facts, private facts and movement.
3. Add a queue and test it with the right number of players. Our guide to [adding matchmaking to your game](/blog/add-matchmaking-to-your-game) covers the setups.
4. Publish on summer.games and play with real friends to check parties, chat and leaderboards.

Tell your agent "Install Summer Engine and let's make a game." Start at [summerengine.com](https://www.summerengine.com).

---

## 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