Authoritative servers vs peer-to-peer, who decides what's true in your game

Field note. Game servers are mostly authoritative. P2P shows up in some unexpected places. Knowing the difference explains why cheating works the way it does and why anti-cheat is hard.

In any multiplayer game, multiple players see the world differently because of latency. When the views differ, something has to decide which version is "real."

The two main approaches:

• Authoritative server. A central server holds the canonical state. Clients are subordinate.
• Peer-to-peer (P2P). Players communicate directly. Some scheme negotiates state.

Each is suited to different games. The choice has cascading consequences. This article explores both.

The authoritative server model

How it works:

1. Server runs the simulation.
2. Players send their inputs to the server.
3. Server processes inputs, updates the simulation.
4. Server sends each player a snapshot of relevant state.
5. Clients render based on snapshots, with prediction filling the gap.

The server's view of the world is "truth." If your client thinks you hit someone but the server disagrees, the server wins.

Almost all modern competitive games use this model.

Why authoritative server dominates

Several reasons:

Cheating resistance. Clients can be modified. Servers (if hosted by the developer) can't be (easily). With server authority, common cheats (teleport, infinite health, wallhacks for some types) are harder.

Consistent state. All players see the same truth. No "we're both seeing different versions of who's winning."

Easier rules enforcement. Game logic lives in one place.

Better moderation. Bad actors can be banned from a central place.

Spectator support. A central server can naturally broadcast to spectators.

Persistence. State is kept on the server, available across sessions.

Costs:

• Server infrastructure required.
• Server location matters (latency).
• Single point of failure.
• Hosting cost.

For competitive games, the benefits dominate. The cost is acceptable.

When authoritative server is mandatory

If your game has:

• Any economic component (in-game purchases, marketplaces).
• Competitive leaderboards.
• Anti-cheat requirements.
• Persistent characters.
• Significant simulated state.

Then you essentially must have authoritative server. The alternative is "anyone can cheat."

Most modern MMOs, competitive games, and live-service games use authoritative servers.

The P2P alternatives

P2P is less common in modern games but still exists. Several flavors.

P2P with one host

A player's machine acts as the host. Others connect to them. The host's machine is "the server" for that match.

Examples: classic Halo, Call of Duty multiplayer (some modes), many indie co-op games.

Advantages:

• No dedicated server infrastructure.
• Free for the game publisher.
• Works for casual / small-scale.

Disadvantages:

• Host has authority and home-network advantage.
• Host's connection is critical; if it's bad, everyone suffers.
• Host migration when host leaves is complex.
• Cheating possible if host modifies their machine.

For casual co-op (4-8 player), host-based P2P often works fine. For competitive play, problematic.

Pure P2P with consensus

No host. Players exchange state directly and negotiate truth.

Used in some legacy games (older RTS games like StarCraft Brood War). Modern usage is rare due to cheating concerns.

Rollback netcode (a hybrid)

Players run their own local simulations. They send inputs to each other. When new input arrives, the receiver rolls back the simulation, applies the new input, replays forward.

Used in modern fighting games (Street Fighter VI, Guilty Gear Strive, etc.). The reason: action games need very low effective latency; rollback gives near-zero latency feel.

Tradeoff: complex implementation. Visual glitches if rollback is significant. Doesn't scale beyond 2-4 players easily.

Delay-based netcode (older fighting game model)

Players' inputs are delayed before being applied locally, giving the network time to propagate. All players see actions at the same time.

Smoother visually than rollback but feels less responsive. Older fighting games (Street Fighter 4) used this; newer ones moved to rollback.

The two models, side by side

Specific games and their models

Minecraft Java: authoritative server.

Minecraft Bedrock: authoritative server.

Valheim: P2P with one player as host. (Or dedicated server if hosted.)

Counter-Strike: authoritative server.

League of Legends: authoritative server.

Among Us: P2P with host.

Most fighting games: rollback P2P.

Civilization series multiplayer: P2P with synced simulation.

Most MOBAs (DOTA 2, LoL): authoritative server.

Most battle royales (Fortnite, Apex, etc.): authoritative server.

Pattern: real-time, large-scale, competitive → authoritative server. Smaller, more casual, lower-stakes → can be P2P with host.

What this means for the player

The model affects you in specific ways:

Authoritative server:

• You may experience "I shot them but it didn't count" because the server disagreed.
• Cheating is harder; the game is fairer.
• Server downtime can prevent play entirely.
• Your ping to the specific server matters.

P2P with host:

• The host has slight advantages (their ping is 0; everyone else's includes the path to them).
• Host's connection issues hurt everyone.
• Cheating by the host is possible.
• Game continues even if servers are down (you and friends can play directly).

Rollback netcode:

• Very low effective latency.
• Brief visual glitches when prediction is wrong.
• Some "what happened?" moments.

P2P and NAT

P2P games require direct connections between players. NAT is a major obstacle. Hence the focus on:

• UPnP for automatic port forwarding.
• STUN / TURN for NAT traversal.
• Relay servers as fallback.

Many P2P games include a relay-server fallback (e.g., Steam's relay for games using Steamworks). If direct connection fails, the relay forwards traffic. Higher latency but works.

The hidden hybrid: authoritative server with peer-to-peer voice

A common pattern in modern games:

• Game state: authoritative server.
• Voice chat: P2P among players, with STUN/TURN.

This combines benefits. Game state has all the authoritative-server advantages; voice has the low-latency P2P advantages. Each can use the right architecture.

When P2P makes sense for modern games

A few scenarios where P2P is still right:

Indie co-op games for 2-4 friends. Dedicated servers are expensive; P2P works for small parties.

Fighting games. Rollback netcode beats authoritative server for action.

Casual party games. Among Us, Fall Guys' early days. Low-stakes, small groups.

Some real-time strategy games. Where lockstep simulation is the natural pattern.

For most other modern games, authoritative server is the standard.

How this affects hosting

For a hosting company, the model determines:

Authoritative server games: lots of demand for dedicated server hosting. Server placement matters. Server scaling matters. This is most game hosting.

P2P games: hosting demand is less from the players (each game is a P2P match). The publisher may need infrastructure for matchmaking, voice relay, accounts, but not "the game state."

Relay-based games (SDR): the relay is provided by the publisher (Valve for Steam games). Hosting demand is minimal for the relay; some demand for backend services.

For game hosting providers, authoritative-server games are the bread and butter.

Cheating in each model

Authoritative server: harder to cheat in ways that affect game state. Common cheats (aimbot, walls) target client-side rendering, which is harder to fully prevent. Server-side validation catches some types but not all.

P2P with host: host can cheat freely if motivated. Other players can cheat too, depending on implementation.

Pure P2P: cheating is essentially unsolvable unless using deterministic lockstep with checksum verification.

Rollback: generally safer than non-rollback P2P because rollback exposes inconsistencies quickly.

Authoritative server is the default for "we care about fairness."

Performance characteristics

Authoritative server:

• Network: each player sends inputs (small) and receives state (larger). Server-side bandwidth scales with player count.
• Compute: server does all simulation. Server hardware matters.
• Latency: player-to-server, not player-to-player.

P2P with host:

• Network: host sends to all peers; peers send to host. Mesh-like.
• Compute: host does simulation.
• Latency: each peer's path to host.

Pure P2P:

• Network: all-to-all communication. Scales poorly past ~4 players.
• Compute: each peer runs its own simulation.
• Latency: worst case is the slowest pairwise path.

Architectural choices show up in performance limits. Authoritative server is the only model that scales well past small groups.

The future

A few trends:

Cloud gaming. GeForce Now, Xbox Cloud Gaming. The "client" is in the cloud; the actual local device is a thin client. Changes the latency math.

Geo-distributed authoritative servers. Modern services run regional servers and route players to the nearest. Hybrid centralization at the regional level.

Persistent worlds. MMOs continue to use authoritative servers, increasingly with cloud-native deployment.

Rollback for non-fighting games. Some research into rollback for racing games, FPS-style games. Limited adoption.

The dominant pattern (authoritative regional server) is likely to remain. The variations evolve at the edges.

Conclusion

Authoritative server vs P2P is the foundational architectural choice for multiplayer games. Each suits different game types:

• Authoritative server: competitive, persistent, cheat-sensitive, large-scale.
• P2P with host: casual co-op, small group, no dedicated infrastructure.
• Rollback P2P: fighting games and certain action subgenres.
• Pure P2P: rare in modern games.

For players: the model affects what cheating looks like, how downtime affects you, and how your ping relates to your experience.

For hosting: authoritative-server games drive most game-hosting demand. Other models have specialized needs.

For developers: choose carefully. The choice cascades through every other design decision.

Coming up

Next: cheating and how networks help (or don't) prevent it. The networking aspects of anti-cheat.