Test multiplayer without making builds.

Why multiplayer testing usually stalls

Ownership, prediction, join order and disconnects only misbehave with real clients. The usual fix is a player build, several copies and alt-tabbing, then a rebuild for every change.

Clones instead of builds

Each extra player is a real hidden Unity editor on a stub project that links your Assets and Packages and reads the main Library, the technique behind Unity's Multiplayer Play Mode. Nothing re-imports, so a clone boots in seconds.

Every client is an editor, so:

• One Play button starts the grid; pause, frame step and stop drive every player.
• Each clone has its own stream, console and injected input, so you can grab one and play.
• Every clone hot-reloads with the primary, so a fix reaches all four.
• Clones pick up the primary's asset and scene changes as they sync.

Letting an agent run the match

An agent adds players with satura_exec on the Unity MCP server, opens the scene with unity_open_scene, and calls your handles with unity_exec on one player or all of them. unity_logs reads each player's console and tag logs.

One handle covers the whole match:

[SaturaHandle("Host starts the match, clients join and move")]
public static IEnumerator HostOrJoin()
{
    if (SaturaHandles.PlayerIndex == 0) yield return StartHost();
    else                                yield return JoinAndMove();
}

The agent starts it everywhere at once with unity_exec(player="all") and SaturaHandles.StartAt(SameMoment(3), "HostOrJoin"). Every player runs it on its first frame after that moment and reports its own result. The agent reads them, fixes what broke and re-runs, and with no build in the loop that cycle is short.

The limits of an editor client

Clones are editors: Mono, the editor asset pipeline, editor performance. They find logic and netcode bugs early; still test an IL2CPP build on target hardware before you ship.