Uniqueness is about naming entities and guaranteeing that a named entity can only exist once. This name is referred to as Unique ID.
To start using uniqueness, set CoherenceSync's Uniqueness setting to No Duplicates:
The ID or name of the entity. Use any name you might help you recognize it over the network, for example: game manager, boss, spawner, chest 1, ...
When Manual Unique ID is left empty, Prefab Instance Unique ID will be used instead. The latter is assigned automatically (for prefab instances), to tell apart different instances on the scene easily. This is handy when your scene has a handful of the entities [that come from the same Prefab] around.
In coherence, the concepts of Authority, Persistence and Uniqueness often go hand-in-hand. For example, uniqueness can be useful to keep track of persistent objects. Despite this, all three can also function on their own.
Replacement occurs when there's an attempt to create a named entity that already exists. For example, you have player in your scene, and you instantiate another player.
By default, a Replace strategy is applied. This strategy makes sure the actual GameObject is kept, but the underlying linked entity is updated. This way, Unity Object references are not lost.
However, there's scenarios where you might want to trigger an actual Destroy operation when this happens - for such cases, the Destroy strategy can be used.
This document explains how to set up an ever increasing counter that all Clients have access to. This could be used to make sure that everyone can generate unique identifiers, with no chance of ever getting a duplicate.
By being persistent, the counter will also keep its value even if all Clients log off, as long as the Replication Server is running.
First, create a script called Counter.cs and add the following code to it:
This script expects a command sent from a script called NumberRequester, which we will create below.
Next, add this script to a Prefab with CoherenceSync on it, and select the counterand the method NextNumber for syncing in the bindings window. To make the counter behave like we want, mark the Prefab as "Persistent" and give it a unique persistence ID, e.g. "THE_COUNTER". Also change the adoption behaviour to "Auto Adopt":
Finally, make sure that a single instance of this Prefab is placed in the scene.
Now, create a script called NumberRequester.cs. This will be an example MonoBehaviour that requests a unique number by sending the command GetNumber to the Counter Prefab. As a single argument to this command, the NumberRequester will send an entity reference to itself. This makes it possible for the Counter to send back a response command (GotNumber) with the number that was generated. In this simple example we just log the number to the console.
To make this script work, add it to a Prefab that has the CoherenceSync script and mark the GotNumber for syncing in the bindings window.
The CoherenceSync editor interface allows us to define the Lifetime of a networked object. The following options are available:
Session Based. No persistence. The Entity will disappear when the Client or Simulator disconnects.
Persistent. The Entity will remain on the Server until a simulating Client deletes it.
For managing unique persistent objects, see Uniqueness.
A persistent object can be deleted only by the Client or Simulator that has authority over it. For indirect remote deletion, see the section about network commands.
Deleting a persistent object is done the same as with any network object - by destroying its GameObject.
All persistent objects remain in the World for the entire lifetime of the Replication Server and, periodically, the Replication Server records the state of the World and saves it to physical storage. If the Replication Server is restarted, then the saved persistent objects are reloaded when the Replication Server resumes.
Currently, the maximum number of persistent objects supported by the Replication Server is 32 000. This limit will be increased in the near future.
When we connect to a Game World with a Game Client, the traditional approach is that all Entities originating on our Client are session-based. This means that when the Client disconnects, they will disappear from the network World for all players.
A persistent object, however, will remain on the Replication Server even when the Client or Simulator that created or last simulated it, is gone.
This allows us to create a living world where player actions leave lasting effects.
In a virtual world, examples of persistent objects are:
A door anyone can open, close or lock
User-generated or user-configured objects left in the world to be found by others
Game progress objects (e.g. in PvE games)
Voice or video messages left by users
NPC's wandering around the world using an AI logic
Player characters on "auto pilot" that continue affecting the world when the player is offline
And many, many more
A persistent object with no Simulator is called an orphan. Orphans can be configured to be auto-adopted by Clients or Simulators on a FCFS basis.
