CoherenceSync
Last updated
Last updated
CoherenceSync is a component that should be attached to every networked Game Object. It may be your player, an NPC or an inanimate object such as a ball, a projectile or a banana. Anything that needs to be synchronized over the network and turned into an Entity. You can select which of the attached components you would like to sync across the network as well as individual public properties.
All Networked Entities need to be placed in the Resources folder
Any scripts attached to the component with CoherenceSync that have public variables will be shown here and can be synced across the network. Enable the script + the variable to sync, it's that easy. Those variables with a lightning bolt next to them signify a public method that can be activated via commands.
Ownership Transfer
When you create a networked game object, you automatically become the owner of that game object. That means only you are allowed to update or destroy it. But sometimes it is necessary to pass ownership from one player to another. For example, you could snatch the football in a soccer game or throw a mind control spell in a strategy game. In this case, you will need to transfer ownership from one client to another.
Entity Lifetime
When a player disconnects, all the game objects created by that player are usually destroyed. If you want any game objects to stay in the game world after the owner disconnects, you need to set Entity lifetime type of that game object to Persistent.
Session Based - Will be removed when the client disconnects
Persistence - Entities with this option will persist as long as the server is running. Auto Generate Persistance UUID should be checked so that a unique identification string will be used to regenerate the object when you reconnect to the server. When the entity is spawned with this checked it will generate its own UUID.
Uniqueness
Allow Duplicates - no restrictions on which objects can be instantiated over the network.
No Duplicates - ensure objects are no duplicated by marking them with a UUID. You can provide your own, left the field blank (a GUID will be assigned at runtime), or use the CoherenceUUID component helper to generate GUIDs for you at editor time.
Entity Simulation Type
Client Side - Simulates everything on the local client and passes the information to the Replication Server to distribute that information to the other clients.
Other forms of simulation (Server; Server with Client Input) coming soon.
Authority Transfer Style
Not Transferable - The default value is Not Transferable because most often objects are not meant to be transferred.
Stealing - Allows the game object to be transferred to another client.
Request - This option is intended for conditional transfers, which is not yet supported.
Orphaned Entities
By making the game object persistent, you ensure that it remains in the game world even after its owner disconnects. But once the game object has lost its owner, it will remain frozen in place because no client is allowed to update or delete it. This is called an orphaned game object.
In order to make the orphaned game object interactive again, another client needs to take ownership of it. To do this, enable Auto-adopt orphan.
Once you have set the transfer style to stealing, any client can request ownership by calling the RequestAuthority() method on the CoherenceSync component of that game object:
someGameObject.GetComponent<CoherenceSync>().RequestAuthority();
A request will be sent to the game object's current owner. The current owner will then accept the request and complete the transfer.
You are now the new owner of the game object. This means the isSimulated flag has been set to true, indicating that you are now in full control of the game object. The previous owner is no longer allowed to update or destroy it.
Helper scripts with a custom implementation of Authority transfer can be found here.
Events for handling user connection and disconnection. Manual Destory is useful for session based objects that you want to keep "semi persistent" which would be removed when all the clients disconnect.
When CoherenceSync variables/components sent over the network, by default, reflection is used to sync all the data at runtime. Whilst this is really useful for prototyping quickly and getting things working, it can be quite slow and unperformant. A way to combat this is to bake the CoherenceSync component, generating a compatible schema and generating code for it.
The schema is a file that defines which data types in your project are synced over the network. It is the source from which coherence SDK generates C# struct types (and helper functions) that are used by the rest of your game. The coherence Replication Server also reads the Schema file so that it knows about those types and communicates them with all of its clients efficiently.
The schema must be baked in the coherence Settings window before the check box to bake this prefab can be clicked.
When the CoherenceSync component is baked, it generates a new file in the baked folder called CoherenceSync<NameOfThePrefab>. This component will be instantiated at runtime, and will take care of networked serialization and deserialization, instead of the built-in reflection-based one.
Refer to the commands section.
