Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
coherence is a network engine, platform and a series of tools to help anyone create a multiplayer game.
Fast network engine with cloud scaling, state replication, persistence and auto load balancing.
Easy to develop, iterate and operate connected games and experiences.
SDK allows developers to make multiplayer games using Windows, Linux or Mac, targeting desktop, console, mobile, VR or the web.
Game engine plugins and visual tools will help even non-coders create and quickly iterate on a connected game idea.
Scalable from small games to large virtual worlds running on hundreds of servers.
Game-service features like user account, key-value stores and matchmaking.
At the core of coherence lies a fast network engine based on bitstreams and a data-oriented architecture, with numerous optimization techniques like delta compression, quantization and network LOD-ing ("Level of Detail") to minimize bandwidth and maximize performance.
The network engine supports multiple authority models:
Client authority
Server authority
Server authority with client prediction
Authority handover (request, steal)
Distributed authority (multiple simulators with seamless transition)
Deterministic client prediction with rollback ("GGPO"): coming in a future release
coherence supports persistence out of the box.
This means that the state of the world is preserved no matter if clients or simulators are connected to it or not. This way, you can create shared worlds where visitors have a lasting impact.
The coherence SDK only supports Unity at the moment. Unreal Engine support is planned. For more specific details and announcements, please check the Unreal Engine Support page. For custom engine integration, please contact our developer relations team.
coherence is currently in private preview. Some stability and performance issues may still be present and being ironed out. Additionally, more features are planned for the public release later this year.
Custom UDP transport layer using bit streams with reliability
Smooth state replication
Server-side, client-side, distributed authority
Connected entity support
Fast authority transfer
Remote messaging (RPC)
Persistence
Multiple examples and showcases
Support for Windows, Mac, Linux, Android, iOS, etc.
Unity SDK with intuitive no-code layer
Per-field adjustable interpolation and extrapolation
Input queues
ECS/DOTS support
Easy deployment into the cloud
SDK source included, no 3rd-party libraries
Per-field compression and quantization
Per-field sampling frequency adjustable at runtime
Unlimited per-field levels of detail
Areas of interest
Developer portal with server and service configurator
Multiple regions (US East, EU Central)
Player accounts
Key-value store
Matchmaking
Ability to deploy one replication server and one simulation server per environment
Prometheus and Grafana integration
Removed reliance on Entities package
Performance improvements
WebGL / WebAssembly support
WebRTC support
Accurate SimulationFrame tracking
Better support for in-scene networked entities (decoupling uniqueness and persistence)
Support for lean pure C# clients and simulators without Unity
Faster input queues
Network Profiler
Additional regions
Support for multiple simulators and replicators in a single project
Dashboard with usage statistics
Peer-to-peer (without replication server) with NAT punch-through
TCP fallback support
WebSockets support
MTU detection
Packet replay
Ability to deploy multiple simulation servers per environment
Player analytics
Additional packet compression
Developer portal graphs and analytics
Simulator authentication
JavaScript SDK
Unreal Engine SDK
Multiple replication servers per game world
Customer-specific serialization
User-space load-balancing (SDK framework)
Game world map with admin interface
Anti-cheat functionality
Advanced transaction logs (audit trail)
Schema versioning (hot updates)
coherence only supports Unity at the moment. Unreal Engine support is planned. For more specific details and announcements, please check the Unreal Engine Support page. For custom engine integration, please contact our developer relations team.
First, open Project Settings
.
Under Package Manager
, add a new Scoped Registry with the following fields:
Name: coherence
URL: https://registry.npmjs.org
Scope(s): io.coherence.sdk
Enable Preview Packages: checked
Show Dependencies: checked
Click Apply
.
Now open the Package Manager
.
Click Packages
and My Registries
.
Under coherence
, click Install
.
If you want to install coherence manually, go to the folder of your project and open the file /Packages/manifest.json
.
Copy paste the lines surrounded by comments that look like this:/* comment */
.
The Unity docs have information about scoped package registries.
When you install the coherence Unity Package, all the services for the SDK are installed in the background as well.
You will then see this package in the Package Manager under "My Registries".
The coherence SDK has some dependencies on other Unity packages you can see in the image above. If you're already using these in your project, you might have to adjust their version number (Unity will tell you about this).
When you successfully install the coherence SDK you'll get this quickstart winodow pop-up and you'll be good to go.
A lean and performant server that keeps the state of the world and replicates it efficiently between various simulators and game clients. The Replicator usually runs in the coherence Cloud, but developers can start it locally from the command line or the Unity Editor.
A build of the game. To connect to coherence, it will use the coherence SDK.
A version of the game client without the graphics ("headless client") optimized and configured to perform server-side simulation of the game world. When we say something is simulated on the server, we mean it is simulated on one or several simulators.
A text file defining the structure of the world from the network's point of view. The schema is shared between the replicators, simulators and game clients. The world is generally divided in components and archetypes.
Code Generation
The process of generating code specific to the game engine that takes care of network synchronization and other network-specific code. This is done using a CLI tool called Protocol Code Generator that takes the schema file and generates code for various engines (e.g. C# for Unity).
The process of making sure the state of the world is eventually the same on the replicator, simulators and game clients, depending on their areas of interest.
coherence works by sharing game world data via a Replication Server in the cloud and passing it to the connected clients.
The clients and simulators can define areas of interest (LiveQueries), levels of detail, varying simulation and replication frequencies and other optimization techniques to control how much bandwidth and CPU power is used in different situations.
The game world can be run using multiple simulators that split up simulation functions or areas of the world accordingly.
Fast authority transfer, remote commands, and events allow different authority models, including client authority, server authority, distributed authority and combinations like client prediction with input queues.
The platform handles scaling, synchronization, persistence and load balancing automatically.
Peer-to-peer support (without a replicator) is planned in a future release. Please see the Peer-to-peer page for updates.
Games are better when we play together.
coherence is a network engine, platform and a series of tools to help anyone create a multiplayer game. Our mission is to give any game developer, regardless of how technical they are, the power to make a connected game.
The Network Playground is a collection of scenes showing you how to use various features of the coherence Unity SDK. It shows you how to synchronize transforms, physics, persistence, animations, AI navigation and send network commands and events.
You can follow our step-by-step guide to learn how to install coherence in Unity, set up your scene, prefabs, interactions, as well as deploy your project to be shared with your friends.
Join our community Discord for community chatter and support.
Join our official Developer
Contact us at
It's quick and easy to set up a networked scene from scratch using the coherence SDK. This example will show you the basic steps to sync up some moving characters.
Add these components to your scene to prepare it for network synchronization.
coherence -> Scene Setup -> Create MonoBridge
This object takes care of connected GameObject
lifetimes and allows us to develop using traditional MonoBehaviour
scripts.
coherence -> Scene Setup -> Create LiveQuery
coherence -> Scene Setup -> Add Sample UI
Creates a Canvas
(and Event System
if not already present in the scene) with a sample UI that helps you connect to a local or remote replication server. You can create your own connection dialog, this one is just a quick way to get started.
Out of the box, coherence will use C# Reflection to sync all the data at runtime. This is a great way to get started but it is very costly performance-wise.
For optimal runtime performance, we need to create a schema and perform code generation specific to our project.
coherence offers an automatic way of doing that called baking.
Click on coherence -> Bake Schemas
.
This will go through all CoherenceSync
components in the project and generate a schema file based on the selected variables, commands and other settings. It will also take into account any CoherenceArchetype
components.
For every prefab with a CoherenceSync
object, the baking process will generate a bespoke C# file in the coherence/baked
folder in the project.
Adding that file to the prefab will make that prefab use bespoke generated code instead of C# reflection.
Once the Schema has been baked, you will be able to activate the baked script in the Configuration section of the CoherenceSync component.
The name of the baked script will be CoherenceSync[prefabName]
.
Creates a which queries the area around the local player to get required information from the replication server. You can surround your entire scene in one query or can attach it to an object such as the player or a camera.
Learn more about this in the section.
Now we can build the project and try out network replication locally.
This example will show you how to launch a local replication server and connect multiple instances.
You can run a local replication server from the coherence menu by clicking:
coherence -> Server -> Run Local Server
.
This will open a new terminal window with the replication server.
Now it's time to make a standalone build an test network replication.
#protip: Go to Project Settings, Player and change the Fullscreen Mode to Windowed and enable Resizable Window. This will make it much easier to observe standalone builds side-by-side when testing networking.
Open the Build Settings window (File -> Build Settings
). Click on Add Open Scenes to add the current scene to the build. Click Build and Run.
Select a folder (e.g. builds) and click OK.
When the build is done, start another instance of the executable (or run the project in the Game Window in Unity).
Click Connect on both clients. Now try focusing one and using WSAD keys. You will see the box move on the other side as well.
Congratulations, you've made your first coherence replicated experience. But this is only the beginning. Keep reading to take advantage more advanced coherence features.
If you want to connect to the local replication server from another local device (such as another PC, Mac, Mobile or VR device), you can find your IPv4 address and use that as your server address in the Connect dialog. These devices need to be connected to the same network.
You can find your IPv4 address by going to your command line tool and type ipconfig
. Remember to include the port number, for example 192.168.1.185:32001.
Make sure your Firewall allows remote connections to connect to the replication server from other devices on your network.
In this section, we will learn how to prepare a prefab for network replication.
Add an asset and create a prefab of it. Make sure the prefab is in a Resources
folder in your Unity project.
Here is an example:
GameObject -> 3D Object -> Cube
Create a Resources
folder in your Project. Drag the Cube into the Resources folder to turn it into a prefab.
The CoherenceSync
component will help you prepare an object for network synchronization during design time. It also exposes an API that allows us to manipulate the object during runtime.
CoherenceSync
will query all public variables and methods on any of the attached components, for example Unity components such as Transform
, Animator
, etc.. This will include any custom scripts such as PlayerInput
and even scripts that came with Asset Store packages you may have downloaded.
Select which variables you would like to sync across the network. Initially, this will probably be the Transform
settings; position, rotation, scale.
Under Synchronization
, click Select fields and methods
.
In the Bindings dialog, select position, rotation and scale.
Close the Bindings dialog.
This simple input script will use WASD or the Arrow keys to move the prefab around the scene.
Click on Assets -> Create -> C# Script
.
Name it Move.cs
. Copy-paste the following content into the file.
Wait for Unity to compile the file, then add it onto the prefab.
We have added a Move
script to the prefab. This means that if we just run the scene, we will be able to use the keyboard to move the object around.
But what happens on another client where this object is not authoritative, but rather replicated? We will want the position to be replicated over the network, without the keyboard input interfering with it.
Open the Events
section in CoherenceSync
. Add a new On Network Instantiation
handler by clicking on the plus sign next to it.
Pull the Cube prefab into the Runtime Only / None (Object) field.
Now click the dropdown No Function and select Move -> bool enabled
.
Leave the Boolean field unchecked.
From the CoherenceSync
component you can configure settings for Lifetime (Session-based
or Persistent
, Authority transfer (Request
or Steal
), Authority model (Client Side
or Server Side with Client Input
) and Adoption settings for when local persistent entities are orphaned.
On Networked Instantiation
(when the GameObject is instantiated)
On Networked Destruction
(when the GameObject is destroyed)
On Before Authority Transfer
(before authority over the GameObject is transferred from one client/simulator to another)
On After Authority Transfer
(after the GameObject's Authority has been transferred to another client/simulator).
Some extra scripts that are part of the Network Playground that may be useful.
coherence currently supports Unity. For custom engine integration,. For updates regarding Unreal Engine support, please check the page.
Unity 2020.1.9f1 or later.
A Windows, Linux or Mac system.
The current version of coherence uses the Unity Entities package. Unity that they will not support this package in Unity 2021 for a while. This means that the current recommended Unity version for using coherence is Unity 2020 LTS. This is only temporary as we have been working on removing the reliance on Entities internally.
Networked entities can be simulated either on a game client ("client authority") or a simulation server ("server authority).
Client authority is the easiest to set up initially, but it has some drawbacks:
Higher latency. Because both clients have a non-zero ping to the replication server, the minimum latency for data replication, commands and events is the combined ping (client 1 to replications server and replication server to client 2).
Higher exposure to cheating. Because we trust game clients to simulate their own entities, there is a risk that one such client is tampered with and sends out unrealistic data.
In many cases, especially when not working on a competitive PvP game, these are not really issues and are a perfectly fine choice for the game developer.
Client authority does have a few advantages:
Easier to set up. No client vs. server logic separation in the code, no building and uploading of simulation servers, everything just works out of the box.
Cheaper. Depending on how optimized the simulator code is, running a simulator in the cloud will in most cases incur more costs than just running a replication server (which is comparatively very lean).
Having one or several simulators taking care of the important world simulation tasks (like AI, player character state, score, health, etc.) is always a good idea for competitive PvP games.
Running a simulator in the cloud next to the replicator (the ping between them being negligible) will also result in lower latency.
The player character can also be simulated on the server, with the client locally predicting its state based on inputs. You can read more about how to achieve that in the section .
Peer-to-peer support (without a replicator) is planned in a future release. Please see the for updates.
Now that we have tested our project locally, it's time to upload it to the cloud and share it with our friends and colleagues. To be able to do that, we need to create a free account with coherence.
Create an account or log into an existing one.
Create an organization.
Under the organization, create a new project.
Copy the token to your clipboard.
Open Unity and navigate to the Project Settings. Open the coherence tab.
Paste the token into the Portal Token section.
Once you have pasted the portal token successfully, you need to fetch the runtime token as well.
Now we can finally deploy our schema and replication server into the cloud.
In the Project Settings tab for coherence, click on Upload Schemas.
The status should change from "Unknown" to "In Sync".
Your project schema is now deployed with the correct version of the replication server already running in the cloud.
You can now build the project again and send the build to your friends for testing.
You will be able to play over the internet without worrying about firewalls and local network connections.
Make sure everybody selects the remote server before clicking Connect.
It's important that your prefab is in a Resources folder so that Unity can load it at runtime. This is a Unity requirement, more info .
You can find more information in the . There are also some Events that are triggered at different times.
Even if an entity is not currently being simulated locally, we can still affect its state by sending a , or even .
In your web browser, navigate to .
Open the project dashboard and find the .
You can fetch the by clicking on the down-arrow button on the right side of the input field.
If the status does not say In Sync, or if you encounter any other issues with the server interface, please refer to the section.
When you run the project now, you will notice that the Connect Dialog now contains additional address(-es). The Connect Dialog uses the to fetch all the addresses available for your project. This depends on the project configuration (e.g. the regions that you have selected for your project).
We are working on a WebGL / Webassembly option that will automatically upload the browser-playable build to your own personal webpage that you can share with your friends. For more information about our roadmap, please contact our .
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.
All persistent objects remain in the world for the entire lifetime of the replication server. But what happens when the replication server is restarted or goes offline?
Persistence Client is a special utility that runs alongside the replication server and records the state of the world and saves it to physical storage. If the replication server goes offline, the Persistence Client will backup the entire state of the world.
The Persistence Client will be available as part of the coherence online services in a future release. Please contact our developer relations team for more information.
Extrapolation or "dead reckoning" uses historical data to predict the future state of a component. The actual network data that arrives later can be used to interpolate or snap the predicted values to the correct ones.
We will be adding an example of extrapolation in a subsequent release.
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 counter
and 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.
Input queues enable a simulator to take control of the simulation of another client's objects based on the client's inputs.
In situations where you want a centralized simulation of all inputs. Many game genres use input queues and centralized simulation to guarantee the fairness of actions or the stability of physics simulations.
In situations where clients have low processing power. If the clients don't have sufficient processing power to simulate the world it makes sense to use input queue and just display the replicated results on the clients.
In situations where determinism is important. RTS and fighting games will use input queues and rollback to process input events in a shared (not centralized), and deterministic, way so that all clients simulate the same conditions and produce the same results.
coherence currently only supports using input queues in a centralized way where a single simulator is setup to process all inputs and replicate the results to all clients.
Setting up an object to simulate via input queues using CoherenceSync is done in three steps:
The Simulation Type of the CoherenceSync component is set to Simulation Server With Client Input
Setting the simulation type to this mode instructs the client to automatically give authority over this object to the simulator in charge of simulating all inputs on all objects.
Each simulated CoherenceSync component is able to define their own, unique, set of inputs for simulating that object. An input can be one of:
Button. A button input is tracked with just a binary on/off state.
Button Range. A button range input is tracked with a float value from 0 - 1.
Axis. An axis input is tracked as two floats from 0 - 1 in both the X and Y axis.
To declare the inputs used by the CoherenceSync component, the CoherenceInput component is added to the object. The input is named and the fields are defined.
In this example, the input block is named "Player Movement" and the inputs are WASD and "mouse" for the XY mouse position.
In order for the inputs to be simulated on CoherenceSync objects, they must be optimized through baking.
If the CoherenceInput fields or name is changed, then the CoherenceSync object must be re-baked to reflect the new fields / values.
When a simulator is running it will find objects that are set up using CoherenceInput components and will automatically assume authority and perform simulations. In the case of a setup with multiple simulators, it is important that only one is designated as the processor of these objects. So, for all other simulators the InputServerSystem must be disabled.
Both the client and simulator need to access the inputs of the CoherenceInput of the replicated object. The client uses the Set* methods and the simulator uses the Get* methods to access the state of the inputs of the object. In all of these methods, the name parameter is the same as the Name field in the CoherenceInput component.
public void SetButtonState(string name, bool value)
public void SetButtonRangeState(string name, float value)
public void SetAxisState(string name, Vector2 value)
Simulator-Side Get* Methods
public bool GetButtonState(string name)
public float GetButtonRangeState(string name)
public Vector2 GetAxisState(string name)
For example, the mouse click position can be passed from the client to the simulator via the "mouse" field in the setup example.
The simulator can access the state of the input to perform simulations on the object which are then reflected back to the client as any replicated object is.
Generally, using server-side simulation with simulators makes the time from the client providing input to the time the object is updated with that input significantly longer than just client-side simulation because of the time required for the input to be sent to the simulator, processed, and then the updates to the object returned across the network. This can cause visual lag. Using input queues allows the client to perform prediction of the simulation to provide a smooth playing experience.
If the client simulates the inputs on the object as well as applying them to the CoherenceInput component and then blends the authoritative results from the simulator with the locally simulated results, then smoother and more responsive simulation is achieved.
Rollback is not currently available but is in the roadmap. Each client will be aware of the current global simulation frame and so the inputs can be applied by each client at the same frame in time and so client-side prediction can be even more accurate.
Commands are network messages sent from one entity to another entity in the networked world. Commands bind to public methods accessible on the GameObject that CoherenceSync sits on.
In the design phase, you can expose public methods the same way you select fields for synchronization: by using the Select Bindings interface on your CoherenceSync object.
Selected public methods will be exposed as network commands in the baking process.
The resulting schema section will look something like this:
To send a command, we call the SendCommand
method on the target CoherenceSync object. We must supply as many parameters as are defined in the target method and the schema.
Sometimes you want to inform not only the entity that has authority, but all the networked instances across all clients. To do that, use the alternative method overload and set it's boolean value to true:
This is useful when you want every client that networks that entity to execute the same logic. Similar to how RPCs work on other networking solutions.
We don't have to do anything special to receive the command. The system will simply call the corresponding method on the target network entity.
If the target is a locally simulated entity, SendCommand
will recognize that and not send a network command, but instead simply call the method directly.
Sometimes you want to inform a bunch of different entities about a change. For example, a explosion impact on a few players. To do so, we have to go through the instances we want to notify, and send commands to each of them.
In this example, a command will get sent to every network entity known to this client. To make it only affect entities within a certain criteria, you need to filter to which CoherenceSync you send the command to on your own.
When a prefab is using reflection there are some restrictions for what types can be sent in a single command:
4 integers
4 floats
4 bools
4 entity references
1 string
If you ever need to send commands containing any other type (like a vector) or a higher quantity (like two strings) you must mark the prefab to use baked code. This will generate a custom command that can handle all the supported primitive types of the coherence SDK.
If a single command is bigger than the supported packet size, it won't work even with baked code. For a good and performant game experience, always try to keep command sizes low.
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.
Persistent Expire. A persistent object that will be automatically deleted from backing storage after X seconds. These object will continue to exist as long as the replication server is active.
Persistent objects need to be identified so that the system can know how to treat duplicate persistent objects.
Setting the Auto Generate Persistence UUID flag means that each instance of this persistent object prefab is assigned a unique identifier so that each instance is considered unique.
Manually assigning a UUID means that each instance of this persistent object prefab is considered the same object regardless of where on the network it is instantiated. So, for example, if two clients instantiate the same prefab object with the same persistence UUID then only one is considered official and the other is replaced by the replication server.
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.
The state of network entities that are currently not simulated locally (either because they are being simulated on another game client or on a simulator) cannot be affected directly.
Network commands and events can help us affect state indirectly, but for anything more involved, an authority transfer might be necessary.
In the design phase, CoherenceSync objects can be configured to handle authority transfer in different ways:
Request. Authority transfer may be requested, but it may be rejected by the receiving party (i.e. when Approve requests is false).
Steal. Authority will always be given to the requesting party on a FCFS ("first come first serve") basis.
Not transferable. Authority cannot be transferred.
Requesting authority is very straight-forward.
As the transfer is asynchronous, we have to subscribe to one or more Unity Events in CoherenceSync to learn the result.
The request will first go to the replication server and be passed onto the receiving simulator or game client, so it may take a few frames to get a response.
coherence doesn't replicate Animator state, but its parameters. Latency can create scenarios where different clients reproduce different animations. Take this into account when working with Animator Controllers that require precise timings.
Unity Animator's parameters are bindable out of the box, with the exception of triggers.
Triggers can be invoked over the network using commands and events. Here's an example where we inform networked clients that we have played a jump animation:
Since we don't have support for events yet, here we use command broadcasting and entity references to notify other clients about our entity performing a jump.
Now, bind to PlayJumpAnimator
.
Positions and livequeries in the world are compressed, and the compression is defined by maximum scale and bit count. Larger scale at the same bit count means lower precision, and vice-versa.
A default maximum world size of 2400
means that only values from [-2400, 2400]
will be supported for all spatial axes.
If our game scenes are larger than 2400 x 2
(4800
) units across, we can increase this value in the Settings window or in the schema as illustrated below.
Don't forget to extend the LiveQuery scale to match the world position scale.
The way you get information about the world is through LiveQueries. We set criteria for what part of the world we are interested in at each given moment. That way, the replicator won’t send information about everything that is going on in the game world everywhere, at all times.
Instead, we will just get information about what’s within a certain area, kind of like moving a torch around to look in a dark cave.
More complex area of interest types are coming in future versions of coherence.
A LiveQuery is a cube that defined the area of interested in a particular part of the world. It is defined by its position and its radius (half the side of the cube). There can be multiple LiveQueries in a single scene.
A classic approach is to put a LiveQuery on the camera and set the radius to correspond to the far clipping plane or visibility distance.
Moving the GameObject containing the LiveQuery will also notify the replication server that the query for that particular game client has moved.
No matter how fast the internet becomes, conserving bandwidth will always be important. Some game clients might be on poor mobile networks with low upload and download speeds, or have high ping to the replication server and/or other clients, etc.
Additionally, sending more data than is required consumes more memory and unnecessarily burdens the CPU and potentially GPU, which could add to performance issues, and even to quicker battery drainage.
In order to optimize the data we are sending over the network, we can employ various techniques built into the core of coherence.
Delta-compression (automatic). When possible, only send differences in data, not the entire state every frame.
Compression and quantization (automatic and configurable). Various data types can be compressed to consume less bandwidth that they naturally would.
Simulation frequency (configurable). Most entities do not need to be simulated at 60+ frames per second.
Levels of detail (configurable). Entities need to consume less and less bandwidth the farther away they move from the observer.
Area of interest. Only replicate what we can see.
If we don't do any special configuration, entity data is captured at the highest possible frequency and sent to the replication server. This often generates more data than is needed to efficiently replicate the entity's state across the network.
On a simulator, we can limit the framerate globally using Unity's built-in static variable targetFrameRate.
coherence will automatically limit the target framerate of uploaded simulators to 30 frames per second. We plan to enable lifting this restriction in the future. Check back for updates in the next couple of releases.
Components can have their own maximum simulation framerates. These can be defined at runtime by adding a Set[ComponentName]Frequency
component to the entity.
In the future, you will be able to define entity simulation frequencies in the schema as well.
Depending on the settings in our project, data may not always arrive at a smooth 60 frames per second through the network. This is completely okay, but in order to make state changes (e.g. movement, rotation) appear smooth on the client, we use interpolation.
Interpolation is a type of estimation, a method of constructing new data points within the range of a discrete set of known data points.
The way interpolation works in coherence is that we wait for three data points and then start smoothing the subsequent values according to the interpolation parameters defined in the schema (or default parameters, if no overrides are present).
To override interpolation settings, create a new schema asset via Assets/Create/coherence/Schema
and mark it as an active schema in the settings window.
There, add an interpolation definition:
This new interpolation definition MyInterpolation
isn't used yet. We need to tell coherence which component is going to use it. We can associate it to WorldPosition and WorldOrientation:
Although not necessary, we're also defining scale and bit depth in the example above.
There are a few fields you can tune to get the most out of interpolation:
overshootPercentage
How far into dead reckoning we can venture when the time fraction exceeds 100%
overshootRetraction
How fast to pull back to 100% if we overshoot the allowed dead reckoning maximum in seconds
manualLatency
Seconds to stay behind the sample data
autoLatencyFactor
targetInterpolation = autoLatencyFactor * packetDeltaTime
. -1
disables auto latency
elasticity
Seconds to remain behind the current interpolation point, applied to smoothdamp
function or slerp
maxDistance
maximum distance between data points before the component "teleports" to the next value without smoothing.
allowed values: positive real numbers
curveType
the type of interpolation used
allowed values: "CatmullRom"
, "Linear"
Interpolation can be overridden globally, per component and per LOD level. Here is a sample schema that defines a named interpolation style OverrideTranslation
and uses it for all WorldPosition
components.
Here's another example that overrides interpolation for WorldPosition
and WorldOrientation
:
Remember that everytime you change a schema, you need to Bake for the changes to make effect.
We need one last piece to tie everything together. We need a way to let our bindings to use this interpolation override. To do so, we can create a custom binding provider that extends how the transform component is bound. Create a file named CustomTransformBindingProvider.cs
in an Editor folder (e.g. Assets/Editor
), with these contents:
This will use OverrideTranslation
interpolation component for WorldPosition
, and OverrideRotation
for WorldOrientation
. You can use any name for these as long as it matches the names you defined in your schema. If you don't want to override one of these, just comment out the assignment you don't need.
After you compile this script, a popup will appear letting you know that your CoherenceSync assets have been updated to point to these new components you defined.
From here on, any additional change to interpolation you want to make, you can adjust the values in the schema and bake again.
coherence can support large game worlds with many objects. Since the amount of data that can be transmitted over the network is limited, it's very important to only send the most important things.
You already know a very efficient tool for enabling this – the . It ensures that a client is only sent data when an object in its vicinity has been updated.
Often though, there is a possibility for an even more nuanced and optimized approach. It is based on the fact that we might not need to send as much data for an entity that is far away, compared to a close one. A similar technique is often used in 3D-programming to show a simpler model when something is far away, and a more detailed when close-up.
This idea works really well for networking too. For example, when another player is close to you it's important to know exactly what animation it is playing, what it's carrying around, etc. When the same player is far off in the horizon, it might suffice to only know it's position and orientation, since nothing else will be discernible anyways.
To use this technique we must learn about something called archetypes.
An archetype is a component that can be added to any prefab with the CoherenceSync component. It contains a list of the various levels of detail (LODs) that this particular prefab can have.
There must always exist a LOD 0, this is the default level and it always has all components enabled (it can have per-field overrides though, see below.)
There can be any number of subsequent LODs (e.g. LOD 1, LOD 2, etc.) and each one must have a distance threshold higher than the previous one. The coherence SDK will try to use the LOD with the highest number, but that is still within the distance threshold.
Example
An object has three LODs, like this:
LOD 0 (threshold 0)
LOD 1 (threshold 10)
LOD 2 (threshold 20)
If this object is 15 units away, it will use LOD 1.
Confusingly, the highest numbered LOD is usually called the lowest one, since it has the least detail.
One each LOD, there are two options for optimizing data being transferred:
Components can be turned off, meaning you won't receive any updates from it.
It's fields can be configured to use fewer bits, usually leading to less fine-grained information. The idea is that this won't be noticeable at the distance of the LOD.
coherence allows us to define the scale of numeric fields and how many bits we want to allocate to them.
Here are some terms we will be using:
Scale. The minimum/maximum value of the field before it overflows. A scale of 2400
means the number can run from -2400
to 2400
.
Bits. The number of bits (octets) user for the field. When used for vectors, the number defined the number of bits used for each component (x
, y
and z
). A vector3
set to 24 bits
will consume 3 * 24 = 72
bits.
Range. For integer values, we define a minimum and maximum possible value (e.g. Health
can lie between 0
and 100
).
More bits means more precision. Increasing the scale while leaving the bit count the same will lower the precision of the field.
The maximum number of bits used for any field/component is currently 32.
coherence allows us to define these values for specific components and fields. Furthermore, we can define levels of detail so that precision and therefore bandwidth consumption falls with the distance of the object to the point of observation.
Levels of detail are calculated from the distance between the entity and the center of the LiveQuery.
On each LOD you can configure the individual fields of any component to use less data. You can only decrease the fidelity, so a field can't use more data on a lower (more far away) LOD. The Archetype editor interface will help you to follow these rules.
In order to define levels of detail, we have to add a CoherenceArchetype
component to a prefab with CoherenceSync
defined field bindings.
Clicking on Edit LODs opens the Archetype Editor.
We can override the base component settings even without defining further levels of detail.
Clicking on Add new Level Of Detail will add a new LOD. We can now define the distance at which the LOD starts. This is the minimum distance between the entity and the center of the LiveQuery at which the new level of detail becomes active (i.e. the replicator will start sending data as defined here at this distance).
You can also disable components at later LOD levels if they are not needed. In the example above, you can see that the entire Animator component is disabled beyond the distance of 100 units. At 100 units (a.k.a. meters), we usually do not see animation details, so it does not make sense to replicate this data.
The Data Cost Overview shows us that this takes the original 416 bits down to just 81 bits at LOD level 2.
The primitive types that coherence supports can be configured in different ways:
These three types can all be configured in the same way:
By setting the scale, which affects the maximum and minimum value that the data type can take on. For example, a scale of 100 means that a float ranges from -100 to 100.
By setting the precision, which defines the greatest deviation allowed for the data type. For example, a precision of 0.5 means that a float of value 10.0 can be transmitted as anything from 9.5 to 10.5 over the network.
When using these scale setting for vectors, it affects each axis of the vector separately. Imagine shrinking its bounding box, rather than a sphere.
Based on the scale and the desired precision, a bit count will be calculated. The default precision and scale (which happens to be 2400) gives a bit count of 24. This means that for a Vector3 a total of 72 bits will be used, 24 x 3.
Integers can be configured to any span (that fits within a 32-bit int) by setting its minimum and maximum value.
For example, the member variable age
in a game about ancient trolls might use a minimum of 100 and a maximum of 2000. Based on the size of the range (1900 in this case) a bit-count will be calculated for you.
For integers it usually make sense to not decrease the range on lower LODs since it will overflow (and wrap-around) any member on an entity that switches to a lower LOD. Instead, use this setting on LOD 0 to save data for the whole Archetype.
Right now quaternions (used for rotations) do not support field overrides, but this will be fixed in the near future.
All other types (strings, booleans, entity references) have no settings that can be overridden, so your only option for optimizing those are to turn them off completely at lower LODs.
When we bake, information from the CoherenceArchetype
component gets written into our schema. Below, you can see the setup presented earlier reflected in the resulting schema file.
The most unintuitive thing about archetypes and LOD-ing is that it doesn't affect the sending of data. This means that a "fat" object with tons of fields will still tax the network and the replication server if it is constantly updated, even if it uses a very optimized Archetype.
Also, it's important to realize that the exact LOD used on an entity varies for each other client, depending on the position of their query (or the closest one, if several are used.)
Objects with the ConnectedEntity
component on them are treated in a special way by the query system. If the entity they are connected to is present in a query, then they are also included automatically. They are also excluded/removed automatically when the entity they are connected to goes out of the query.
This means that the entity will never show up on its own – it will always have to be part of a query where the connected entity is included.
You need to add the ConnectedEntity
component to entity. The entity will disappear from all queries that don't have the entity this is connected to. The entity has to be converted to its SerializeEntityID
before it can be used in the ConnectedEntity
component. This can be done using the CoherenceMonoBridge.UnityObjectToEntityId
static function.
Please note that the ConnectedEntity component is only available in from code in ECS at the moment. It will be fully integrated with the editor flow in the next release.
Sometimes you want to synchronize entities that are connected to other entities. These relationships can be references between entities, but they can also involve direct parent-child relationship between game objects, or more nuanced use cases.
Here's a guide for what technique to use, depending on the situation:
If you have an entity that needs to keep a nullable reference to another entity, use a normal Entity reference. This includes any existing MonoBehaviour that has GameObject or Transform fields that you want to synchronize over the network.
If knowing about an entity implies that you should also know about some other (connected) entity, you might need to use the ConnectEntity component.
If the entities are placed in a hierarchy, use the techniques for parent-child relationships.
An entity with the ConnectedEntity
component does not cause an entity to attach itself to the connected entity. It is on the game developer to detect entities with ConnectedEntity
components and attach to them to their game specific parents.
A ball that is supposed to be attached to the hand bone of a networked entity. In this case, the ball would show up only once the entity its connected to show up. To attach the ball to the hand, the game developer can write the following code snippet -
A simulation server or simulator is a version of the game client without the graphics ("headless client") optimized and configured to perform server-side simulation of the game world. When we say something is simulated on the server, we mean it is simulated on one or several simulators.
Simulators can also be independent from the game code. A simulator could be a standalone application written in any language, including C#, Go or C++ , for instance. We will post more information about how to achieve this here in the future. For now, if you would like to create a simulator outside of Unity, please contact our developer relations team.
A simulator can have various uses, including:
Server-side simulation of game logic that cannot be tampered with
Offloading processing from game clients
Splitting up a large game world with many entities between them
Here are some examples of things a simulator could be taking care of:
Running all the important game logic
Running NPC AI
Simulating the player character (by receiving only inputs from the clients through input queues)
We can have as many simulators as we like. They will connect to the replication server like any other game client.
Our cloud services only support uploading one simulator to the cloud during our alpha. This will be extended in the near future. Enterprise customers can still run multiple simulators in their own cloud environment.
When scripting simulators, we need mechanisms to tell them apart.
Ask Coherence.SimulatorUtility.IsSimulator
.
There are a few ways you can tell coherence if the instance should behave as a simulator:
Specifying a ConnectionType
when connecting via Coherence.Network.Connect
.
COHERENCE_SIMULATOR
preprocessor define.
--coherence-simulation-server
command-line argument.
Toggling on Simulator in the sample connection dialog.
Connect
and ConnectionType
The Connect
method on Coherence.Network
accepts a ConnectionType
parameter.
Whenever the project compiles with the COHERENCE_SIMULATOR
preprocessor define, coherence understands that the game will act as a simulator.
Launching the game with --coherence-simulation-server
will 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.
Automatic simulator adoption of CoherenceSync objects is work in progress and will be available in one of the future releases of coherence.
The sample UI provided includes auto-reconnect behaviour out of the box for simulators. The root GameObject has an AutoReconnect component attached to it.
If the simulator is invoked with the --coherence-play-region
parameter, AutoReconnect will try to reconnect to the server located in that region.
If you need a different solution, take a look at its implementation use plug your own.
Entity references let you set up references between entities and have those be synchronized, just like other value types (like integers, vectors, etc.)
To use Entity references, simply select any fields of type GameObject
, Transform
, or CoherenceSync
for syncing in the Bindings window:
The synchronization works both when using reflection and in baked sync scripts.
Entity references can also be used as arguments in Commands.
It's important to know about the situations when an entity reference might become null, even though it seems like it should have a value:
A client might not have the referenced entity in its live query. A local reference can only be valid if there's an actual entity instance to reference. If this becomes a problem, consider switching to using the ConnectedEntity component which ensures that another entity becomes part of the query.
The owner of the entity reference might sync the reference to the Replication Server before syncing the referenced entity. This will lead to the Replication Server storing a null reference. If possible, try setting the entity references during gameplay when the referenced entities have already existed for a while.
In any case, it's important to use a defensive coding style when working with entity references. Make sure that your code can handle missing entities and nulls in a graceful way.
coherence allows us to use multiple simulators to split up a large game world with many entities between them. This is called spatial load balancing. Please refer to the section about simulators for more information.
Our cloud services only support uploading one simulator to the cloud during our alpha. This will be extended in the near future. Enterprise customers can still run multiple simulators in their own cloud environment.
This scene will show you how to use coherence to sync GameObject transforms and Physics objects across the network.
In this example, each client will have its own player character to move. Left-clicking on the map will make the entity move to that location. Right-clicking will spawn local physics based objects that all player characters can interact with. Each client will only have control over its local entity.
In the Hierarchy of the Scene you can see three core Prefabs:
Core Scene Setup
and Coherence Setup
are present in all scenes and described in detail in Exploring the Network Playground.
Coherence Entity
is the prefab that will change per Scene with different functionality. It has a standard CharacterController
and Rigidbody
as well as an Agent
script which will handle movement functionality through the Input Manager
in the Core Scene Setup
prefab.
Coherence Connection Events
handles overall Scene connectivity. Additionally, it removes all Entities with coherenceSync
from the Scene to demo disconnection/reconnection via the Interface without refreshing the Scene.
Coherence Entity Character
(always change the prefab, not the instance) is located in the Resources folder. The UnityEngine.Transform
and position
are ticked to sync. All other settings (persistence and authority) use the default settings. This entity will be session based, no authority handover and no adoption will take place, when a client leaves.
The On Network Instantiation
event is used to change the colour of the mesh.
The Physics Entity Spawner
is a simple script to instantiate a Coherence Entity Physics
Prefab with a coherenceSync component that replicates the transform and position. The component also changes the material based on if it is locally simulated or synced over the network.
You can build this Scene via the Build Settings. Run the local Replication Server through the Window -> Coherence -> Settings window and see how it works. You can try running multiple clients rather than just two and see replicating for each.
A simulator build is a built Unity Player for the Linux 64-bit platform that you can upload to coherence straight from Unity Editor.
Make sure you have run through Build and run and Create an account.
On Unity's menu bar, navigate to coherence -> Simulator -> Build Wizard
.
From within the Build Wizard you can build and upload simulators.
The Info tab provides information and requirements to build simulators properly.
The Build tab creates valid simulator builds from Build Configuration Assets.
There's a known issue in the Platforms package provided by Unity where builds will fail when the project is not in the target build platform. To prevent this from happening, please switch your active platform to match the one used in your build configuration before building.
You can create them via Assets -> Create -> coherence -> Simulator Build Configuration
.
A newly created build configuration looks like this:
There are several settings you might want to change.
Specify the scenes you want to get in the build via the Scene List component.
Specify a Company Name and a Version from the General Settings component (optional).
Additionally, you can add our OptimizeForSize component (find it using Add Component). Specify which optimizations you want to use to reduce the final build size from the Optimize For Size component (optional).
This feature is experimental, please make sure you backup your project beforehand.
You can add an OptimizeForSize component to your build configuration via the Add Component in the build configuration inspector. It looks like this:
Select the desired optimizations depending on your needs.
Settings applied to built simulators will be reverted once the build process is completed, so these settings won't affect other builds you make.
Once you have created a valid simulator build, you can upload it to coherence.
If you built your simulator using the Build tab, you should have a valid path to your simulator build set already. If you haven't or want to use a different path, use the Browse button.
Target frame rate on simulator builds is forced at 30.
coherence only supports Unity at the moment. Unreal Engine support is planned. For more specific details and announcements, please check the Unreal Engine Support page. For custom engine integration, please contact our developer relations team.
The Network Playground is a starter project for you to dive into. It contains the latest SDK, all the required preview packages and a bunch of extra resources for you to learn how to make multiplayer games with coherence.
You will need Unity Version 2020.1.9f1 or later.
Download the Network Playground Project here
Each Scene in this Network Playground Project shows you something new:
Scene 1. Synchronizing Transforms
Scene 2. Physics
Scene 3. Persistence
Scene 4. Synchronizing Animations and Custom Variables
Scene 5. AI Navigation
Scene 6. Network Commands
Scene 7. Network Events
Welcome to the first scene of the coherence Network Playground. This scene will show you how easy it is to set up networking in your Unity project and sync GameObject transforms across the network.
In this example, each client will have a player character to move by clicking on the map to make the entity move to that location. Each client will only have control of its local entity.
In the Hierarchy of the Scene you can see three core Prefabs.
Core Scene Setup
and Coherence Setup
are present in all (Network Playground) Scenes and described in detail in Exploring the Network Playground.
Coherence Entity Character
is the Prefab that will change per Scene with different functionality. It has a standard CharacterController
and Rigidbody
as well as an Agent
script which will handle movement through the Input Manager
in the Core Scene Setup
prefab.
Coherence Entity Character
(always change the prefab, not the instance) is located in the Resources folder. The UnityEngine.Transform
and position
are ticked to sync. All other settings (persistence and authority) use the default settings. This entity will be session based, no authority handover and no adoption will take place, when a client leaves.
The On Network Instantiation
event is used to change the color of the mesh and recalculate the RigidBody collisions. That's it.
You can build this Scene via the Build Settings. Run the local Replication Server through the Window -> Coherence -> Settings window and see how it works. You can try running multiple clients rather than just two and see replicating for each.
The Network Playground project is a series of scenes with different features of coherence for you to pick through and learn.
They will teach you the fundamentals that should set you on your way to creating a multiplayer game.
Each Scene in this Network Playground Project shows you something new:
Scene 1. Synchronizing Transforms
Scene 2. Physics
Scene 3. Persistence
Scene 4. Synchronizing Animations and Custom Variables
Scene 5. AI Navigation
Scene 6. Network Commands
Scene 7. Network Events
Each scene comes with a few helpful core components.
This Prefab stores all the generic things that make up these simple Scenes.
Main Camera
PostFX Volume
Directional Light
Environment (Ground, Walls etc)
Navigation Interface
To move between the Scenes without having to enter and exit playmode, useful when testing the standalone build.
Input Manager
Input Manager that uses Raycasting to send a message to the GameObject (with a collider) that it hit.
This Prefab includes all of the things that make coherence work.
Interface
Canvas UI that handles Connection/Disconnection dialog and what address to connect.
Event System
Event system to interact with any UI in the scene.
Coherence Live Query
Game Object/Component with a query radius that coherence uses to ask the server "What is happening in the query radius?" so it does not query unnecessarily big areas of large worlds. You can find more information here.
Coherence Mono Bridge
GameObject/Component to transform the Mono based coherenceSync component to archetypes so all data can be processed as ECS code.
We use this component on anything that we require to be networked, whether this is a playable character, NPC (non playing character), an object (ball, weapon, banana, car, plant etc) or any Game/Input Managers that require to sync data between Clients/Simulators/Servers.
It scans the inspector for attached components and allows us to sync those component values (as long as they are public) and communicate them to other clients. It also allows us to set individual Prefabs persistent, authoritative and network connect/disconnect settings. There's much more information on the coherenceSync Fundamentals page
This scene will show you how easy it is to set up Networking in your Unity project and sync GameObject transforms and Physics objects across the network whilst keeping them persistent. As long as the server is running you can disconnect and re-connect, your world will persist.
In this example each client will have it's own player character to move, we will click on the map to make the entity move to that location, simple click to move functionality and right click to spawn local physics based objects that all other player characters can interact with. Each client will only have control of its local entity. You can disconnect and re-connect and the persistent entities will all remain.
In the Hierarchy of the Scene you can see three core Prefabs:
Core Scene Setup
and Coherence Setup
are present in all scenes and described in detail in Exploring the Network Playground.
Coherence Entity
is the prefab that will change per Scene with different functionality. It has a standard CharacterController
and Rigidbody
as well as an Agent
script which will handle movement functionality through the Input Manager
in the Core Scene Setup
prefab.
Coherence Connection Events
handles overall Scene connectivity. Additionally, it removes all Entities with coherenceSync
from the Scene to demo disconnection/reconnection via the Interface without refreshing the Scene.
The Physics Entity Spawner
component is a simple script to instantiate a Coherence Entity Physics Persistent
prefab with a coherenceSync component that replicates the transform and position. The component also changes the material based on if it is locally simulated or synced over the network.
Coherence Entity Physics Persistent
has Entity Lifetime Type
set to Persistent
. This means it will remain in the world as long as the replication server is running, even if all clients disconnect. It also has Authority Transfer Style
set to Stealing
which means the entity can be "stolen" and simulated on a client requesting authority.
The Auto Generate Persistance UUID
should be checked so that a unique identification string will be used to identify instances of this entity as unique. When the entity is spawned with this checked, it will generate its own UUID.
This is done via the Input Manager
in the Core Scene Setup
prefab. When the object is left-clicked, it sends the message "Adopt" to the GameObject on the specific Layer Mask "Physics Entities". The component called Coherence Handler
on Coherence Entity Physics Persistent
handles the Adopt call and requests the authority change via the coherenceSync component.
Coherence Handler
is a basic layer for handling Commands and Events, both sending and receiving. You can create your own or reuse and extend this for your project.
You can build this Scene via the Build Settings. Run the local Replication Server through the Window -> Coherence -> Settings window and see how it works. You can try running multiple clients rather than just two and see replicating for each.
This scene will show you how easy it is to set up Networking in your Unity project and sync GameObject transforms, animations via the Animator parameters and customer variables.
In this example, each client will have its own player character to move, the beloved Unity RobotKyle asset. Type your name into the connect dialog box and connect. You can move around with WASD. When another player connects, their name is carried across and their transform and animation state is replicated.
In the Hierarchy of the scene you can see the two core prefabs Core Scene Setup
and Coherence Setup.
Both are present in all scenes and described in detail in Exploring the Network Playground.
Coherence Kyle
is taken from the Unity asset "Robot Kyle", with added components Rigidbody
, Character Controller
, and Animator
with the two animation states - Idle and Walk. The animation states are controlled by a speed parameter from the Agent
script. The scene also contains a Name Badge
script which gets the Connect Dialog
GameObject from the Core Scene Setup
and sets the color depending if it's local or networked.
Attached to Coherence Kyle
is a coherenceSync component which replicates the parametersTransform; position and rotation
, Animator; Speed[float]
and NameBadge; Name [string]
. The authority and persistence settings are set to their default values and the On Network Instantiation
event is used to change the color of the networked entities.
You can build this Scene via the Build Settings. Run the local Replication Server through the Window -> Coherence -> Settings window and see how it works. You can try running multiple clients rather than just two and see replicating for each.
You can read more about synchronizing animations on the Animations section.
This scene will show you how easy it is to set up Networking in your Unity project and sync non player characters that move around the world via Unity's Navmesh system.
In this example each client can spawn as many navigation agents as they wish, and these navigation agents will move intermittently to different locations on the grid. All navigation agents will be replicated across clients with a specific colors signifying if they are local or networked.
In the Hierarchy of the Scene you can see three core Prefabs:
Coherence Connection Events
handles overall Scene connectivity. Additionally, it removes all Entities with coherenceSync
from the Scene to demo disconnection/reconnection via the Interface without refreshing the Scene.
Spawner
is a simple script to instantiate a Coherence Entity Nav Agent
prefab with a coherenceSync component that replicates the transform and position. The component also changes the material based on if it is locally simulated or synced over the network.
Coherence Entity Nav Agent
has a Nav Mesh Agent
component controlled via the Navigation Agent
script which every few seconds sets a new destination on the grid. It's not required to sync anything other than the Transform; position, rotation
parameter as the Nav Mesh Agent
settings only need to simulate locally.
You can build this Scene via the Build Settings. Run the local Replication Server through the Window -> Coherence -> Settings window and see how it works. You can try running multiple clients rather than just two and see replicating for each.
Core Scene Setup
and Coherence Setup
are present in all scenes and described in detail in .
Optimization
What it does
Replace Textures And Sounds With Dummies
Project's textures and sound files are replaced with tiny and lightweight alternatives (dummies). Original assets are copied over to <project>/Library/coherence/AssetsBackup
. They are restored once the build process has finished.
Keep Original Assets Backup
The Assets Backup (found at<project>/Library/coherence/AssetsBackup
) is kept after the build process is completed, instead of deleted. This will take disk space depending on the size of the project, but it's a safety convenience.
Compress Meshes
Sets Mesh Compression on all your models to High.
Disable Static Batching
Static Batching tries to combine meshes at compile-time, potentially increasing build size. Depending on your project, static batching can affect build size drastically. Read more about static batching.
This scene will show you how easy it is to set up Networking in your Unity project and send Network Commands to other clients. Network Commands is like sending a direct message to another player, without anyone else knowing.
In this example each client has one character they can control with click to move input. They can right-click on another Entity to send a command and that Entity will instantiate an Exclamation mark above their head.
In the Hierarchy of the Scene you can see three core Prefabs:
Core Scene Setup
and Coherence Setup
are present in all scenes and described in detail in Exploring the Network Playground.
Coherence Entity
is the prefab that will change per Scene with different functionality. It has a standard CharacterController
and Rigidbody
as well as an Agent
script which will handle movement functionality through the Input Manager
in the Core Scene Setup
prefab.
Coherence Entity
can send commands to other entities through the Coherence Handler
component. In the coherenceSync component, small "lightning bolt" icons are displayed next to the tick boxes for the syncable properties. These icons signify that they are public methods rather than singular variables and that these methods can be called through the Coherence Handler
Event System, either to send or receive commands.
In the game view in Play mode, Commands can be sent to other entities via the right click button. An exclamation mark asset should pop up above the right-clicked entity, but only for the sending and the receiving client. No other clients will be made aware of this.
You can build this Scene via the Build Settings. Run the local Replication Server through the Window -> Coherence -> Settings window and see how it works. You can try running multiple clients rather than just two and see replicating for each.
coherence provides a powerful matchmaking API with various different setups (multiple teams, team sizes, etc.).
Before using the matchmaking service you have to configure it on the developer portal. Currently there are two things to setup: the timeout and the teams.
The timeout is in seconds. There can be any number of teams and any number of players per team.
For example, a chess game would need only one team with two players, while in a socker game you'd need two teams with eleven players per team.
coherence provides an API for creating player game accounts that uniquely identify players across multiple devices. An account is required in order to use the rest of the online services, like the key-value store and matchmaking.
There are two types of accounts that are currently supported - guest accounts and user accounts.
Guest accounts provide an easy way to start using the coherence online services without providing any user interface for user names or password. Everything is controlled with the , and is completely transparent to the player.
The session data for the account is stored locally on the device so it is important to know that uninstalling the game will also wipe out all the data and the account will be no longer accessible even if the player installs the game again.
User accounts require explicit authorization by the player. Currently, only user name and password are supported as means for authentication. The user interface for entering the credentials must be provided by the game. Check the how to use this feature.
In the future, there will be support for many more authentication mechanisms like Steam, Google Play Games, Sign in with Apple, etc.
Please refer to the .
This scene will show you how easy it is to set up Networking in your Unity project and send Network Events to other clients. Network Commands is like sending a direct message to another player, without anyone else knowing. Network Events is like shouting out loud for anyone in the area to hear you.
In this example each client has one character they can control with click to move input. They can right-click anywhere on the grid and all entities will instantiate an exclamation mark above their head.
In the Hierarchy of the Scene you can see three core Prefabs:
Coherence Entity
is the prefab that will change per Scene with different functionality. It has a standard CharacterController
and Rigidbody
as well as an Agent
script which will handle movement functionality through the Input Manager
in the Core Scene Setup
prefab.
Network Events are still in development but this example shows a workaround using Commands. When an event is sent to an entity, Coherence Handler
finds all instances of coherenceSync and sends the event command to all these entities.
In the coherenceSync component, small "lightning bolt" icons are shown next to the tick boxes for the syncable properties. These icons signify that they are public methods rather than singular variables and that these methods can be called through the Coherence Handler
Event System, either to send or receive commands.
In the game view in Play mode, Commands can be sent to other entities via the right click button anywhere on the grid and an exclamation mark asset should pop up above all clients entities.
You can build this Scene via the Build Settings. Run the local Replication Server through the Window -> Coherence -> Settings window and see how it works. You can try running multiple clients rather than just two and see replicating for each.
Please refer to the
Core Scene Setup
and Coherence Setup
are present in all scenes and described in detail in .
coherence provides an API and a database for storing key-value pairs from within game sessions.
The key/value store provides a simple way to store and retrieve data for the currently logged in player. For example, you could store player's score, email address, or any other data.
It is important to mention that this feature requires a game account.
The keys must be alphanumerical strings, underscore or dash. Currently, only strings are accepted as values. If you need to store numbers or complex types like arrays, you have to convert them to strings.
The total amount of storred data (keys + values) cannot exceed 256 KB per player (TBD).
There is no limit how often the data is stored or retrieved.
Please refer to the Cloud API: Key-value store.
The coherence SDK is a set of prefabs & scripts to help you create multiplayer games super fast.
It makes it easy for anyone to create a multiplayer game by having flexible, intuitive and powerful visual components.
Here are the main building blocks of the SDK.
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. You can select which of the attached components you would like to sync across the network as well as individual public properties.
The coherence Settings window is located in Project Settings -> coherence
and lets you launch a local replication server, upload your server to the cloud via the access token and bakes your schemas for more optimized data transfer of our Networked GameObjects.
LiveQuery, as the name suggests, queries a location set by the developer so that coherence can simulate anything within its radius. In our Starter Project, the LiveQuery position is static with a radius large enough to cover the entire playable level. If the world was very large and potentially set over multiple simulation servers, the LiveQuery could be attached to the playable character or camera.
The coherence MonoBridge passes information between the coherenceSync component and the networked ECS components.
The sample UI Prefab holds all of the UI and connection functionality to connect to the running project locally or via a server. You can completely rewrite this if you like, it's there to get you up and running quickly.
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 Type
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.
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, you need to set When orphaned
to Auto Adopt
.
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.
If you want to run some custom code when passing ownership, you can add your own event callbacks in the CoherenceSync component. The OnBeforeAuthorityTransfer
event is invoked just before the transfer happens. The OnAfterAuthorityTransfer
event is invoked just after the transfer happens. Both events supply a boolean parameter. If set to true, it means you are getting ownership, and if false it means you are losing ownership. In other words, if a game object is transferred from Client A to Client B, the events will be invoked in this order:
1. ClientA: OnBeforeAuthorityTransfer(false);
2. ClientA: OnAfterAuthorityTransfer(false);
3. ClientB: OnBeforeAuthorityTransfer(true);
4. ClientB: OnAfterAuthorityTransfer(true);
The parameter taken by these events reports whether the local client has authority over it now.
When this object is synchronized over the network
lets you set if you instantiate the specific prefab or an alternative one by giving its name path (Make sure it's in the Resources folder). Very useful if you are setting up a local player (with controls, camera etc) and a variant without those components.
Event system for handling user connection and disconnection. Destroy Component Only
is really 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 are turned into ECS to send over the network, C# 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 into a Schema.
The schema is a text 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 Inspector of that Game Object called NameOfGameObject_Sync
.
OnNetworkedInstantiation
is called when the network entity is instantiated by coherence. This is the best moment to make sure you prepare the GameObject the way you need. For example, disabling colliders or swapping materials.
OnNetworkedDestruction
is called when the network entity is going to be destroyed by coherence. The boolean parameter it takes reports if the destruction behavior is set to just destroy CoherenceSync rather than the Game Object.
Refer to the commands section.
Refer to the events section.
Refer to the Level of detail section for more information.
The coherence User Interface is a prefab that you can add to your scene that handles Connection, IP, Port and Disconnection from your server. It is made up of a Unity UI Canvas and various buttons and images.
The main functionality is located on the "Connect Dialog" GameObject with the script Connect Dialog
Note: You can of course also build your own interface to connect players to the server.
List of the Cloud APIs
The coherence Cloud API allows us to access online services like game accounts, key-value store, matchmaking, and others. It also allows you to get the addresses (IP and port number) of the servers the players can connect to.
The Cloud API requires you to use tokens connected to your coherence project.
The MonoBridge is a system that makes sure every GameObject is linked to its networked representation. It essentially interfaces between the GameObject world and the DOTS/ECS-based coherence SDK code running "under the hood".
Note: All of this code is accessible to you and can be interfaced with directly using DOTS.
When you place a GameObject in your scene, the MonoBridge detects it and makes sure all the synchronization can be done via the CoherenceSync component.
The way you get information about the world is through LiveQueries. We set criteria for what part of the world we are interested in at each given moment. That way, the replicator won’t send information about everything that is going on in the game world everywhere, at all times.
Instead, we will just get information about what’s within a certain area, kind of like moving a torch around to look in a dark cave.
More complex area of interest types are coming in future versions of coherence.
A LiveQuery is a cube that defined the area of interested in a particular part of the world. It defined by its position and its radius (half the side of the cube). There can be multiple LiveQueries in a single scene.
A classic approach is to put a LiveQuery on the camera and set the radius to correspond to the far clipping plane or visibility distance.
Moving the GameObject containing the LiveQuery will also notify the replication server that the query for that particular game client has moved.
The coherence Settings window is located in Project Settings -> coherence
and lets you launch a local replication server, upload your server to the cloud via the access token and bakes your Schemas for more optimized data transfer of Networked GameObjects.
Enable CoherenceSync support
Uncheck Enable CoherenceSync support
to go pure ECS and use none of the visual tools.
Bake Schemas
When CoherenceSync variables/components are turned into ECS to send over the network, C# 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 poorly performing. A way to combat this is to bake the CoherenceSync component into a Schema.
The Schema is a text 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 to know about those types and to communicate 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 Inspector of that Game Object called NameOfGameObject_Sync
.
Active Schemas
Select the Schema files you want to use.
CoherenceSync (runtime reflection, slow)
CoherenceSync (baked, fast)
Bake Output Folder
Defines where to store the baked Schema files.
Portal
Upload your Schema files to your server.
Status - Current Status of your cloud server
Token - Cloud token
Local Replication Server
Run a local replication server.
Port - The port access
Frequency - Frequency of server.
You can fetch the by clicking on the down-arrow button on the right side of the input field.
Here is a sample script showing how you can use the server discovery API to get the servers associated with your runtime key.
Creating a player account is the first step towards using the coherence Cloud API. It is required in order to use the rest of the services.
To initialize the Cloud API you need to provide a Runtime Key that can be obtained from the settings.
The easiest way to get started is by using a guest account. The only thing that is needed is to call LoginAsGuest
. This will create a random username / password combination and will authenticate the player with the coherence Cloud.
Once logged in, the credentials are securely persisted so if the game is restarted the player will be able to log in automatically.
If the game is uninstalled then the account credentials will be lost and a new guest account will be created next time the game is installed.
Another alternative is to login with a username and a password. You have to provide the user interface.
This example initializes the Cloud API, checks for an existing session and, if no session was found or if it expired, logs in the player as guest.
coherence uses the concept of ownership to determine who is responsible for simulating each entity in the game world. By default, each client that connects to the server owns and simulates the entities they create. There are a lot of situations where this setup is not adequate. For example:
The number of entities in the game world could be too large to be simulated by the players on their own, especially if there are few players and the world is very large.
The game might have an advanced AI that requires a lot of coordination, which makes it hard to split up the work between clients.
It's often desirable to have an authoritative object that ensures a single source of truth for certain data. State replication and "eventual correctness" doesn't give us these guarantees.
Perhaps the game should run a persistent simulation, even while no one is playing.
With coherence, all of these situations are can be solved using dedicated simulation servers. They behave very much like normal game clients, except they run on their own with no player involved. Usually they also have special code that only they run (and not the clients). It is up to the game developer to create and run these programs somewhere in the cloud, based on the demands of their particular game.
If you have determined that you need one or more simulation servers for your game, there are multiple ways you can go about implementing these. You could create a separate Unity project and write the specific code for the simulation server there (while making sure you use the same schema as your original project).
An easier way is to use your existing Unity project and modify it in a way so that it can be started either as a normal game client, or as a simulation server. This will ensure that you maximize code sharing between clients and servers -- they both do simulation of entities in the same game world after all.
Please note that to build a simulation server, you have to build for the Linux platform.
To determine whether to start a build as client or simulation server, you can use command line arguments:
To pass the command line argument, start the application like this:
When building stand-alone builds, Unity also has an option for headless mode. This is great for simulation servers since we're not interested in rendering any graphics on these anyway. By using headless mode we get a leaner executable that is easier to deploy in the cloud.
Change your build target to be Linux and tick Headless Mode.
Refer to the Simulator: Build and deploy section.
These are the primitive types supported in a coherence schema:
Uses a default range of -9999 to 9999.
Uses a default scale of +/- 2400, which is encoded using 24 bits.
Encoded using a single bit.
Encoded using two floats.
Encoded using three floats.
The size of a string depends on its length. Try to keep the length of your strings as short as possible, or they won't fit inside a network package.
The Entity
type is used to keep references to other Entities. Technically the reference is stored as a local index that has to be resolved to an actual Entity before usage. Also, since a client might not know about the referenced Entity (due to it being outside of its live query) an Entity reference might be impossible to resolve in some circumstances. Your client code will have to take this into account and be programmed in a defensive way that handles missing Entities gracefully.
The most common definition in schemas is components, which correspond to ECS components in DOTS/ECS and to MonoBehaviours in regular Unity code.
The definition takes a name of the component, and on the following lines an indented list of member variables, each one followed by their primitive type (see above.) The indentation has to be exactly 2 spaces. Here's how it might look:
After code generation, this will give access to a component with the name Portal
that has the members locked
, connectedTo
, and size
.
Optionally, each member/type pair can have additional meta data listed on the same line, using the following syntax:
This is how it might look in an actual example:
There are some components that are built into the Protocol Code Generator and that you will always have access to.
Events are defined very similarly to components, but they use the event
keyword instead.
Here's a simple example Event:
Commands are defined very similarly to components, but they use the command
keyword instead.
Here's a simple example Command:
The Replication Server replicates the state of the world to all connected Clients and Simulators.
To understand what is happening in the game world, and to be able to contribute your simulated values, you need to connect to a Replication Server. The Replication Server acts as a central place where data is received from and distributed to interested clients.
You can connect to a Replication Server in the cloud, but we recommend that you first start one locally on your computer. coherence is designed so you can easily develop everything locally first before deploying to the cloud.
Replication Servers replicate data defined in schema files. The schema's inspector provides all the tools needed to start a Replication Server.
Run the Replication Server by clicking the run button.
A terminal/command line will pop up running your server locally
The port the Replication Server will use. Default: 32001
.
The Replication Server frequency. Default: 60
.
You can also start the replication server from the coherence menu or by pressing ctrl+shift+alt+N.
If you're unsure where schema files are located, you can easily search through the project using Unity's project search window, witht:Coherence.SchemaAsset
To connect with multiple clients locally, publish a build for your platform (File > Build and Run
, details in Unity docs). Run the Replication Server and launch the build any number of times. You can also enter Play Mode in the Unity Editor.
For Mac Users: You can open new instances of an application from the Terminal:
When the replication server is running, you connect to it using the Connect
command from one of your component systems.
After trying to connect you might be interested in knowing whether the connection succeeded. The Connect call will run asynchronously and take around 100 ms to finish, or longer if you connect to a remote server. One way is to poll the NetworkState once each tick until we know that it has succeeded. It is also possible to listen for a [network event]().
Check 'Run in Background' in the Unity settings under Project Settings -> Player so that the clients continue to run when not the active window.
Make sure that your system is actually run, for example by adding the [AlwaysUpdateSystem]
attribute to your system class. By default, Unity ECS will not run your system if it doesn't process any Entities.
ECS is a way of writing code that provides high performance by default.
Under the hood coherence is entirely ECS based but we supply the coherence Toolkit which is Mono-based to make it easier to make massive multiplayer games whatever way you want.
The current version of coherence uses the Unity Entities package. Unity that they will not support this package in Unity 2021 for a while. This means that the current recommended Unity version for using coherence is Unity 2020 LTS. This is only temporary as we have been working on removing the reliance on Entities internally.
If you would like to use the coherence SDK without the toolkit, we would recommend you take some time to learn about ECS and DOTS (Data Orientated Tech Stack) with Unity.
Entities — the entities, or things, that populate your game or program.
Components — the data associated with your entities, but organized by the data itself rather than by entity. (This difference in organization is one of the key differences between an object-oriented and a data-oriented design.)
Systems — the logic that transforms the component data from its current state to its next state— for example, a system might update the positions of all moving entities by their velocity times the time interval since the previous frame.
Here are various materials to learn:
Unity DOTS Overview -
Unity ECS Documentation -
Unity Learn, ECS -
The schema has two uses in your project:
As a basis for code generation, creating various structs and methods that can be used in your project to communicate with the replication server.
As a description for the Replication Server, telling it how the data in your project looks like – to receive, store, and send this data to its clients.
When using MonoBehaviours and CoherenceSync you often don't need to interact with the schema directly.
If you're writing your game using ECS/DOTS you will have to create and modify it yourself. Here's an example of a small schema:
To learn more about the types and definitions available in a schema, see the .
You want to spawn new stuff into the world. It is very similar to creating a .
You can add any networked components (from your schema or the coherence SDK) onto the requests.
There is one important thing to point out here -- the Translation
component that is added to the new entity will correspond to a WorldPosition on the server. There are several types defined by coherence that behave this way, because the server often needs to know more about the purpose of the data than we do in our code (for example how to compress the data, etc.) In our C# code this information isn't very useful, so instead we get the ubiquitous Translation
component from Unity:s ECS libraries there.
In the future there will be even more types that behave like this, and you'll be able to define them yourself too.
You can only destroy entities that you own. Check if there is a Simulated
component attached to the entity.
To destroy it, you just call DestroyEntity
as normal:
EntityManager.DestroyEntity(goblinEntity);
It will be ignored if no Simulated
component is attached.
As soon as you put a Simulated
component on an entity it will start syncing its data over the network and create entities on the remote clients. You won't sync anything related to the rendering (or sound for that matter) though, so the game won't appear very much in sync. To fix this, you need to add components like RenderMesh
, RenderBounds
and LocalToWorld
to the entity.
It turns out that doing it that way is unnecessarily cumbersome, since you already have methods for creating whatever kind of entities your game cares about. A better approach is to keep using those methods for setting up your entities and replace the networked entities with those ones.
Here are the recommended steps:
coherence replicates the networked components (without rendering, but you can see them in the Entity Debugger)
The game finds out that it can represent those entities visually (see below)
Create the visual representation and inform the server that it should update this new entity instead
Step 1 is already working if you have set up the SDK properly and have a WorldPositionQuery running.
Step 2 is more interesting. In its simplest form you need a system that looks for entities with some specific components, but are lacking RenderMesh
or similar components. Here's an example:
Finally in step 3 you can instantiate a new (local) Entity with all the graphics and other things needed for it to look good. You replace the networked entity with this new, good looking one using a utility method named Replace
. It tells the coherence SyncSendSystem
about this new entity, copies all the components from the networked entity, and finally removes the networked one. Since the new entity has a RenderMesh
now, it won't be processed by the ForEach
function again and coherence will keep updating it due to it having all the necessary network components!
Several of the primitive types can be configured to take up less space when sent over the network, see .
Archetypes are used to optimize the sending of data from the server to each client, lowering the precision or even turning off whole components based on the distance from the live query to a particular Entity. Read more about how to define them in the schema on the page .
When using reflection, there are limitations to what types are supported in commands. See the section for more information.
Group of Components that define a type. Makes use of LODs.
Allows a User to interact with the World. Connects to Replication Server.
Allows for sending an instruction to an Entity that may be running on a different machine.
Part of ECS. Describes a characteristic or aspect of an Entity.
Stands for Entity Component System. An entity system where entities are made of components.
An instance of an Archetype. Part of ECS.
Allows for signalling that something of significance has occurred allowing interested listeners to act on it.
Allows the Client to specify a subset of the World to receive updates from. Acts as a filter to exclude updates on less relevant entities that could otherwise result in undesired latency.
A partial representation of an Archetype. Allows for specifying priorities of components within an Archetype.
Generates the client schema source file (e.g. schema.cs) that automatically handles serialization/deserialization of an ECS world, commands, and events.
Replicates the state of the world to the connected Clients and Simulators.
Responsible for simulating a subset of the game world. Connects to Replication Server through which the state gets replicated to Clients.
The key-value store provides a simple persistence layer for the players.
This class provides the methods to set, get and unset key-value pairs. This is executed within the context of the currently logged in player.
Size: there are no limits to the number of stored key/values as long as the total size is less than 256kb.
Requests: Set/Get/Unset can be called unlimited amount of times but the execution may be throttled.
coherence Network Playground (Unity Version 2020.1.9 or later)
Coming soon.
Many of the primitive data types in coherence supports configuration to make it possible to optimize the data being sent over the network. These settings can be made individually for each field of a component and will then be used throughout your code base.
The field settings uses the meta data syntax in the schema, which looks like this:
The meta data always goes at the end of the line and can be set on both definitions and the fields within a definition, like this:
In this example, an ECS component named Health would be created, but instead of using the default 24 bits when sending its value, it would just use 8. Any updates to it would also be deprioritized compared to other components, so it could potentially be sent a bit late if bandwidth is scarse.
Component updates do not only contain the actual data of the update, but also information about what entity should be affected, etc. This means that the total saving of data won't be quite as large as you'd think when going from 24 to 8 bits. Still, it's a great improvement!
All components support a piece of meta data that affects how highly the Replication Server will prioritize sending out updates for that particular component.
This meta data is set on components, like this:
The available priority levels are:
"very-low"
"low"
"mid" (default)
"high"
"very-high"
Some of the primitive types support optimizing the number of bits used to encode them when sending the over the network. It's worthwhile to think through if you can get away with less information than the default, to make room for more frequent updates.
All of these types support the same two settings:
bits
– how many bits the type should use to encode its floating point values
scale
– the maximum and minimum value of each of its scalars (a scale of
Integers can be configured to only hold a certain range via:
range-min
– the lowest possible value that the integer can hold
range-max
– the largets possible value that the integer can hold
Using these settings you can emulate other numeric types like char
, short
, unsigned int
, etc.
Right now quaternions don't have any settings, but this will be remedied soon.
The other types doesn't have any settings that affect the number of bits they use. If they take up to much bandwith you'll have to try to send them less often, using priority, update frequency, or LODing.
This document explains how to use Archetypes and LOD-ing in ECS/DOTS. If you're using coherence with MonoBehaviours, see this page instead.
Level of Detail (or LOD-ing, for short) is a technique to optimize the amount of data being sent from the replication server to each client. Often a client doesn't need to get as much information about an entity if it's far away. The way this is achieved when working with coherence is by using archetypes.
Archetypes let you group components together and create distinct "levels of detail". Each such level must have a distance threshold, and a list of components that should be present at that distance. Optionally it can also contain per-field overrides that make the primitive data types in the components take up less space (at the cost of less precision.)
To define an archetype, use the archetype
keyword in your schema, then list the LODs in ascending order. Notice that LOD 0 does not need a distance, since it always starts at 0. Here's an example of a simple archetype:
In this example, any Enemy entity that is 200 or more units away from the live query of a particular client will only get updates for the WorldPosition
. Any client with a distance of 10 – 200 will get WorldPosition
and WorldOrientation
, and anything closer than that will get the full entity.
Given one or more archetype definitions in your schema, you will have access to a few different data types and methods in your project (these will be generated when you run the Protocol Code Generator.)
ArchetypeComponent
– this component has a field index that keeps track of which one of the archetypes in your schema that is being used. If you add the ArchetypeComponent
yourself you have to use the static constants in the Coherence.Generated.Archetype
to set the index. These all have the name "archetype name" + "Index", e.g. EnemyIndex
in the example above.
An individual "tag" component (with no fields) called "archetype name" + "Archetype", e.g. EnemyArchetype
in the example above. This component can be used to create optimized ForEach queries for a specific archetype.
LastObservedLod
– this component holds the current LOD for the entity. This can be used to detect when the entity changes LOD, if that's something you want to react to. Note that this component is not networked, since the exact LOD for an entity is unique for each client.
Static helper methods on the Archetype
class to instantiate the archetype in a usable state. These are named "Instantiate" + "archetype name", e.g. InstantiateEnemy
in the example above.
If a component isn't present at a certain LOD, no updates will be sent for that component. This is a great optimization, but sometimes a little too extreme. We might actually need the information, but be OK with a slightly less fine-grained version of it.
To achieve this, you can use the same field settings that are available when defining components, but use them as overrides on specific LOD's instead.
Here's an example of the syntax to use:
Notice that the settings are exactly the same as when defining components. To override a field, you must know its name (value
in this case.) Any field that is not overridden will use the settings of the LOD above, or the original component if at LOD 0.
Each component in an archetype can also override the default priority for that component. Just add the priority meta data after the component, like this:
To read more about priority, see the page about Field Settings.
This tool has built in help that you can access like this:
protocol-code-generator --help
If you want information about a special command, instead do:
protocol-code-generator --help generate
When running the schema generator, it needs to know the location of the schema file and what kind of code it should generate.
It will emit the generated code to stdout
, so you have to pipe that to a text file in order to save it (for example using the >
operator). Here's an example of how it can look:
protocol-code-generator generate --code csharp --ecs unity --schema ./coherence.schema > ./generated/schema.cs
The emitted file should be placed somewhere inside your Unity project.
The replication server also has general and specific help.
replication-server --help
replication-server --help serve
To start the server, you need to give it the location of the schema, like this:
replication-server serve --schema ../Assets/coherence/coherence.schema
In the example above we're running the server from the coherence-bin
directory right at the root of your project.
You can also define other parameters like min-query-distance
(the minimum distance the LiveQuery needs to move for the replicator to recognize a change), frequency
, ip
and port
number.
replication-server serve --min-query-distance 10 --port 32001 --frequency 320 --schema "C:\Users\tadej\Desktop\work\coherence\gamejam-stellar\Assets\Schemas\stellar.schema"
You can run coherence simulation server using
./sim_x86_64 --coherence-simulation-server
The persistence client has general and specific help.
persistence-client serve --help
persistence-client --help serve
Some extra scripts that are part of the Network Playground that may be useful
Flags
-d, --schema=STRING
The schema file (.schema)
-o, --output=STRING
Output file
--output-dir=STRING
Output directory (can only be used together with --split)
-c, --code=STRING
-e, --ecs=STRING
--sync=STRING
Flags
--port=32001
The port to listen to
--stats-port=32000
The port to listen for stats scrapers
--dump
Write network packets to capture files (.packets)
--frequency=20
The server update frequency
--schema=STRING
The schema file (.schema)
--entities=STRING
Entity snapshot (.yaml)
--parent-replicator=STRING
Host address for parent replicator connection
--use-world-partitioner
If set, the binary_partitioner is used
--disconnect-timeout=5000
Disconnect timeout (in milliseconds)
--debug-streams
Use debug streams
--max-entities=65536
Maximum number of entities allowed
--min-query-distance=0.1
Minimum distance for query change
Flags
--save-file-name="world.save" .
The name of the persistent save file
--save-folder="."
The folder where the save file is written
--save-frequency=30
The frequency in which the save file is written, in seconds
--host="127.0.0.1:32001"
The host:port to connect to
--dump
Write network packets to capture files (.packets)
--frequency=20
The server update frequency
--schema=STRING
The schema file (.schema)
--disconnect-timeout=5000
Disconnect timeout (in milliseconds)
--debug-streams
Use debug streams
--query-world-position="0,0,0"
Position of the center of the entity query
--query-radius=10000
Radius of entity query
--log-level=LOG-LEVEL-STRING
Log level
--log-file=LOG-FILE-STRING
Log output file
--panic-on-error
Enable/disable panic on error
We are currently preparing a fair and affordable pricing model in line with our philosophy of fairness and supporting low-risk iterative game development.
For more information, please check back later or contact our developer relations team.
Unreal Engine support is planned for a future release of coherence.
Check back here for more news or contact devrel@coherence.io for more information or collaboration options.
You can also join our Discord to get in touch with the team directly.
Full peer-to-peer support is coming in a future coherence release.
Check back here for more news or contact devrel@coherence.io.
You can also join our Discord to get in touch with the team directly.
For information about our SLA options, please check back later or contact our developer relations team.