TicTacToe Game State Management

Imagine two people playing TicTacToe on two different computers, each looking at their own window. Both windows must show the same board, and both players must agree on whose turn it is. If one window showed an X in the top-left corner while the other showed an empty square, the game would stop being a game. This chapter asks one question: when a program is spread across several machines, where does the game's knowledge live, and how does every player come to see the same thing?

Before reading on, pause and consider a simple plan. The server holds the complete state of the game, and each time something changes, it sends that complete state to every connected player. Each player's screen then displays whatever it needs. This feels simple and symmetrical, and it works well for a game where nothing is hidden. TicTacToe is such a game, since both players can see the entire board at all times. Keep that plan in mind, because the rest of this article tests where it holds and where it breaks.

Notice that the state is more than the picture on the screen. The picture is something the program draws from the state. If the state says the board holds an O in the center and it is now X's turn, the window can be redrawn to show exactly that. The state is the underlying information; the window is one way of presenting it.

In a non-networked version of the game, all three of these values would live in instance variables inside one program. The program would consult those variables to decide how to draw the board and how to respond when a user clicks the mouse. Keeping the state in one place inside one program is simple. The difficulty begins when the pieces of the program no longer share a single memory.

The networked version of the game involves three objects. Two of them belong to a client class, and each provides the interface for one of the two players. The third is the hub object, which manages the connections to the clients. These objects are not on the same computer, so they cannot simply read and write the same instance variables. A client on one machine cannot reach into the variables of a client on another machine.

A player's action begins as a request, not as a change to the game. When a player places a piece on the board, that action is packaged as a message and sent to the hub. Only the hub decides what the action does to the state. The hub then updates the official state to reflect the result and sends the new state to both players. Each player's window is redrawn to match what the hub sent.

The diagram shows the flow in one direction at a time. Actions travel inward to the hub, and the state travels outward to both players. The hub does not change anything on its own; every change to the state begins with a player's action.

The design resolves the tension between separate machines by choosing one owner for the truth. The official game state is stored in the hub. Each player receives a copy of that state, and the copy is refreshed every time the state changes. The players never hold the authority to alter the state directly. A player's window is a copy the player looks at, and it is not the game itself.

The payoff is a guarantee stated in the source: because every view is rebuilt from the same official copy, the game always looks the same to both players. The clients are display-and-input devices, and the hub is the arbiter of what is true.

A tempting shortcut in a networked game is to let the hub send everything and rely on the client program to behave. In TicTacToe this worry is small, because both players are allowed to see the whole board. The same reasoning matters more in games with hidden information, where the client could simply choose not to show certain data. The source makes the key point: hiding information in the client is not sufficient, because a player can substitute their own client program to enable cheating.

The source concludes that the server must not give a player more than they should have. Preventing cheating depends on what data leaves the hub, not only on how the official client behaves. This is the reason the hub, not the client, decides what counts as an allowed change to the state.

Poker is more involved than TicTacToe, and its game state is correspondingly more involved. The important difference is not only how many values the state contains. Poker has information that belongs to one player and not to the others. A player's hand is private to that player, and the deck from which cards are dealt is not something players should be able to inspect. Once these facts are taken into account, the question of what to send over the network stops being a simple broadcast decision.

The full Poker game state, including each player's hand and the full deck, is known only to the PokerHub. A player never needs to hold the complete picture in order to play, and the design deliberately keeps it away from them. The PokerHub holds the one complete picture, while each player receives a limited picture shaped for that player alone.

When the state of a Poker game changes, the PokerHub does not send one object to everyone. It creates a separate PokerGameState object for each player, one representing the game from that player's point of view, and sends each object to the appropriate player. A PokerGameState represents the game from the point of view of one player, and each player receives only their own.

There is also a practical reason to avoid sending a fresh copy of the complete state after every minor change. Each update that carries the whole state repeats information that a player often does not need. The real need, however, is to decide what each player should receive, not merely to reduce traffic.

The source notes a design choice. Instead of sending a complete copy of the state each time it changes, the program could send only the change. That would reduce what travels over the network, but it would require a way to encode each change into a message that both ends can read. Someone would have to define that encoding and make both sides agree on it.

The author chose the simpler option: send the entire state as the message. The reasoning is specific to this game. The state of TicTacToe is small, consisting of a board, a turn, and an outcome, so resending all of it each time costs little and keeps the message format straightforward. A larger game with much more state would weigh the trade-off differently.