TicTacToe Game Design

Most of the networked game examples in this course are simple enough to read in one sitting. The two-player Poker program is different. It implements a two-player version of the traditional five card draw game, and the source material is explicit that the application is complex. Reading every line of it would be slow and would hide the bigger picture, so this article looks at the shape of the design instead: which parts exist, how they relate to one another, and what the two players actually do when they sit down to play.

The design is also a good example of a pattern you may already know. The two-player Poker program follows a design similar to TicTacToe, with a Main class run by both players. As you read, keep one question in mind: if you already understand how a simpler networked game is organized, which parts of that organization can you recognize here, and which parts are new?

Before looking at any class, start with the people using the program. Both players run the same Main class. Nothing in the setup treats one copy of the program as a server and the other as a client living in a separate codebase. The two players are distinguished by what they do, not by which program they run.

The first player starts a new game. The second player must join that existing game rather than creating a second one. The diagram below traces this order of events. It is an illustration built from the source's description, not a transcript of the program's actual code, so it shows the roles and their order rather than exact method calls.

The Poker program is built from three named parts. The Main class is the entry point that both players run. The PokerGameState class represents the state of a game. The PokerHub class is a subclass of Hub, and its job is to manage the game. The diagram below shows how these parts relate.

A useful way to separate responsibilities is to ask two questions about any piece of the program. Where does the information about the game live? And what keeps the game moving? PokerGameState answers the first question, because it represents the state of a game. PokerHub answers the second, because it manages the game. Main answers neither directly. It is the place where each player begins, so it is the connection between a person at a keyboard and the shared game.

The source names PokerHub as a subclass of Hub. This tells you that the Poker design builds on the netgame framework's existing Hub machinery instead of replacing it. The subclass relationship is the key idea: PokerHub inherits from Hub, and the Poker-specific behavior is what PokerHub adds on top of that foundation.

The two-player Poker program follows a design similar to TicTacToe, and the most visible shared feature is a Main class run by both players. This is the common thread that lets a reader carry knowledge from a simpler game into this one. The source states the resemblance at this level and does not list every point of comparison, so use the shared Main class as your anchor and check the rest of the design against it rather than assuming more correspondences than the source gives.

The difference the source does make explicit is scale. Most networked examples in the course are simple enough to read in one sitting, while Poker implements a complex two-player version of five card draw. The design shape is the part you can carry across; the game rules are the part that require familiarity with five card draw poker.