Server Authoritative Board Game: What Belongs

Updated 5 November 2026 · Standard formula, shown below

A server authoritative board game is one where the server holds the single source of truth for all game state, and clients only send inputs and render results. This means the server owns the board, the pieces, the turn order, the rules, and the random number generator, while clients are essentially “dumb terminals” that display what the server tells them. This architecture is the standard for competitive multiplayer games because it prevents cheating and keeps every player’s view consistent.

Background: Why Server Authority Exists

Board games are fundamentally about trust. In a physical game, the rules are enforced by the players themselves, but online, you can’t trust anyone. A player could modify their client to see hidden information, roll dice in their favor, or move pieces illegally. Server authority solves this by removing all trust from the client. The server is the referee, and it never lies. This is especially critical for games with hidden information (like poker or Battleship) or where the outcome depends on a random event (like rolling dice or drawing cards). Without server authority, a single malicious client could ruin the game for everyone.

Core Components: What the Server Must Own

To be truly server authoritative, a board game server must control several key elements. If any of these are left to the client, the integrity of the game is compromised.

Game State: The complete state of the board, including piece positions, player hands, scores, and whose turn it is. This is the absolute minimum.
Random Number Generation (RNG): All dice rolls, card shuffles, and any other random events must be generated on the server. The server should also use a cryptographically secure random number generator, not the standard Math.random() which can be predicted.
Rule Validation: The server must validate every move against the game’s rules before accepting it. This includes not only legal moves (e.g., a knight moves in an L-shape) but also whether it’s the player’s turn and whether they have the resources to make the move.
Hidden Information: Any information that should be hidden from players (e.g., the opponent’s hand, the next card in the deck) must be stored on the server and only revealed to the client when appropriate.
Timers: If the game has turn timers or a game clock, the server must be the authority on time. Clients can’t be trusted to report when they started their turn.

How It Works: The Client-Server Dance

The interaction between client and server follows a strict pattern. The client is the player’s “hand” and the server is the “brain”.

Client Sends Intent: The player clicks a space to move a piece. The client sends a message to the server: “I want to move my pawn from A1 to A2.”
Server Validates: The server checks the request. Is it the player’s turn? Is the move legal? Does the player have the required resources?
Server Updates State: If valid, the server updates its internal game state. If invalid, it sends an error message back to the client.
Server Broadcasts: The server sends the new, authoritative game state (or just the changes) to all connected clients.
Client Renders: The client receives the new state and renders it on screen. It does not make any decisions on its own.

This pattern is often called a lockstep or snapshot model. In a lockstep model, all clients must confirm they are ready before the server advances the simulation. In a snapshot model, the server sends the full state at a regular interval. For board games, a snapshot model is usually simpler and more robust, since the state changes are infrequent.

Common Problems and Misconceptions

One common misconception is that server authority means the server must simulate the entire game in real-time. This is not true. Board games are turn-based, so the server can be event-driven, only processing actions when they are received. This is much less demanding than a real-time game.

Another problem is desync, where the client’s view of the game differs from the server’s. This can happen due to network lag or bugs. A good server will periodically send a full state snapshot to clients to correct any drift. Clients should also be able to request a full state resync if they detect an inconsistency.

A third issue is reconnection. If a player disconnects, the server must be able to hold their state and allow them to reconnect and resume. This is much easier with server authority because the server has the full state, so the client can simply download it again on reconnect.

How to Choose: Architecture Patterns

There are two main architectural patterns for server authoritative board games: thin server and thick server.

Thin Server: The server only validates moves and maintains the game state. The client is responsible for all game logic, such as determining legal moves, computing scores, and rendering. This is easier to implement but requires the client to be trusted with the rules, which can be exploited.
Thick Server: The server contains all game logic, including rules, AI, and scoring. The client is purely a view. This is more secure and consistent, but requires more server-side development and can be more complex to maintain. For any competitive or ranked game, a thick server is the correct choice.

For a serious board game, you should always use a thick server. The extra development effort is worth the security and consistency it provides.

Costs and Performance Considerations

Running a server authoritative game costs money. You need a server that can handle the number of concurrent games you expect. For a turn-based game, the load is low, but you still need to pay for hosting, bandwidth, and potentially a database. The cost scales with the number of players and the frequency of moves.

Performance is rarely a bottleneck for board games. The main concern is latency, not throughput. A player should not have to wait more than a few hundred milliseconds for their move to be validated. This is easily achievable with a well-placed server. The bigger cost is development time, as server authority is more complex to implement than a simple peer-to-peer or client-authoritative model.

Alternatives to Server Authority

Server authority is not the only way to build a multiplayer board game. The main alternatives are:

Peer-to-Peer (P2P): Players connect directly to each other. This is cheap to run (no server costs) but requires one player to be the “host” and is vulnerable to cheating. It also has issues with NAT traversal and reconnection.
Client Authority: One client is the authority. This is essentially P2P with a designated host. It’s easy to implement but has the same cheating problems.
Deterministic Lockstep: All clients run the same simulation and exchange only inputs. This is used in real-time strategy games. It’s very efficient but requires perfect synchronization and is extremely difficult to implement correctly for a board game with complex rules and hidden information.

For a board game, server authority is almost always the best choice because it offers the best balance of security, consistency, and development complexity.

Frequently Asked Questions

Can I use WebSockets for a server authoritative board game?

Yes, WebSockets are an excellent choice. They provide a persistent, full-duplex communication channel between the client and server, which is perfect for sending moves and receiving state updates. They are well-supported in all modern browsers and most game engines.

How do I handle hidden information like a deck of cards?

The server must keep the deck order and the cards in each player’s hand. When a player draws a card, the server sends the card’s data to that player only. The server must also ensure that no other client receives information about that card. This is straightforward with server authority, as the server controls all data.

What if a player disconnects mid-game?

The server should keep the player’s state and allow them to reconnect. When they reconnect, the server sends them a full state snapshot so they can resume. If the player doesn’t reconnect within a timeout, the server can forfeit them or replace them with an AI.

Is server authority overkill for a casual game with friends?

It depends. If you’re playing with friends you trust, a simpler P2P model might be fine. But if you want to prevent accidental desyncs or allow for easy reconnection, server authority is still a good idea. It also makes it easier to add features like matchmaking or ranked play later.

Do I need a database to store game state?

Not necessarily. For a live game, you can keep the state in memory on the server. A database is only needed if you want to save games for later resumption or for analytics. For most board games, in-memory state is sufficient.

How do I prevent players from seeing the opponent’s hand?

The server simply never sends that information to the client. The client only receives the data it needs to render the game. This is the core principle of server authority: the client is not trusted with any information it shouldn’t have.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.