In coherence, it is possible to specify how a Prefab is instantiated at runtime using the Instantiate via option on the CoherenceSync
.
We support three default implementations, or you can create your own. The three default implementations are Default, Pooling or DestroyCoherenceSync.
This instantiator will create a new instance of your prefab, and when the related network entity is destroyed, this prefab instance will also be destroyed.
This instantiator supports object pooling, instead of always creating and destroying instances, the pool instantiator will attempt to reuse existing instances. It has two options:
Max Size: maximum size of the pool for this prefab, instances that exceed the limit of the pool will be destroyed when returned.
Initial Size: coherence will create this amount of instances on app startup.
This instantiator will create a new instance for your prefab, but instead of completely destroying the object when the related network entity is destroyed, it will destroy or disable the CoherenceSync component instead.
You can implement the INetworkObjectInstantiator interface to create your custom implementations that will be used by coherence when we need to instantiate a pefab in the scene.
Custom implementations can be Serializable and have your own custom serialized data.
Implementations of this interface will be automatically selectable via the Instantiate via option in the CoherenceSync
for the object, or on the corresponding CoherenceSyncObject
asset.
In coherence, it's possible to specify how the Prefab for a network entity will be loaded into memory at runtime using the Load via option on the CoherenceSync
.
We support three default implementations, or you can create your own. The three default implementations are Resources, Direct Reference or Addressables, these three will be automatically managed by coherence and you won't have to worry much about them.
Resources loader will be used if your prefab is inside a Resources folder, if you wish to use any other type of loading method, you will be prompted to move the prefab outside of the Resources folder.
This loader will be used if your prefab is outside of a Resources folder, and the prefab is not marked as Addressable. This means that we will need to hard reference your prefab in the CoherenceSyncConfig, which means it will always be loaded into memory from the moment you start your game.
This option is only available if you have the Addressables Package installed.
This loader will be used if your prefab is marked as an Addressable asset, and it will be soft referenced using Addressables AssetReference class, meaning it's not loaded in memory at the beginning of the game but it gets loaded on demand, when needed.
When you choose this method, you don't have to implement Addressables code: coherence takes care of doing the loading for you, transparently.
You can implement the INetworkObjectProvider
interface to create your custom implementations that will be used by coherence when we need to load the prefab into memory.
Custom implementations can be Serializable and have your own custom serialized data.
Implementations of this interface will be automatically selectable via the Load via option in the CoherenceSync
for the object, or on the corresponding CoherenceSyncObject
asset.
In this section we cover how coherence handles loading CoherenceSync
Prefabs into memory and instantiating them when a new remote entity appears on the network.
Whenever you start synchronizing one of your Prefabs, either by adding the CoherenceSync
component manually or clicking the Sync with coherence toggle in the Prefab inspector, coherence will create a CoherenceSyncConfig
ScriptableObject to track the existence of this entity, and add it to a registry.
This object holds information on how a certain type of network entity is loaded and instantiated. As a user, the two main changeable options here are Load via, and Instantiate via.
There is a 1:1 correspondence between a networked Prefab and its CoherenceSyncConfig
object, so you can also edit the related CoherenceSyncConfig
in the inspector of any CoherenceSync
component:
The CoherenceSyncConfig
object allows us to do the following:
Hard reference the prefab in Editor, this means that whenever we have to do postprocessing in synced prefabs, we don't have to do a lookup or load them from Resources.
Serialize the method of loading and instantiating this prefab in runtime.
Soft reference the prefab in Runtime with a GUID, this means we can access the loading and instantiating implementations without having to load the prefab itself into memory.
Every time a CoherenceSyncConfig
object is created, it gets added to a registry that is another ScriptableObject of type CoherenceSyncConfigRegistry
.
You can inspect all of the CoherenceSyncConfig
assets in one place in the CoherenceSync Objects window, found under the coherence > CoherenceSync Objects menu item:
This is a great way to see the configuration of different entities next to each other, and to do mass edits.
Assets/coherence/CoherenceSyncConfigs
is the default location of all CoherenceSyncConfig
objects.
You can also manually inspect the CoherenceSyncConfigRegistry
by selecting it from Assets/coherence
folder
Instead of hard referencing Prefabs in your scripts to instantiate them using Unity's own Instantiate()
, you can reference a CoherenceSyncConfig
and instantiate your local Prefab instances through our API.
This will utilize the internal INetworkObjectProvider
and INetworkObjectInstantiator
interfaces to load and instantiate the Prefab in a given networked scene (a scene with a CoherenceBridge component in it).
For instance:
You can also hard reference the Prefab in your script, and use our extensions to instantiate the Prefab easily using the internal INetworkObjectInstantiator
interface implementation.
The main difference is that the previous approach doesn't need a Prefab hard reference, and you won't have to change the code if the way that the Prefab is loaded into memory changes (for example, if you go from Resources to load it via Addressables).