4003-543-01/4005-742-01 Ad Hoc Networks Programming Project 2 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 Design Hints 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. The program supports multiple game sessions and secure game sessions. 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. There can be multiple sessions of Take 4 going on simultaneously. The user can pick which session to join, or start a new session. Each session may be open or secure. Anyone can join and play in an open session. Only those possessing the correct password can join and play in a secure session. A session is uniquely identified by the session name (a non-empty String). When the Take 4 application starts up, it displays a session selection dialog with the following items: A list of the Take 4 sessions that are out there. The list shows the name of each session and indicates whether each session is open or secure. The user can click on a session in the list to select that session. A "Join" button to join an existing session. This button is enabled if the user has selected a session in the session list. A text box labeled "Password:" for entering a session password. When the user types in this box, the actual characters are not displayed, just a mark for each character typed. A text box labeled "Session Name:" for entering a session name. A "New" button to create a new session. This button is enabled if the user has typed a name in the session name box. A "Quit" button. This button is always enabled. (Note: The exact appearance and layout of the session selection dialog are up to you.) The session list is continually updated. If a device arrives that is playing a Take 4 session whose name is not in the session list, the session is added to the session list. If the last device departs that is playing a certain Take 4 session, the session is removed from the session list. If the user clicks the "Quit" button, the Take 4 application closes the session selection dialog and exits. If the user selects a session in the session list and clicks the "Join" button, and the session is an open session, the Take 4 application proceeds to play in that session. The session name box and password box are ignored. If the user selects a session in the session list and clicks the "Join" button, and the session is a secure session, the Take 4 application verifies the password the user entered in the password box. The session name box is ignored. If the password is correct, the Take 4 application proceeds to play in that session. If the password is not correct, the Take 4 application displays a dialog with an error message and an "OK" button; when the user clicks the "OK" button, the Take 4 application returns to the original session selection dialog. If the user types a name in the session name box and clicks the "New" button, and the name in the session name box is equal to one of the names in the session list, the Take 4 application displays a dialog with an error message and an "OK" button; when the user clicks the "OK" button, the Take 4 application returns to the original session selection dialog. If the user types a name in the session name box and clicks the "New" button, and the password box is empty, the Take 4 application creates a new, open session with the given name. Then the Take 4 application proceeds to play in that session. If the user types a password in the password box, types a name in the session name box, and clicks the "New" button, the Take 4 application creates a new, secure session with the given name and password. Then the Take 4 application proceeds to play in that session. When creating a new session, the Take 4 application assumes that no other user is creating another session with the same name at the same time, and the Take 4 application assumes that no other device will arrive that is playing a Take 4 session with the same name. In other words, the Take 4 application ignores these potential race conditions. Once the user has chosen a new or existing game session, the Take 4 application closes the session selection dialog and displays this UI for playing the game: The title bar shows the session name and the player's name. If the application starts up and no other nearby devices are running the chosen Take 4 session, the board is initially empty. If the application starts up and one or more nearby devices are running the chosen Take 4 session, 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 session 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 session. When the last player's application terminates, the game session vanishes. In an open game session, any player is able to participate fully in the game. In a secure game session, an intruder lacking the password is not able to discover the board configuration, is not able to monitor the moves, is not able to mark or unmark squares, and is not able to clear the board. Furthermore, in a secure game session, an intruder lacking the password is not able to discover the password by monitoring the network traffic. 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 game playing 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   Warning: Even though I have provided some of the code, it is your responsibility to make sure your project correctly implements all the requirements.   The game application must behave as described in The Ad Hoc Collaborative Multiplayer Game section above.   Note: I have not provided code for the session selection dialog. The exact appearance and layout of the session selection dialog are up to you.   When two instances of a game session merge -- for example, when a device running a game session moves into range of another device running the same game session -- the state of the game session must become that of the game session that started least recently, according to the system clock time.   When two instances of a game session merge and both instances started at the identical time, the state of the game session must become that of the game session that has experienced more moves, where a move is either marking a square, unmarking a square, or clearing the board.   When two instances of a game session merge and both instances started at the identical time and both instances have experienced the identical number of moves, the state of the game session 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.) Design Hints To implement the secure game sessions, use the Tuple Board's existing security features. See package edu.rit.tb.security and class FixedHelixSecurityContext. Use the game session password as the key for the security context object. 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, May 8, 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. Ad Hoc Networks • 4003-543-01/4005-742-01 • Spring Quarter 2007 Course Page Alan Kaminsky • Department of Computer Science • Rochester Institute of Technology • 4486 + 2220 = 6706 Home Page Copyright © 2007 Alan Kaminsky. All rights reserved. Last updated 16-Apr-2007. Please send comments to ark­@­cs.rit.edu.