Multiplayer skill for AI agents

​

When your agent uses it

• The user wants multiplayer, co-op, PvP, online play over the internet, or to play with friends in a Summer game
• The user asks for peer-to-peer, a player-hosted server, host migration, join-by-IP or a lobby
• Deciding how a multiplayer Summer game is structured before writing networking code
• A multiplayer game was built with @rpc or MultiplayerSynchronizer and needs moving to Summer’s networking

​

Install

npx -y summer-engine@latest skills install multiplayer --agent claude-code

​

The skill

​

The picture

• the client scene, which every player runs: input, camera, visuals, UI;
• the authority scene, which runs headless as the match server and owns the rules.

   each player's device                   Summer hosting (or Local Play)
  ┌──────────────────────┐  my pose       ┌──────────────────────────────┐
  │ client scene         │ ─────────────► │ authority scene = one World  │
  │ moves its own player │  "collect"     │ checks every pose and request│
  │ draws everyone else  │ ─────────────► │ owns score, doors, items...  │
  │                      │ ◄───────────── │                              │
  └──────────────────────┘  state, events └──────────────────────────────┘

• A running match is a World. Summer starts one authority for it; the game declares what a World is in world.json (a WorldDefinition).
• A player joins with Summer.client.join(...) and gets a verified Session: their seat in that World, with a verified player identity.
• Players find a World through a queue in summer.build.json. Hosted, Summer’s matchmaking fills it; locally, Local Play starts the authority and N clients on your machine.
• The same code runs locally and hosted. No if server, no local-only branches, no IP addresses.

​

How data moves

​

The rules

1. Each client moves its own character. Movement feels instant on every connection. The authority accepts or refuses each pose, and a refused pose snaps the player back.
2. The authority owns every other fact. Clients never change shared state; they send a Command and show the result.
3. Identity comes from the Session, never from a field a client sent.
4. Never use the stock high-level multiplayer API in a Summer game: no @rpc, MultiplayerSynchronizer, MultiplayerSpawner, ENetMultiplayerPeer, multiplayer.is_server() or peer-ID branches. Their sender ids are transport peers, not verified players. Late joiners miss state, and the game cannot use Summer hosting, matchmaking or identity.
5. Test under a bad network before calling anything done: Local Play with latency, jitter and loss (multiplayer-testing).

​

Words

​

Build it in this order

1. multiplayer-project: the files, both entry scenes, joining, and a first Local Play run.
2. multiplayer-movement: each player moves their own character; others see it smoothly; the authority checks every pose.
3. multiplayer-state: score, doors, private inventories, Commands and Events.
4. multiplayer-testing: Local Play under latency and loss, bots, and what a passing run must show.
5. multiplayer-publish: export the summer.games bundle and upload it as a Build.
6. release-readiness: before players get a version, prove the server starts its authority scene and a real online join works.

​

Add Summer services

​

What people ask for, and what Summer does

​

Start

• None of them: start with multiplayer-project.
• They exist: pick the skill for the piece you need from the tables above.
• The game already uses @rpc or MultiplayerSynchronizer: tell the user it needs moving to Summer’s networking. Then follow multiplayer-project and port one system at a time: movement first, then state.

​

From a shell

​

Related skills

• multiplayer-project: Set up a Summer multiplayer project: entry scenes, World and queue files, joining, a first Local Play.
• multiplayer-movement: Movement in Summer multiplayer: owners move instantly, others glide, the authority checks each pose.
• multiplayer-state: Authority-owned state in Summer multiplayer: shared and private State groups, Commands, Events.
• multiplayer-testing: Test a Summer multiplayer game with Local Play: several players, bad network, bots, a passing run.
• multiplayer-publish: Ship a hosted Summer multiplayer game: the bundle, server preset, pre-upload checks, a new Build.
• release-readiness: Before releasing a Summer game version, prove players can play it: server, online join, progress, files.
• summer-matchmaking: Get players into matches with Summer matchmaking: queues, teams, accept prompts, join progress and failures.
• summer-player-data: Save a player’s progress so it follows them to every match: authority load and commit, autosave, safe retries.