How to Add Multiplayer to Your Game

You can add multiplayer to your game with one prompt. Open your Summer project, tell your coding agent to make the game multiplayer, and it splits the game into a client and a server, adds joining, and opens several players side by side so you can test right away.

Multiplayer shipped in Summer Engine 0.7.0 on October 7, 2026. The 0.7.0 release notes put it in one line: "You can now build multiplayer games." This post covers the first step in depth: what the agent sets up when you ask for multiplayer, why building it into the game beats adding it on top later, and how to move a single-player game online one piece at a time.

If you want the full tour of everything Summer runs for a multiplayer game, such as parties, persistent Worlds and leaderboards, read how to make a multiplayer game with AI. This guide stays on the first prompt and the changes that follow it.

What shipped in Summer Engine 0.7.0

Your game can now be multiplayer from day one. According to the multiplayer quickstart, Summer runs a server for every match, brings players together through matchmaking, keeps their progress and ranks them on leaderboards. You do not rent or manage any machines. You describe the game you want, and your coding agent builds it with Summer's skills.

The quickstart starts with a single prompt. Copy it into your coding agent with your Summer game open.

Make my game multiplayer. A client and a server, joining a match, and a first test with several players.

What does the agent set up when you add multiplayer

The guide to making your game multiplayer describes the result. Your project gets two starting scenes, a way to join, and a first test run.

A client scene and a server scene

A Summer multiplayer game is one project with two starting scenes.

• The client scene is what every player runs. It holds input, camera, visuals and menus.
• The server scene runs without a screen and owns the rules. It holds the score, the doors and who won.

The split is the core of the change. Anything a player sees or touches stays on the client. Anything that decides the outcome of the game moves to the server.

Joining a match

Players need a way into a running game. The docs use three words for this.

• World. One running match or shared place, run by one server. A 10-minute round is a World, and so is a server that stays up for weeks.
• Session. One player's seat in a World. Summer checks who the player is before they get one, so your server always knows exactly who did what.
• Queue. How players find a World, such as "casual" or "ranked 2v2".

A first test with several players

The last part of the prompt is the test. The agent starts Local Play, which runs your whole multiplayer game on one computer. Summer starts the server scene in the background plus one game window per player, side by side, each signed in as a test player. You choose the number of players in Debug > Local Multiplayer, and no account, server or extra tools are needed. For a closer look at this step, read how to test multiplayer on one computer.

Why build multiplayer in instead of adding it later

Multiplayer has a reputation as something you bolt on at the end. That usually means a second program for the server, a separate build to keep in sync, and a list of shortcuts that only worked on your own machine. Summer avoids each of those.

• One codebase. The same code runs on your machine and once the game is published. There is no separate server version to keep in sync.
• Nothing to remove later. There are no local-only shortcuts, so what you test is what players get.
• No host. Summer runs the server for every match. No player has to host and nobody shares an address. If someone quits or drops out, everyone else keeps playing, and a player who reconnects in time gets their seat back.
• Fair by default. The server checks every move and request, so a modified client cannot give itself points, speed or items.
• The same account everywhere. Players sign in once with their Summer account, and your game sees their name in every match.

This also matters for your agent. An agent writes game code well, but it cannot see a server you forgot to start or an address a friend typed wrong. With the server and joining built into the engine, the agent has a clear target: two scenes, a way in, and a test run it can start itself. For more on why the engine works this way, see what an AI game engine is.

How to add multiplayer to your game step by step

These steps take an existing single-player game online. Each prompt comes from the Summer docs.

1. Ask for a plan first. If you are not sure how multiplayer fits your game, start here. No code is written.

   Explain how multiplayer would fit my game. No code, just a plan.
   

2. Make the game multiplayer. This is the one prompt that sets up both scenes, joining and the first Local Play run.

   Make my game multiplayer. A client and a server, joining a match, and a first test with several players.
   

3. Make movement multiplayer. Your existing character controller keeps working. The prompt below makes it instant for the player and checked by the server.

   Make my character move in multiplayer. Instant for the player, checked by the server, smooth for everyone else.
   

4. Share the game world. Move the facts every player must agree on to the server.

   Share the score, doors and timer. The server owns them; every player sees the same values.
   

5. Route player actions through the server. Picking up, buying, opening and readying up become requests.

   Let players ask the server. Collect, buy, open or ready up, checked by the server.
   

6. Test on a bad connection. Your own machine has no lag, which hides timing problems.

   Test my multiplayer game on a bad connection. Several players, real lag, and what a passing run shows.
   

7. Add a way to find a match. For a casual game, start with quick play. The full setup is in how to add matchmaking to your game.

   Add quick play. A Play button, a searching screen with Cancel, and joining the match.
   

For more ready-made prompts you can paste, see the Summer Engine MCP prompt templates.

What changes in your single-player code

Going from single-player to online changes who owns each part of the game. Here is what the docs say happens to each part.

Movement stays on the player's device

Input, walking, gravity, jumping and collision all keep running on the player's own device. About 20 times a second, the game sends the character's position and facing to the server. Your server decides what is allowed, such as a top speed and the edges of the level, and gives a little leeway for jumps and falls so normal play never snaps back. A move that is too fast or out of bounds is refused, and that player snaps back to where they last were allowed to be.

Other players are drawn a fraction of a second in the past, gliding between positions, so they move smoothly even when packets arrive late. The movement guide has the details, including respawns and teleports set by the server.

Game facts move to the server

Apart from each player's own movement, your server owns every fact in the game: the score, the round timer, which doors are open, what is in each inventory, who won. Players never change those facts directly. They ask the server, the server checks the request, and then everyone sees the result. A player who joins mid-match gets the current score and doors straight away. Private facts, such as a hand of cards or a secret role, only reach the player they belong to. See sharing the game world.

Effects become one-off messages

A sparkle when a coin is collected, a sound or a hit flash is sent to everyone once, as it happens. These are not kept, so a player who joins later does not replay old sparkles.

How to check the first test passed

Local Play gives you several windows at once. A good run looks like this.

• Your own character never stutters or snaps back while moving normally.
• The other players glide smoothly in every window.
• Every window shows the same shared facts, such as the score and open doors.
• Private facts only show in their owner's window.
• Two players trying the same thing at once each get one clear answer.

Then run it again with added delay, jitter and packet loss. Local Play can add all three to every window, so you see what players on a real connection will see. Run it that way before you call a feature done.

What are the limits today

• Local Play is not the hosted game. Players are placed straight away with no real search, the Accept / Decline prompt never appears, and players are not grouped by rating. Searching, matching by skill and the accept prompt all need a hosted game.
• Your machine has no lag. A test without added delay hides timing problems, so always do a second run on a bad connection.
• A single-player game may not need a server at all. Items, a shop and analytics work without one. Add a server when saves should follow the player everywhere. See the single-player and mobile guide.

What to do next

When your game plays well with several players, get it ready to publish. Your agent can prepare the project.

Get my multiplayer game ready to publish. Server preset, platform checks and one summer.games export.

A multiplayer game can go to iPhone, Mac and Windows, and Summer runs its server for you. The publishing guide walks through each step.

If you are comparing ways to build an online game, online multiplayer game maker covers the kinds of tools that exist, and multiplayer games with AI covers how agents help with networking in general.

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