Authority

Networked entities can be simulated either on a Game Client ("Client authority") or a Simulator ("Server-side authority"). Authority defines which Client or Simulator is allowed to make changes to the synced properties of an entity, and in general defines who "runs the gameplay code" for that entity.

When an entity is created, the creator is assigned authority over the entity. Authority can be then transferred at any time between Clients – or even between Clients and Simulators, or between Simulators.

In any case, only one Client or Simulator can be the authority over the entity at any given time.

To learn more about authority, check out this short video:

You can see the basic Authority principles in practice in our First Steps interactive demo. You can read the explanation as well.

Authority models

When architecting a multiplayer game, it is important to choose which authority model the game relies on. coherence supports a variety of models.

Distributed Client 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 and commands is the combined ping (Client 1 to Replication 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).

Server-side authority

Having one or several Simulators taking care of important world simulation tasks (like AI, player character state, score, health, etc.) is always a good idea for competitive PvP games. In this scenario, the Simulator has authority over key game elements, like a "game manager", a score-keeping object, and so on.

Running a Simulator in the cloud next to the Replication Server (with the ping between them being negligible) will also result in lower latency.

Server-side with Client input

A typical choice for competitive games, sometimes called "Server-authoritative". The entity is simulated on the Server, and the Client only sends inputs. To achieve smoother gameplay, the Client can predict the entity's state locally and then reconciliate once the Simulator has come back with a new state.

You can read more about how to achieve this in the section about Server-authoritative setup, or below in the Input authority section.

Mixing authority models

A cool possibility that coherence enables is to mix these modes, since authority is not tied to the match but rather a property of each CoherenceSync.

So for instance, you can have a game where some critical entities are server-side with client input for cheat prevention, while others are distributed among Clients. It's up to you!

Authority types

While we generally speak of "authority" in abstract, in the coherence model we break authority in two, in order to support the variety of scenarios needed in multiplayer games. We call these State authority and Input authority.

A Client or Simulator can only have State authority over an entity, only Input authority, or both (in this case we say it has "full authority"). In fact, if you use coherence on a basic level, most of the time you will be dealing with full authority without realising it.

State authority

When a Client has State authority over an entity it means that they are authorized to change its state, that is, the values of the entity's networked properties.

For instance, if the entity's Transform.position and Transform.rotation properties are set to sync, the Client who has authority can change these and move the entity around.

A Client who tries to change properties with no State authority will see those properties be reset immediately by coherence.

Hint: If you see an entity jittering around, it might be the signal that the current Client has no authority over an entity, but it's trying to change its values. Time to do some debugging!

Input authority

When a Client or Simulator has State authority over an entity, it means that they are authorized to send inputs to the State authority.

Whoever has State authority then is in charge of processing that input, and producing a new state for the entity, which is then sent to all observing Clients.

Splitting Input and State authority is a common pattern when creating a server-authoritative setup.

Special authority states

Orphans

Entities that no-one has authority over (neither State nor Input) are called "orphans". Orphaned entities are not simulated, so the values of their synced properties don't change. In a way you could think of them as sleeping.

Authority over an entity can be given up using CoherenceSync.AbandonAuthority(). Using this API will make an entity orphan until someone else adopts it. An entity can also become an orphan when a Client or Simulator that had State authority disconnects.

To change the state of an orphan entity, someone has to take State authority over them. This is done either automatically when an orphan is seen for the first time (only if the entity is set to be on Auto-Adopt Orphan), or intentionally, using the API CoherenceSync.Adopt().

For an entity to become an orphan, they need to be set as Persistent. A non-persistent entity that is abandoned will be immediately deleted by the Replication Server.

Remote entities

When a Client has no authority whatsoever over an entity, we often refer to that entity as "remote". It's important to understand that a remote entity is only remote to some of the Clients, so "remote" is not a authority state in itself, but just a way to refer to an entity from the point of view of a certain Client.

For instance, an entity seen as remote by Client A might be:

• Authoritative on some other Client B or C, or on Simulator A, etc.

• If no one has authority over it, it is an orphan.

Even if an entity is not currently being simulated locally (the Client does not have authority), we can still affect its state by sending a network command or even requesting a transfer of authority.

Authority in practice

To recap all possibilities with an example, consider the following case. We're creating a competitive 1v1 robot fighting game in a big arena.

• Client A has Input authority over their mech robot.

• Client B also has Input authority over their robot.

• The Simulator Server in charge of the match has State authority over both mechs, so they can't cheat.

• Client A sees the robot belonging to Client B as a remote entity.

• The same happens to Client B: they see Client A's robot as remote.

• Authority transfer has been disabled for the robot mechs, so even if cheating, Clients couldn't be stealing authority from each other.

• Client A also has State authority over some cosmetic items they are wearing.

• They can turn them on/off at any time by enabling/disabling the MeshRenderer component, or literally remove them and leave them on the ground.

• If Client A drops an item to the ground, the entity gets abandoned by them. It is now an orphan, and won't move for the duration of the match.

• If Client B finds the cosmetic item and picks it up, they will adopt it and can now wear it on themselves.

We hope that using this example you can see all the possibilities that a flexible authority system can provide.