LogoLogo
⚠️ Outdated documentationGo to LatestHomeAPI
SDK 1.2.4
SDK 1.2.4
  • Welcome
  • Overview
    • Features
    • Roadmap
  • Getting started
    • Get the Unity SDK
    • Setup a project
      • Scene setup
      • Prefab setup
      • Sample connection UIs
      • Local development
        • Local testing using Builds
        • Local testing via Unity's Multiplayer Play Mode (MPPM)
        • Local testing via ParrelSync
      • Test in the cloud
        • Deploy a Replication Server
        • Share builds
    • Video tutorials
    • Samples and tutorials
      • Package samples
      • First Steps tutorial
        • 1. Basic syncing
          • 1.2. Animation parameters
          • 1.3. Sending commands
        • 2. Physics / Authority transfer
        • 3. Areas of interest
        • 4. Parenting entities
        • 5. Complex hierarchies
        • 6. Persistence
      • Campfire project
        • Game mechanics
        • Leveraging object pooling
        • Remote interactions: Chairs
        • Remote interactions: Trees
        • A unique object with complex state
        • Custom instantiation and destruction
        • Running a server-side NPC
        • Playing audio and particles
        • A simple text chat
      • Beginner's guide to networking
  • Manual
    • Unity Components
      • CoherenceSync
      • CoherenceBridge
      • CoherenceNode
      • CoherenceLiveQuery
      • CoherenceTagQuery
      • PrefabSyncGroup
      • CoherenceInput
      • Order of execution
    • Networking state changes
      • Supported types
      • Messaging with Commands
      • Syncing child GameObjects
      • Animation
      • CoherenceSync references
      • [Sync] and [Command] Attributes
      • [OnValueSynced] Attribute
      • Creating your own syncable member
      • Custom Component Actions
      • Rigid Bodies
      • Interpolation
    • Authority
      • Authority transfer
      • Server-authoritative setup
    • Lifetime
      • Persistence
      • Uniqueness
      • Example: A global counter
    • Parenting network entities
      • Direct children CoherenceSyncs
      • Deeply-nested CoherenceSyncs
      • Nesting Prefabs at Edit time
    • Asset management
      • Instantiate via
      • Load via
      • Instantiating from CoherenceSyncConfig
    • Scene management
    • Baking (code generation)
    • Replication Server
      • Rooms and Worlds
      • Replication Server API
    • Simulators (Servers)
      • Scripting: Client vs Simulator
      • Run local Simulators
      • World Simulators
      • Room Simulators
      • Simulator slugs
      • Multi-Room Simulators
      • Build and Deploy
      • Command-line arguments
    • Client Connections
    • Optimization
      • Areas of Interest
      • Level of Detail (LOD)
      • Profiling
      • Simulation Frequency
    • Project Settings
    • Advanced topics
      • Big worlds
        • World Origin Shifting
        • Load balancing
      • Competitive games
        • Simulation Frame
        • Determinism, Prediction and Rollback
      • Team workflows
        • Version Control integration
        • Continuous Integration
      • Schema explained
        • Specification
        • Field settings
        • Archetypes
      • Code Stripping
      • Command-line interface tools
      • Single-player gameplay
    • Scripting API
  • Hosting
    • Choosing where to host
    • coherence Cloud
      • Online Dashboard
      • Manage Worlds
      • Configure Rooms
      • Lobbies
      • Game Services
        • Account
        • Key-Value Store
      • coherence Cloud APIs
        • Worlds API
        • Rooms API
        • Lobbies API
        • Game Services
          • Authentication Service (Player Accounts)
          • Key-value store
    • Peer-to-peer
      • Implementing Client hosting
  • Support
    • Release notes
    • Glossary
    • Unreal Engine support
    • WebGL support
    • ECS / DOTS support
    • Known issues and troubleshooting
    • Upgrade guide
      • Upgrade 1.1 -> 1.2
      • Upgrade 1.0 -> 1.1
      • Upgrade 0.10 -> 1.0
      • Upgrade 0.9 -> 0.10
    • Credit cost & pricing
Powered by GitBook
On this page
  • Authority models
  • Communicate with remote entities

Was this helpful?

Export as PDF
  1. Manual

Authority

Last updated 11 months ago

Was this helpful?

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.

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

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

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

Authority 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

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.

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!

Communicate with remote entities

Having one or several 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.

You can read more about how to achieve this in the section about .

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 or even .

Simulators
Server-authoritative setup
network command
requesting a transfer of authority
transferred
between Simulators