Chapter 31. A Networked Two-Person GameChapter 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 actionThe 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:
|