Every other page explains one feature. This one is the map: what you actually do, in order, to get a multiplayer game shipped — whether you're starting fresh or adding multiplayer to a game you've already built.

1. Connect the editor (about 3 minutes)

Identical for every project:

1. Install the addon — one line in a terminal at your project root:

   iwr https://spawnweaver.dev/install.ps1 -UseBasicParsing | iex   # Windows
   

   curl -fsSL https://spawnweaver.dev/install.sh | bash             # macOS / Linux
   

2. Enable the plugin — Project Settings → Plugins → SpawnWeaver. The SpawnWeaver autoload registers itself; that's your whole API surface.
3. Click "Get a free key" in the SpawnWeaver dock. Your browser opens, you approve (signing up right there if you're new), and the key appears back in the editor — saved and connection-tested. Nothing to copy or paste.

No server to deploy, no backend code, no account needed until step 3. If you'd rather not sign up yet, SpawnWeaver.start_offline() runs the whole API locally with no account at all — see Offline mode.

2a. Starting a new game

Click Generate starter scene in the dock, then Playtest ×2. Two windows open; one creates a room, the other joins with the code, and two characters move around in sync.

You now have a working multiplayer game to modify instead of a blank file to fill. Everything in it uses the same public API you'd write yourself — read it, delete the parts you don't want, keep the calls.

2b. Adding multiplayer to an existing game

The realistic case, and the one SpawnWeaver is shaped around: your single-player code keeps working. You add nodes, not rewrites.

Give players a way in. Drop a LobbyBrowser node into your menu scene. You get quick match, a live list of open games, and join-by-code, styled by your project's theme. Connect one signal:

$LobbyBrowser.entered_room.connect(func(room):
    get_tree().change_scene_to_file("res://level.tscn"))

Prefer your own menu? Call the API directly — find_match(), create_room(), join_room(code) — see Rooms and Matchmaking.

Spawn everyone. Add a PlayerSpawner to your level and point it at your existing player scene. It creates one avatar per player, removes them on leave, and re-syncs correctly after a reconnect.

Replicate movement. Put a SpawnSync node inside your player scene. The local copy sends its transform; remote copies interpolate smoothly. Your movement script doesn't change at all — this is the step where the game becomes multiplayer.

Guard your input with window focus. Godot's Input.is_physical_key_pressed() and get_global_mouse_position() read global OS state, not per-window input — so two test windows will both react to one keypress unless you check:

func _physics_process(delta):
    if not get_window().has_focus():
        return          # another instance owns the keyboard right now
    # ... your normal movement code

Every multiplayer game needs this, and it surprises almost everyone the first time they run two windows.

3. Decide what your game shares

This is the part no SDK decides for you, and getting it right early saves rewrites. Three buckets:

The classic mistake is putting the scoreboard in events: it works perfectly until someone joins late and sees 0–0 forever. If it must survive a join, it's state.

Who decides what? SpawnWeaver relays messages; it never runs your game logic. The normal pattern:

• Each player owns their own entity — their position and health. Nobody else writes it (the server enforces this).
• The host owns shared truth — the scoreboard, the match timer. Check SpawnWeaver.is_host, and let host migration hand it to someone else when the host leaves.

The arena tutorials use client-authoritative hits (the shooter decides). That's right for co-op and casual games, and wrong for competitive ones — see Best practices for the trade-offs.

4. Test like it's real

• Playtest ×2/×3/×4 in the dock — each window gets its own player identity automatically.
• Kill a window mid-match and relaunch it. The SDK reconnects on its own and resumes the same room inside the 60-second grace window. Make sure your UI handles the reconnecting and room_left signals instead of freezing.
• Watch the debugger while you play: live rooms, every player's entity state updating in real time, per-session timelines, and errors with suggested fixes.

5. Ship

1. Create a separate production project so live players never share rooms or storage with your test builds. One project per environment.
2. Export normally. Your public key ships inside the build (that's what it's for — it's public by design), and the plugin bundles the config automatically. Desktop and web exports both work; see the FAQ for the web caveats.
3. Re-read Limits & quotas against your real traffic — send rates, entity counts, storage sizes — and fix anything over budget before players find it.
4. Expecting a launch spike? Tell us ahead of time and we'll size your project's limits for the day.

How long this actually takes

That last row is the honest one. SpawnWeaver removes the infrastructure and the plumbing; it doesn't remove game design. What you save is the month you'd otherwise spend building and operating a backend.

Where to go next