Scripting: Client vs Simulator
When scripting Simulators, we need mechanisms to tell them apart.
public class SimualatorClass : MonoBehaviour
public void Awake()
// I'm a simulator!
There are two ways you can tell coherence if the game build should behave as a Simulator:
public class ConnectAsSimulator : MonoBehaviour
var endpoint = new EndpointData
region = EndpointData.LocalRegion,
host = "127.0.0.1",
port = 32001,
schemaId = RuntimeSettings.instance.SchemaID,
var monoBridge = FindObjectOfType<CoherenceMonoBridge>();
// simulator-specific code
Whenever the project compiles with the
COHERENCE_SIMULATORpreprocessor define, coherence understands that the game will act as a Simulator.
The custom build pipeline lets us define preprocessor defines like COHERENCE_SIMULATOR
Launching the game with
--coherence-simulation-serverwill let coherence know that the loaded instance must act as a Simulator.
You can supply additional parameters to a Simulator that define its area of responsibility, e.g. a sector/quadrant to simulate Entities in and take authority over Entities wandering into it.
You can also build a special Simulator for AI, physics, etc.
You can define who simulates the object in the CoherenceSync inspector.
The sample UI provided includes auto-reconnect behaviour out of the box for Room- and World-based simulators. The root GameObject has AutoReconnect components attached to it.
AutoReconnect in the sample UI
Multi-Room Simulators have their own per-scene reconnect logic. The AutoReconnect components should not be enabled when working with Multi-Room Simulators.
If the Simulator is invoked with the
--coherence-play-regionparameter, AutoReconnect will try to reconnect to the Server located in that region.