Connecting simulations - SyncroMesh Documentation

Multiplayer uses the same interconnected board model as distributed simulation. Authoritative boards publish entity state; client boards subscribe and build a local view. Your game defines commands and rules on top of those mechanisms.

Establish authority #

Decide which board owns each entity and where commands are validated. Client-only boards must not decide authoritative outcomes. Configure board areas when local simulation coordinates need translation to a common world frame. An area is not an automatic load balancer.

Connect two boards #

// In the authoritative board bootstrap:
await Network.listen(19000, {maxConnections: 32});

// In a separate client board bootstrap:
await Network.setClientOnly(true);
const connectionId = await Network.connect('127.0.0.1', 19000, {clientOnly: true});

Import Network from Syncromesh/Network. These snippets show the roles, not a complete game. Connection establishment is asynchronous: return from bootstrap, then check connection state and set focus when the connection is ready. Configure authentication before admitting clients when your application needs it.

Choose what peers receive #

Set a connection focus AABB with Network.setFocus. Ordinary spatial replication requires a focus region; connecting alone does not subscribe to the entire world. The listening side streams replication to incoming subscribers; a connecting client does not send authoritative deltas upstream. The default broadcast cadence is 20 Hz and can be changed with setReplicationRate. Per-entity masks select fields in recurring deltas; full snapshots establish complete baselines.

Build the local presentation #

Subscribe to entity lifecycle events and create local presentation appropriate to each replicated entity. Client presentation state is distinct from authoritative game rules. Attach the client board to a window to render it. Use reliable network messages for game-specific commands and events.

Transfer entity ownership #

When your game's region rules require a transfer, coordinate the explicit offer/intent/award/ack handshake through the network API. Handle lifecycle and ownership events so logic follows the current owner. Merely setting a board area or moving an entity past its boundary does not implement your application's transfer policy.

Evaluate with a representative workload #

Start with an authoritative board and a client board on one machine, then exercise separate processes and network conditions.
Test focus changes, entity creation and deletion, reconnects, and ownership handoff.
Measure scripting time, physics cost, and network traffic with the entity density and update rates your game needs.
Decide application behaviour for connection loss and rejected commands.

See Network reference for the concrete calls, event payloads, and authentication controls.

<- Boards and execution Changelog ->