> For the complete documentation index, see [llms.txt](https://studio-docs.sandbox.game/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://studio-docs.sandbox.game/multiplayer/test-multiplayer-locally.md).

# Test multiplayer locally

Play mode can run a dedicated server and more than one client on your machine. Use it to check movement, scoring, and spawning before you upload. It does not place anyone in platform matchmaking. That test is on [Add matchmaking](/multiplayer/add-matchmaking.md).

The **Multiplayer** checkbox next to Play only affects this local test. The cloud game has its own switch, on [Publish a multiplayer game](/multiplayer/publish-a-multiplayer-game.md).

## Step 1: Start more than one client

In the title bar, next to Play, open the network menu (the network icon).

1. Check **Multiplayer**.
2. Set **Clients** from 1 to 4.
3. Choose **Transport**: WebSocket or WebTransport.
4. Press Play.

The editor starts a dedicated server for the project. The editor viewport is the first client. Each extra client opens its own play window. That count is **Clients** minus one. Arrange the windows so you can watch replication, join, and scoring together.

{% hint style="info" %}
*NOTE: One Play mode window only shows your own character. A second client is what shows that the session is shared.*
{% endhint %}

## Step 2: Check the shared session

With two clients connected, confirm each of these:

1. The local Pawn responds immediately, and a remote Pawn appears on the other windows after join.
2. Each player controls a different character, and each player sees the other character move.
3. A `@ENGINE.ServerRPC()` that changes a replicated property, such as the score, updates every client, including a window that joined late.
4. A client that writes a replicated property locally does not change the other windows.
5. A projectile or other object spawned during play shows up on both clients, and disappears on both when it is removed.
6. Session chat, opened with Enter, reaches only the players on this server. Escape closes chat and releases the mouse. Click the game to capture the pointer again.

A game that plays correctly with one window has not passed this list.

`disconnectFromServer` is an intentional leave. The world returns to standalone. An unexpected drop reconnects with backoff, up to five attempts.

In `beginPlay` or later, `ENGINE.NetRuntime.getType()` prints `DedicatedServer` on the server process and `Client` in the play windows.

## Step 3: Add delay and packet loss

Open the network menu again. **Server Lag Simulation** and **Clients Lag Simulation** are separate switches. Each one has three bars:

| Bar             | What it does                                   |
| --------------- | ---------------------------------------------- |
| **Latency**     | One-way delay, from 0 to 500 ms                |
| **Jitter**      | Variation in that delay, from 0 to 100 ms      |
| **Packet Loss** | How often a message is dropped, from 0 to 100% |

Reliable messages are delayed and kept. Unreliable messages, including replication updates and unreliable RPCs, can also be dropped.

Turn on **Server Lag Simulation**, set a small latency, and play again with two clients. Movement should still correct, and both clients should still show the same score. Turn lag on before you trust prediction, interpolation, and hit traces.

Set the bars back to 0 before you treat a failure as a gameplay bug.

## What You've Done

Two clients on your machine share a server, see each other, and still agree on the score when the connection is imperfect. Uploading that build is a separate test from this Play mode session.

*Checked against `@gnsx/genesys.js` 19.0.0-beta.456 on 16 October 2026.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://studio-docs.sandbox.game/multiplayer/test-multiplayer-locally.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.