Test multiplayer without making builds.

Why multiplayer testing usually stalls

You can reason about single-player logic from the code alone. You cannot do that with netcode. Ownership, prediction, reconciliation, join order, late joins, disconnects: these only misbehave once two or more real clients are talking to each other, and reproducing them means getting several clients into the same state at the same time.

The conventional answer is to build a player, launch two or three copies, alt-tab between them, and rebuild for every change. The build is the expensive part, and it sits directly in the middle of the loop.

Clones instead of builds

Satura Space adds each extra player as a real hidden Unity editor, not a built player. The clone is pointed at a small stub project that links back to your Assets and Packages and reads the main project's Library, which is the same technique behind Unity's Multiplayer Play Mode. Nothing is re-imported, so a clone boots in seconds rather than minutes.

Because every client is an editor instance, the whole session shares one code path:

• One Play button starts the entire grid at once.
• Every clone gets its own live stream in the app, so you watch four viewpoints side by side.
• Every clone gets its own Unity console, filterable per player.
• Every clone receives its own injected mouse and keyboard, so you can grab one and play while the others run.
• Every clone hot-reloads along with the primary, so a C# fix reaches all four clients without a rebuild.

Letting an agent run the match

The version worth setting up has an agent driving those four windows instead of you. Through the Unity MCP server an agent calls unity_add_player to shape the grid, opens a scene, enters Play Mode, and runs a TddScenario across every client at once.

The scenario branches on which client it is running as, so one file describes the whole match:

public class HostJoinTest : TddScenario
{
    public override IEnumerator Run()
    {
        if (IsHost) yield return StartHost();
        else        yield return JoinAndMove();
    }
}

PlayerIndex, PlayerCount and IsHost are set per instance before the scenario starts, and each side writes its own pass or fail result. The agent reads those results, fixes what broke, and re-runs the match. With no build in the loop, that cycle is short enough to iterate on.

The limits of an editor client

They are editor instances, so they behave like the editor: Mono scripting backend, editor-time asset pipeline, editor performance characteristics. This is the right tool for finding logic and netcode bugs early. It does not replace testing a real IL2CPP build on target hardware before you ship.