Comment on page
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 Bridge = FindObjectOfType<CoherenceBridge>();
// 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.
coherence includes an auto-connect MonoBehaviour out of the box for Room- and World-based Simulators. The Component its called AutoSimulatorConnection.
When you add the Component, it will parse the connection data passed with Command-line arguments to connect to the given Replication Server automatically. This will also work for Simulators you upload to the coherence Cloud.
Multi-Room Simulators have their own per-scene reconnect logic. The AutoSimulatorConnection components should not be enabled when working with Multi-Room Simulators.
If the Simulator is invoked with the
--coherence-play-regionparameter, AutoSimulatorConnection will try to reconnect to the Server located in that region.