Client and Server Roles in a Networked Game

When people first build a networked card game, they often reach for the simplest design. They keep one complete record of the game and send that record to everyone after each move. For games where every piece of information is open to every participant, this works well. Poker is different. A player is not allowed to know everything about the game during play, so the simple design needs to be questioned before it is used.

Before reading on, pause and ask yourself a question: if the server sent the same complete game record to both players, what could each player learn that they should not know? The rest of this article answers that question and shows how the Poker application avoids the problem. The central idea is that the full game state and the information a player may see are kept separate, and that the server, not the client, decides what each player receives.

The Poker application is organized around two kinds of components. The PokerHub holds the full game state, and it is the only component that knows everything about the game. The players are clients. Each player receives information through a different kind of object, called a PokerGameState. Each PokerGameState describes the game only from the point of view of one particular player.

The process is triggered by change. When the state of the game changes, the PokerHub does not update one shared record and broadcast it. Instead, it builds two different PokerGameState objects, one for each player's point of view, and sends each object to the player it was built for. Follow one change through the diagram below. The hub starts from the full state, and each player ends up with only the view prepared for them.

The figure summarizes the flow as a rule. One change produces two objects, and each object goes to exactly one player. Neither player receives the other player's object, and neither player receives the hub's complete record. The diagram is a summary only: the text above is what explains why the separation exists.

The simple design merges two ideas that the Poker application keeps apart: the complete record of the game, and the copy that gets sent over the network. Once they are merged, the server sends a single object to everyone, and that object has to be the same for everyone. Poker shows why this is a problem. The source identifies two separate problems that follow from it.

A useful way to check your understanding is to ask, for any piece of information in the game, who should be able to see it. For the two hidden items the source names, the answer is the PokerHub alone: the opponent's cards and the complete order of the deck. The figure below separates the full state, which only the hub holds, from the PokerGameState objects, each of which describes the game from one player's view.

The diagram is a map, not a complete list. The source names the deck order and the opponent's cards as the information that must stay hidden, and it states that each player receives only their own view. It does not give a full inventory of every other item in the game, so when you apply the question to a new piece of information, reason from the same principle: it belongs to the hub unless the player is allowed to know it.

A reasonable first thought is that the client program can simply hide the sensitive information from the screen. The source explains why this is not enough. A client program is software that the player controls. A player who writes a substitute client can read the hidden information directly, whatever the original client chooses to display.

Now trace one full round of communication. The player's action is the change that starts the process. The hub then updates the full state and produces one PokerGameState for each player. Each object is sent to its own player. The sequence below shows which party sends or receives each message, and in what order.

Read the sequence carefully. Only the hub produces state objects, and each client receives only the object that was built for it. Player B does not send anything to Player A in this flow, and Player A's object never reaches Player B. The hub's update is the step where the full state is used to build the two views, so it is the only place where the complete record is read.

The table below contrasts the two designs directly. In the first, the hub sends the same full state to everyone. In the second, which is the one the Poker application uses, the hub sends a tailored object to each player. Keep the efficiency problem and the information problem in mind as you read each row.