4003-543-01/4005-742-01 Ad Hoc Networks
Programming Project 1
Prof. Alan Kaminsky -- Spring Quarter 2006
Rochester Institute of Technology -- Department of Computer Science
Overview
Take 4
The Ad Hoc Collaborative Multiplayer Game
Software Requirements
Submission Requirements
Grading Criteria
Late Projects
Plagiarism
Overview
Write a Java program for a serverless ad hoc collaborative multiplayer game, Take 4. The program uses the Tuple Board (TB) middleware.
Take 4
I can't remember where I heard of this game or what its "official" name might be. I call it "Take 4." If anyone has any information about the game, I'd appreciate hearing it.
Take 4 is played on an 8-by-8 board. Any number of players can play. Starting from an empty board, the players take turns placing a marker on an open square. If, after placing a marker, there are four markers in a row horizontally, vertically, or diagonally, the player who placed the marker wins the game. The board above is showing a winning combination with four in a row diagonally.
Note that, unlike Tic-Tac-Toe, all the markers in Take 4 are the same color. You don't have to get four in a row of your own color, you just have to get four in a row.
The Ad Hoc Collaborative Multiplayer Game
You will develop an ad hoc collaborative application to let any number of players play Take 4 on their wireless mobile computing devices. There will be no central server; rather, the application will use the TB middleware. All devices in the proximal wireless network will be able to participate in the game.
The game application's UI looks like this:
The title bar shows the player's name. If the application starts up and no other nearby devices are running Take 4, the board is initially empty. If the application starts up and one or more nearby devices are running Take 4, the application syncs up with the other devices and displays the current board configuration.
Clicking on an empty square marks the square. Clicking on a marked square unmarks the square. Clicking on the "Clear" button clears all marks off the board. All the running applications display the new state of the board whenever any player clicks anything.
When a player marks an empty square, all the applications display the message "<name> moved" in the text box at the lower right, where <name> is replaced with the player's name. When a player marks an empty square and puts the board into a winning configuration, all the applications display "<name> wins!" instead. When a player unmarks a marked square, all the applications display "<name> removed a mark". When a player clears the board, all the applications display "<name> cleared the board".
Any player may mark or unmark any square at any time. Any player may clear the board at any time. The application does not force the players to take turns, nor does the application prevent clearing the board before the game is over. Like a game played without computers, it is up to the players to behave themselves.
A player can watch the game simply by starting the application and never taking a turn. The application will display all the moves the other players make.
A player can terminate the application by closing the UI window. This terminates the application only for that one player. However, any remaining players can continue playing the game. When the last player's application terminates, the game vanishes.
Software Requirements
-
The game application must be written in Java using TB.
-
The game must be an ad hoc collaborative application
without a central server.
-
The game application must be run by typing this command line:
java Take4 <name>
where <name> is the name of the player.
Note: This means that the program's class must be named Take4, and this class must not be in a package.
-
If there are any of the following problems
with the command line arguments,
the program must print a meaningful error message on the standard error
and must terminate.
(The wording of the error message is up to you.)
- The player name argument is missing.
- There are too many arguments.
-
The game application must use the following classes for its UI.
You may download and compile these Java source files
into your project.
- Class BoardUI -- BoardUI.java
- Class Take4UI -- Take4UI.java
- Interface Take4UIListener -- Take4UIListener.java
-
The game application must use the following class
to represent the board position.
You may download this incomplete Java source file,
finish writing the class,
and compile it into your project.
- Class Position -- Position.java
- Class Position -- Position.java
-
The game application must behave as described in
The Ad Hoc Collaborative Multiplayer Game
section above.
-
When two instances of the game application merge --
for example, when a device running the game application
moves into range of another device running the game application --
the state of the game must become
that of the game application that started least recently,
according to the system clock time.
-
When two instances of the game application merge
and both instances started at the identical time,
the state of the game must become
that of the game application
that has experienced more moves,
where a move is either marking a square,
unmarking a square, or clearing the board.
- When two instances of the game application merge and both instances started at the identical time and both instances have experienced the identical number of moves, the state of the game must become the union of the two instances. (That is, any square that is marked in either or both of the two instances is marked in the union.)
Submission Requirements
Your project submission will consist of a Java archive (JAR) file containing all the Java source files for your project, including the UI and board position classes and interfaces.
-
Each Java source file name must end in ".java".
-
Each class or interface
must include a Javadoc comment
describing the overall class or interface.
- Each method within each class or interface must include a Javadoc comment describing the overall method, the arguments if any, the return value if any, and the exceptions thrown if any.
See my Java source files which we studied in class for the style of Javadoc comments I'm looking for.
Put all the source files into a JAR file named "<username>.jar", replacing <username> with the user name from your Computer Science Department account. The command is:
jar cvf <username>.jar *.java
Send your JAR file to me by email at ark@cs.rit.edu. Include your full name and your computer account name in the email message, and include the JAR file as an attachment.
When I get your email message, I will extract the contents of your JAR file into a directory. I will set my Java class path to include the following directories: the directory where I extracted your files, the Tuple Board Library directory, and the Computer Science Course Library directory. I will compile all the Java source files in your submission using the JDK 1.5.0 compiler. I will then send you a reply message acknowledging I received your project and stating whether I was able to compile all the source files. If you have not received a reply within one business day (i.e., not counting weekends), please contact me. Your project is not successfully submitted until I have sent you an acknowledgment stating I was able to compile all the source files.
The submission deadline is Tuesday, April 10, 2007 at 11:59pm. The date/time at which your email message arrives in my inbox (not the time when I actually read the message, which will be some time later than when it arrives in my inbox) will determine whether your project meets the deadline.
You may submit your project multiple times before the deadline. I will keep and grade only your most recent successful submission.
If you submit your project before the deadline, but I do not accept it (e.g. I can't compile all the source files), and you cannot or do not submit your project again before the deadline, the project will be late (see below). I strongly advise you to submit the project several days before the deadline, so there will be time to deal with any problems that may arise in the submission process.
Grading Criteria
50% of your project grade will be based on the design of your project as documented in the Javadoc and as implemented in the source code. Your project should:
- Be designed using object oriented design principles.
- Make use of reusable software components where appropriate.
- Be documented using proper Javadoc style as described above.
- Follow the ad hoc collaborative application design patterns studied in class.
40% of your project grade will be based on a test run of your project in multiple processes on a single computer; that is, a simulation of a proximal ad hoc network. The grade for this portion will be based on whether your project correctly implements the Software Requirements. Every incorrectly implemented requirement will result in a loss of points. There is one exception: If your application does not run using the command line stated in Requirement 3, you will receive 0 points for this portion of your grade.
10% of your project grade will be based on a test run of your project on multiple computers over an actual proximal ad hoc wireless network. The grade for this portion will be based on whether your project can play the game successfully in the real ad hoc network environment. There is one exception: If your application does not run using the command line stated in Requirement 3, you will receive 0 points for this portion of your grade.
Any deviation from the requirements will result in loss of points. This includes errors in the output formatting (such as incorrect number of spaces, incorrect capitalization, or incorrect punctuation), misspelled output, and extraneous output not called for in the requirements. The requirements state exactly what the output is supposed to be, and there is no excuse for outputting anything different. If any requirement is unclear, please ask for clarification.
After grading your project I will put your grade and any comments I have in your encrypted grade file. For further information, see the Course Grading and Policies and the Encrypted Grades.
Late Projects
I will not accept a late project unless you arrange with me for an extension. See the Course Policies for my policy on extensions. Late projects will receive a grade of zero.
Plagiarism
The project must be entirely your own work. See the Course Policies for my policy on plagiarism.
| Course Page |
| Home Page |