The Networked Tic-Tac-Toe Game

Chapter 31. A Networked Two-Person Game

Chapter 30 described three versions of a chat system, built using a threaded client/server model, UDP multicasting, and HTTP tunneling with servlets. Chatting utilizes a multiplayer game model which allows players to join and leave at any time and doesn't impose an ordering on when the users interact.

This chapter focuses on the more complex networked two-person game model (two-person games include chess, battleships, and tic-tac-toe). The complexity is due to the stricter gaming conditions: two players must be present, and they must take turns. Two-person games can be generalized to n-person contests, which only start when n people are present, who each take turns to play. Most board games have this kind of structure.

The additional rules complicate the three phases of a game: initialization, game play, and termination. The game only starts when there are two players, which means that one player may have to wait, and late arrivals after two players have been found must be sent away or invited to create a new game. During the game, a player who moves out of turn may be penalized or ignored until the other player has moved. A game can terminate in several ways: one of the players may win (or lose), a player may give up, or the game can stop when one of the client network links breaks.

This complexity motivates the strategy used in this chapter: first, a standalone version of the game is designed, built, and debugged, and only then is the networked version considered. This allows issues such as game logic, 3D modeling, and GUI design to be addressed without the headaches of networking.

Once the network phase is entered, utilizing design tools is useful before sitting down to hack. I use three diagramming tools here: informal network protocol diagrams, UML activity, and sequence diagrams. The protocol diagrams highlight the network interactions between the clients, focusing on the three game phases (initialization, game play, and termination). The activity and sequence diagrams allow me to trace turn-taking easily from one player, through the server, to the other player.

The implementation employs a threaded client/server model: each client has a thread to send messages to the server (e.g., details of the player's turn) and another to receive data from the server (e.g., information about the other player). The server is threaded as well: one thread for each client. These networking elements are similar to those used in the threaded client/server chat system in Chapter 30, allowing me to reuse a lot of the code.

The clients are fat in the sense that they do most of the game processing; the server is little more than a message forwarder. An important advantage of the fat client approach is that most of the GUI and game play code developed in the standalone version of the game can be carried over to the client in the networked version without modification.

This chapter utilizes the perennial favorite of two-person gaming, tic-tac-toe, but with a Java 3D makeover to display the board and player counters as 3D objects. I'll assume you know Java 3D.

The standalone FourByFour tic-tac-toe game is shown in Figure 31-1 (the network version looks similar and is shown in Figure 31-11). Player 1's markers are red spheres; player 2 has blue cubes. The aim is to create a line of four markers, all of the same type, along the x-, y-, or z-axes, or the diagonals across the XY, XZ, or YZ planes or from corner to corner.

Figure 31-1. FourByFour in action

The nonnetworked FourByFour game described in the first part of this chapter is a simplified version of a game available in the Java 3D distribution. The main elements are:

Parallel projection

The poles and markers at the back of the scene are the same size as the ones at the front. Up to now, all my examples have used Java 3D's default perspective projection.

Marker caching

Red and blue markers are created for all the possible game positions (64 total) at game startup time and are made invisible. When a marker is needed in a certain position, the relevant one only has to be made visible, which is a fast operation for Java 3D. The alternative is to create the required marker dynamically at runtime and attach it to the scene graph, which is much slower. The disadvantage is that the markers take time to be built, and many will never be used but the overhead is small.

The markers are hidden by using Java 3D Switch nodes.

Marker labels

Any Java 3D scene graph object can be assigned a user data reference, which can point to an arbitrary object. This allows scene graph nodes to store user-specific data. I employ this feature to label the game markers, which identifies them to the rest of the program.

User interaction

Java 3D picking is used to allow a player to select a position by clicking with the mouse, and to rotate the game board via mouse dragging. In the networked version, the Java 3D Canvas3D class is extended to support overlaying (see Figure 31-11). This allows the program to write messages onto the screen without the overhead of creating 3D data structures.

The standalone version of the game is in the directory FourByFour/; the networked version is in NetFourByFour/.