How authority works
Last updated
Was this helpful?
SDK 0.4.14
Last updated
Was this helpful?
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 .
Even if an entity is not currently being simulated locally, we can still affect its state by sending a , network events or even .