Networked Game Framework
The two-player Poker program follows a design similar to TicTacToe, with a Main class run by both players.
Why Poker Is a Bigger Step Up
Most 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. Rather than walking through every line, this article looks at the shape of the design: which parts exist, how they relate to one another, and what the two players actually do when they sit down to play.
Starting With the Two Players
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 in a separate codebase. Instead, the two players are distinguished by what they do. The first player starts a new game. The second player must join that existing game rather than creating a second one.
What do you think happens?
Both players run the same Main class. What decides which player is the one who starts the game?
Reveal answer
The order of actions: the first player starts a new game, and the second player joins that existing game. The two players are distinguished by what they do, not by having different programs.
Nothing in the design treats one copy of the program as a server and the other as a client in a separate codebase. The roles come from the actions each player takes.
The diagram below is an illustration built from the source's description, not a transcript of the program's actual code. The source does not spell out the exact sequence of method calls, so the steps show the order of roles and the parts involved, and nothing finer.
Read the diagram from top to bottom. The first player's copy of Main is the one that begins the game. The second player's copy of Main does not create a second game; it joins the one that already exists. Both copies are running the same program, so the difference between the two players lies entirely in the order and kind of their actions.
The Three Named Parts of the Design
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. Each part is taken up below, followed by a diagram of how they sit together.
How the Parts Fit Together
A useful way to separate responsibilities in this design 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. PokerHub answers the second. Main is where each player begins. The diagram below shows the relationships among these pieces, including the Hub class that PokerHub extends.
The diagram shows only the relationships the source states. The source does not say how Main is linked to PokerHub or PokerGameState, so the diagram leaves that link out rather than guessing it.
Why Poker Resembles TicTacToe
The source states that the two-player Poker program follows a design similar to TicTacToe, with a Main class run by both players. This is the common ground. Poker adds parts that go beyond that shared shape, most notably PokerGameState, PokerHub as a subclass of Hub, and the five card draw rules that the game implements.
| Aspect | Shared with TicTacToe design | New in the Poker design |
|---|---|---|
| Entry point | A Main class that both players run | Main is still the place each player begins |
| Roles | Players are distinguished by actions, not by separate codebases | The first player starts a new game and the second joins it |
| Game structure | A design similar to TicTacToe | PokerGameState represents state and PokerHub manages the game |
| Framework | Not stated in the source for TicTacToe | PokerHub is a subclass of Hub from the netgame framework |
| Game rules | Not stated in the source for TicTacToe | Implements a two-player five card draw game |
Shared and new elements of the Poker design. The source gives the TicTacToe similarity only at the level of a shared Main class run by both players, so the table does not claim more.
Going back to the question from the introduction: the Main-plus-two-players arrangement is the recognizable part, and the explicit split of state and management into PokerGameState and PokerHub, along with the Hub subclassing, is what is new in this program.
Finding the Full Source Code
The full source for the Poker program is in the package netgame.fivecarddraw. The source material is explicit that understanding it requires familiarity with five card draw poker. That is a prerequisite about the game's rules, not only about programming, so a learner who does not know the rules should learn them before reading the code closely.
- This is the package name given in the source; it is the location of the full Poker source.
- The package name itself does not show the class layout. Read the Main, PokerGameState, and PokerHub classes inside it.
Mistakes Learners Make With This Design
Common mistake Assuming one player runs a server and the other runs a client from a separate codebase
What it looks likeLooking for a second program or a separate client folder to explain the second player
Why it failsBoth players run the same Main class. Nothing in the setup separates the two into different codebases.
Do this insteadDistinguish the players by their actions: the first player starts a new game, and the second joins that existing game.
Common mistake Thinking the second player creates another game
What it looks likeAssuming each player's Main starts its own independent game
Why it failsThe second player must join the existing game rather than creating a second one.
Do this insteadTrace the join action back to the game the first player started.
Common mistake Treating PokerHub as the place the game information lives
What it looks likeLooking for the game's state inside PokerHub because it manages the game
Why it failsPokerGameState represents the state of a game. PokerHub manages it.
Do this insteadAsk where the information lives (PokerGameState) separately from what keeps the game moving (PokerHub).
Common mistake Filling in the Hub box with details the source does not give
What it looks likeDescribing exactly how Hub sends messages between players
Why it failsThe source does not describe the internals of Hub.
Do this insteadTreat Hub as a reminder that PokerHub is a subclass of it, and stop there unless you read the framework code.
Sorting Responsibilities Yourself
For each statement below, decide which of the three parts (Main, PokerGameState, or PokerHub) it best describes: (a) it is the place each player begins; (b) it represents the state of a game; (c) it is the part that manages the game. Then explain which of your answers came from a question about where information lives and which from a question about what keeps the game moving.
Hints
- Use the two-question test: where does the information about the game live, and what keeps the game moving?
- The first statement describes the entry point each player runs, so it is the connection between a person and the shared game.
Key Takeaways
- The two-player Poker program has three named parts: the Main class that both players run, the PokerGameState class that represents the game's state, and the PokerHub class, a subclass of Hub, that manages the game.
- The two players take different roles by their actions: the first player starts a new game, and the second player joins that existing game rather than creating another.
- The Poker design resembles the TicTacToe design in having a Main class run by both players, and it builds on the netgame framework's Hub machinery by subclassing Hub.
- The full Poker source code is in the package netgame.fivecarddraw, and reading it requires familiarity with five card draw poker.