COS386 -- Rush Hour Project

General Description

The RushHour project consists of a multi-player network game that is a simplified version of Chinese Checkers. The game server will be written in Perl, whereas the game client will be written in Java. The game will (ideally) support from 1 to 4 players. If there is only 1 player, the opponent will be the game server (which is not allowed to cheat!). (Realistically, we will only have time to make this a two person game.)

The game board will be an 8 by 8 grid (a standard chess board) with no significant color distinctions among the 64 squares. (You may add color variation for esthetic reasons, but they are not required.) Each player will be given 6 markers (of a color that is unique to the player). The markers will be initially lined up on one edge (excluding the corner squares). The goal is to move all 6 markers to the opposite edge. Only single horizontal or vertical moves are allowed. It is permissible to move backwards, but you cannot move into an occupied square. You may assume that jumps and diagonal moves are not allowed.

It should be possible for other people to register with the server as observers. The server should send them details of the game as it progresses, but observers will not interact with the game in any other way. (This detail should not be implemented until the two player game is working properly.)

The Server

The server must maintain the list of waiting or active players as well as the list of observers. It must also keep track of the game board, whose turn it is, and check the legality of moves. The server must also notify all players and observers of changes in the game board. The server should declare a winner when that event occurs. All current players and observers will then be gracefully terminated.

The Client

The client program will need to provide facilities for a player to contact the server and request game service. It must also maintain a visual representation of the board and handle player input when a player's turn is active.

When a game terminates, the client must clearly indicate this and clear up any game artifacts. However, the application (or applet) must not terminate. The player should have the option of re-connecting the game server for more service.

Protocols

You may implement negotiations prior to an active game with either UDP or TCP. An active game will be run via TCP. Both the server and client must monitor the connection and take appropriate action if it is prematurely terminated.

What you should submit

You should create a tar file containing all your code. The tar file should be named according to the names of your team members. Place it in the feedme directory in the class account on helios.
The Perl code should have an extensive pod comment (as well as suitable internal comments for segments of code).
The Java code should have fully developed javadoc comments (and possibly other comments internally). Publish the javadocs on the web and email the url of tree.html.
Hand in complete program listings.
Hand in a record of the unit and integration testing you have done.

Point Breakdown

Javadoc and POD: 10%
Unit and integration testing: 15%
Proper use of sockets: 15%
User interface: 15%
Robustness: 20%
Working system: 20%
More than 2 players: 5%

Example

The screen grabs that follow may give a better sense of what the final product will look like.

The control window

The first image shows a sample control window. The player (Xue Bao-chai) has entered her name, chosen a two-player game and then connected to the game server. Since Lin Dai-yu contacted the server first and requested a three-player game, the server ignored the two-player request and added Miss Xue as the third player.

A game in progress

The next image shows a game that is in progress. It is currently Miss Lin's turn. She has placed the mouse on the marker she wishes to move. That square has been painted red. As she drags the mouse to another square, the new square will become red. If she releases the mouse button over a legal square, her marker will be moved. The server will also update the game boards for the other players.

Sample error messages

The control window displays messages from the server, including a reminder of whose turn it is, the successful completion of a game, and error messages. The image shows several messages related to Master Bao's attempts to cheat. The server would also notify him if he attempts to move when it is not his turn.

The system should be robust. This is partially related to the refusal to let a player cheat. Even more, the server should gracefully handle other non-standard events. For example, it is very likely that part way through the game, Lin Dai-yu will burst into tears and prematurely shut down her game client. The next time the server sends an update message over the socket that used to be connected to her client, a socket error will occur. The server should not crash. One possible action would be to gracefully terminate the game on the remaining clients and let Jia Bao-yu and Xue Bao-chai re-connect for a two-person game.

The Results

Almost every project team had a game working. Many had implemented multiple players and even observers. Some had implemented "chat" facilities for the players to write messages to each other.

The most elaborate user interface

Phil Nelson and Kevin Rask (seniors) produced a very realistic game board:

Phil and Kevin's game board

Last updated 5-22-1999
Questions or comments may be sent to gossett@bethel.edu.