LogoLogo
⚠️ Outdated documentationGo to LatestHomeAPI
SDK 0.9
SDK 0.9
  • Welcome
  • Overview
    • What is coherence?
    • How does coherence work?
    • Features and Roadmap
    • Rooms and Worlds
    • Requirements
    • Release Notes
  • Get Started
    • Install coherence
    • Scene setup
    • Prefab setup
    • Baking and code generation
    • Build and run
    • Create a free account
    • Deploy Replication Server
    • Share builds
    • Troubleshooting
  • Authority and communication
    • How authority works
    • Authority transfer
    • Commands
    • Simulation frame
    • Client connections
    • Server-authoritative setup
    • GGPO
    • Animations
    • Value sync callbacks
  • Persistence
    • Overview
    • Configuring persistence
    • Storage
    • Example – a global counter
  • Optimization
    • Overview
    • Simulation frequency
    • Areas of interest
    • Level of detail
    • Interpolation
  • Connected entities
    • Overview
    • Entity references
    • Parent-child relationships
    • CoherenceNode
  • Simulators
    • Overview
    • Client vs Simulator logic
    • Build and deploy
    • Simulator load balancing
    • Room Simulators
    • Multi-Room Simulators (advanced)
    • World Simulators
    • Simulator slugs
    • Testing Simulators locally
  • Tutorial project
    • Get the Tutorial Project
    • Start Tutorial
      • 1. Transforms
      • 2. Physics
      • 3. Persistence
      • 4. Animation and variables
      • 5. AI navigation
      • 6. Network commands
      • 7. Team-based
      • 8. Connected Entities
  • Game Services
    • Game account
    • Key-value store
    • Matchmaking
  • Developer Portal
    • Overview
    • Dashboard
    • Enabling game services
    • Configure Rooms
    • Manage Worlds
  • API reference
    • coherence SDK
      • CoherenceSync
      • MonoBridge
      • LiveQuery
      • Level of detail
      • Sample UI
      • Settings window
      • Custom bindings (advanced)
      • PlayResolver
      • Rooms
      • Worlds
    • Cloud API
      • API tokens and keys
      • Game account
      • Key-value store
      • Matchmaking
    • Replication Server
    • Simulation Server
  • Schema reference
    • Overview
    • Specification
    • Field settings
    • Archetypes in schemas
  • Resources
    • Downloads
    • SDK update guide
    • Video tutorials
    • Order of execution
    • Glossary
    • CLI utilities
    • Simulator CLI arguments
    • Helper scripts
    • Troubleshooting
    • Continuous Integration setup
  • Community
    • Community
  • Additional information
    • Pricing
    • SLA
    • Unreal Engine support
    • WebGL
    • Peer-to-Peer (P2P)
Powered by GitBook
On this page
  • Client authority
  • Server authority
  • Remote Communication

Was this helpful?

Export as PDF
  1. Authority and communication

How authority works

Last updated 2 years ago

Was this helpful?

Networked entities can be simulated either on a Game Client ("Client authority") or a Simulation Server ("Server authority"). Authority defines which Client or Simulation Server is allowed to make changes to an Entity. An Entity is any networked GameObject.

When an Entity is created, the creator is assigned authority over the Entity and that authority can be between Clients and Simulators, but only one Client or Simulator can be the authority over the Entity at at time.

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 authority

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 Replication Server (with 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 Replication Server) is planned in a future release. Please see the for updates.

Remote Communication

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 .

transferred
input queues
Peer-to-peer page
network command
requesting a transfer of authority