What Is an Authoritative Game Server? Client vs Server

The useful question is not “should everything be server-authoritative?” It is which machine or service is allowed to make the final decision for each valuable piece of state? Movement and combat may belong to the match server. Inventory grants may belong to a persistent backend. Cosmetic animation can remain entirely client-side.

What “authoritative” actually means

Authority is ownership of the final decision. In a typical client-server action game, clients send intent such as “move with this input,” “fire this weapon,” or “use this ability.” The server checks the request against the game rules, advances the simulation, and replicates accepted state back to clients. Unreal Engine describes the same model: the server holds the authoritative game state while clients render an approximation of it. Epic's networking overview is a good engine-specific example.

This does not imply that every byte must originate on the server. Clients still own presentation, camera, sound, animation and local input collection. They can also predict likely outcomes for responsiveness. What they should not do is unilaterally declare a valuable shared result that the trusted authority never verifies.

Three authority boundaries that are easy to conflate

Authority	Typical owner	Examples
Realtime simulation	Dedicated or listen game-server process	Movement, collisions, damage, projectiles, round state
Session authority	Game server and/or session service	Who joined, team assignment, reconnect seat, match lifecycle
Durable backend authority	Trusted backend service	Inventory, currency, progression, leaderboard result, entitlement

A secure design often uses all three. The game server decides who won the match; a trusted server credential submits that result; the durable backend applies XP, rating and rewards exactly once. The client can display the reward immediately, but it does not get to mint it.

Authoritative does not mean dedicated

A dedicated server is a server process with no local player. A listen server is a player's game instance acting as both client and server. Both can be authoritative in a client-server architecture. Epic's dedicated-server documentation explicitly notes that the hosting client is the authoritative host in the listen-server model; the difference is where the trusted process runs and what risks you accept.

Topology	Where simulation authority lives	Main trade-off
Dedicated server	Neutral server process	Hosting/operations cost; strongest separation from players
Listen server	One player's process	Cheap and simple, but host trust, host advantage and host departure matter
Relay/P2P-style design	Depends on the protocol	A relay can forward traffic without being gameplay authority; host/lockstep/rollback models define trust differently
Async / turn-based backend	Often an HTTP/backend service	No continuously ticking authoritative simulation may be necessary at all

Send commands, not valuable conclusions

The most useful authority rule is to make untrusted clients request an action rather than submit the valuable result of that action.

Risky client claim	Safer request	Authority checks
“My position is now X=900.”	“Here are my movement inputs.”	Speed, collision, movement state, elapsed time
“I dealt 100 damage.”	“I fired weapon A at tick/input N.”	Ammo, cooldown, pose/history, hit rules
“Give me 1,000 coins.”	“I completed reward source R.”	Server-owned completion evidence, replay/idempotency, reward rules
“I won; set my rating to 2200.”	Trusted match server submits the final result.	Server credential, match identity, duplicate-result protection

What server authority prevents, and what it does not

If the server actually owns and validates the relevant rule, a modified client cannot simply declare an impossible position, grant itself an item, change health, or fabricate a match result. That removes an entire class of client-trust exploits.

Authority is not a complete anti-cheat system. It does not by itself stop aim assistance, bots, collusion, information abuse caused by over-replication, or exploits in your own server rules. A listen server also gives the hosting player a different trust boundary from a neutral dedicated process. See the server-authoritative anti-cheat guide for that split.

Prediction, reconciliation and interpolation are optional tools

A naive round trip can make locally controlled actions feel delayed, so latency-sensitive games often render a speculative local result before the server confirms it. Prediction does not transfer authority to the client. It creates a temporary local view that may later be corrected.

• Client-side prediction: render likely local outcomes immediately when the game can predict them safely.
• Reconciliation: correct the local prediction when authoritative state arrives, often reapplying unacknowledged inputs.
• Interpolation: render remote entities from a short state buffer so irregular packet arrival does not become visible jitter.

A turn-based game may need none of these. A fighting game may choose rollback rather than the snapshot/interpolation pattern. A physics-heavy action game can need prediction only for selected entities. Treat them as tools chosen by the latency model, not as a checklist that defines whether a server is authoritative.

Simulation tick rate is not the same thing as network update rate

The simulation may advance on one cadence while state replication, input transmission and expensive subsystems run on others. A higher simulation rate can reduce discretization error and improve responsiveness, but it also spends more CPU; a higher replication rate spends more bandwidth and serialization work. There is no useful universal “correct” tick rate.

Choose the cadence from the mechanics you need to resolve, then test it under realistic CPU load, packet loss, jitter and latency. Do not copy a famous game's tick number without measuring your own simulation. Engines also give you relevance/dormancy or similar tools so not every object must be replicated to every connection every simulation step.

When do you need server-side authority?

• Competitive realtime gameplay: usually for the rules whose manipulation would change a meaningful outcome.
• Shared worlds: some trusted owner is needed for contested state, but it may be a dedicated server, listen host or another domain-specific authority depending on your threat model.
• Durable economy/progression: use trusted backend authority even when the gameplay itself is peer-hosted.
• Async/turn-based games: an HTTP/backend service can be the authority; you may not need a realtime game server at all.
• Trusted small co-op: a listen server can be a sensible product choice if you accept host trust and lifecycle trade-offs.

Where Crux fits today

Crux's production backend can be the durable authority for player identity, documents, economy state, leaderboards and other persistent data. A trusted game server can use server credentials to submit results or mutations that should never come directly from a modified client.

Crux Runtime is different: it is currently a capacity-gated closed alpha for approved Godot 4 Linux dedicated-server workloads in one EU region, with a fixed server shape and ephemeral sessions. If your server process runs there, your game binary remains the authoritative simulation. Runtime does not replace your realtime netcode, replication, prediction, reconciliation, game rules, managed reconnect logic, persistent worlds or general-purpose fleet autoscaling.

That separation is intentional: hosting the authoritative process and implementing the authority model are different problems.

Next, compare where that authoritative process can run in Listen Server vs Dedicated Server vs Hosted Server.