As discussed in class, this week's lab is a team project. You should work with a partner. (Since there is an odd number of people in the class, there will have to be one group of three.) You, your partner, and I should all have access to a CVS repository. Create a new CVS repository in the home directory of one of the members of the team, and give access to me and to all teammates. To do this, for example,
mkdir cvs-cs225-lab9
fs setacl cvs-cs225-lab9 -acl eck all
fs setacl cvs-cs225-lab9 -acl yy8888 all
cvs -d /home/zz9999/cvs-cs225-lab9 init
where yy8888 should be replaced with your partner's user name and zz9999 should be replaced with your own user name.
One member of the team should create a lab9 project in Eclipse. Copy and paste the folder /classes/s11/cs225/netgame into the project. Then "Share" the project into the CVS repository that was just created. The other member or members of the team can then "Import" the project from CVS into their copy of Eclipse. To share your work after working on the project, you should "Commit" the project, and your teammates should "Update" their copies of the project. (See lab 5 for instructions.)
We will discuss in class whether this lab should be due next week, or whether it should be a two-week project.
We discussed the "netgame" framework in class yesterday. The classes that form the framework are in the package netgame.common. You will want to import netgame.common.* into the classes that you create for this project. Remember that the Hub class is used to create the server for a game. To create a client, you must write a subclass of the Client class. If your application uses a GameState, you also have to write a subclass of the GameState class. As for the Hub class, you can use it itself, rather than make a subclass. In addition to all that, you need classes to implement the user interface for your program.
Two sample netgame applications are provided, in the packages netgame.chat and netgame.tictactoe. You should try them out before starting any work on your own program.
During lab, a chat room server will be running on host eck.hws.edu. Connect to it and send some messages. To connect, run the program netgame.chat.ChatRoomWindow. You will be asked for your name. Then you will be asked for the host where the server is running. Enter eck.hws.edu as the host name. You should then be connected to the server, and you should be able to send messages and see messages sent by other people in the class.
If you want to run a chat room server on your computer, run the program netgame.chat.Main. This main program does not have a GUI; it just prints out some stuff on the console. This will create the Hub object that acts as the server for the chat room. To connect to the chat room, you need to know the host on which it is running. If you run ChatRoomWindow on the same machine as the server, you can use localhost for the host name. From another computer, you need to know the host name or IP address of the server machine. If you don't know it, you can run the program ShowMyNetwork, which will print your IP address (somewhere in the output...). A copy of of ShowMyNetwork.class is in /classes/s11/cs225; you can cd to that directory and run it there.
The chat room application demonstrates one way of writing netgame applications. It does not use a GameState object. Instead, it simply uses BroadcastMessage to send messages from the users. It does have a Client, which is always requried; the client class is defined as the nested subclass ChatClient inside the ChatRoomWindow class.
To try out the netgame.tictactoe game, each player should run netgame.tictactoe.Main. A dialog box will ask your name and whether you want to start a new game or join an existing one. The first player to run Main should start a new game. The second should join that game; to do so you must know the IP address or host name where the game has been created. Once you dismiss the dialog, the game board appears automatically, as soon as the connection has been made successfully
The TicTacToe application uses a GameState, defined in the class netgame.tictactoe.TicTacToeGameState. The instance variables in this class represent the entire state of a TicTacToe game. You should look at the applyMessage() method in that class, which is where the logic of the game is implemented. This method responds to messages of type StatusMessage, which are sent by the server when a player enters or leaves the game. It does this so that it can know when two players have connected, since the game cannot start until there are two players. The other messages come from TicTacToe clients. When a user makes a move, the client sends an array of type int[] containing the row and column numbers where the user clicked. After a game ends, when a user clicks the board, the client sends the string "newgame" as a message, as a signal to start a new game.
You will also want to take a look at netgame.tictactoe.TicTacToeWindow. The TicTacToe client is defined by a nested class inside this class. Note that the send() method of the Client object is used to send messages to the Hub (and hence to the GameState object on the hub). Note that messages are received by the client in its messageReceived() method. When a copy of the GameState is received as a message, the window redraws and reconfigures itself to correspond to the new state. In fact, this is the only type of message that is acted upon by the client.
The package netgame.checkers defines a standard non-networked checkers game. Your assignment is to make it into a networked game that works in much the same way as the TicTacToe example. (This program is a modified version of the example from Section 7.5 in the textbook. I have "refactored" the code to break up the single class from that example into multiple classes.)
You can use the Main program from the TicTacToe game, with only minor modification to make it work with Checkers instead of TicTacToe.
The CheckersData class pretty much contains the data that you need in a GameState object for the game. What it certainly does not contain is the ability to apply messages to the state. It can be made into a subclass of GameState.
The CheckersWindow class responds to user clicks on the board and on the buttons by making changes directly to the state. (These changes implement the "game logic.") Of course in the networked version, it shouldn't do that. In response to a user action, the window should simply send a message to the Hub, which will forward it to the game state object. The game logic, which changes the state of the game, should be carried out in the game state object.
You and your teammates should carefully lay out the "protocol" that you will use for network communication; that is, what messages can be sent, when they are sent, and what effect they will have. You will have to replace game logic in the CheckersWindow class with message-sending code, and move the game logic into the CheckersData class.
Recall that you will also need a subclass of netgame.common.Client to handle the network communication. You can define it as a nested class inside CheckersWindow (just as is done in TicTacToeWindow).