TicTacToe Game State in a Networked Game

When people first build a networked card game, they often choose the simplest design available: keep one complete record of the game, and send that record to everyone after each move. For games where all information is open to every participant, this design works well. The question this article answers is whether the same design still makes sense for Poker, and the source's answer is no. The reason lies in what a player is allowed to know.

The source's example is Poker. The chapter's simpler games, which the source refers to, have information that every participant can see, so one shared record fits them. Poker is considerably more complicated, and its game state grows in step with that complexity. Keep that contrast in mind as you read: the question is not whether a shared record is convenient, but who is allowed to see which part of it.

This design creates two separate problems in a networked Poker game. The first problem is efficiency. It is not obvious that the hub should send a brand new copy of the whole state to every player each time a small change happens, such as one bet being placed. Most of that copy would be unchanged, so the players would receive far more data than they need to update their screens.

The second problem is information, and it is the more serious of the two. A full copy of the game state would reveal the opponent's cards and the complete order of the deck. A player should not be able to see either of these during play. The efficiency problem makes the design wasteful, but the information problem makes it incorrect, because the design gives players knowledge they must not have.

A reasonable first thought is that the client program can simply hide the sensitive information from the screen. The player's client would receive everything, but it would only display what the player is meant to see. The source explains why this is not enough. A client program is software the player controls. A player who writes a substitute client can read the hidden information directly, because nothing stops that substitute from displaying data that the official client hides.

The lesson that follows is that security has to come from what the server sends, not from what the client chooses to display. This is the reason the Poker design changes what is sent, rather than relying on the client to filter it.

The Poker application solves both problems by separating two ideas that the simpler design merged together. The full game state is kept in exactly one place, the PokerHub. The PokerHub is the only component that knows everything about the game. Everything a player is allowed to know is delivered through a different kind of object, called a PokerGameState. Each PokerGameState describes the game only from the perspective of one particular player.

The two parts of this split are easier to understand when you look at each one separately. The first part is what the hub keeps. The second part is what a single player receives.

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 then sends each object to the player it was built for. Before reading the figure, try to predict the number of objects the hub builds for a single change.

Read the diagram as a rule. One change produces two objects, and each object goes to exactly one player. The hub is the only place where the full state exists, and the arrows that leave it carry only the per-player views.