CSE143 Winter 2003

Project 5

The Game of Floaters!

Due dates: Partner declaration special turn-in form, deadline Friday afternoon, February 28.  Not optional!  Everyone must do this turn-in whether they are working with a partner or not.  After that deadline, you may not "marry" or "divorce" a partner.  Progress Report electronic turn-in Thursday night; receipts next day (sorry, this wasn't at all clear).

Code due electronically Sunday evening, March 9.  Only one person per team should turn in the files.  No, it doesn't matter which one.  Receipt and/or program printouts due at grading appointment; any other remaining written parts due Monday, March 10, in class.  Grading appointments will be scheduled starting Monday, March 10. (details in quiz section).  Both partners must show up, in person, on time, or the project will not be graded.  

User Evaluation Form and instructions now available.  Conduct the experiment any time after your program is completed; turn-in (hardcopy only) Thursday, March 13 in class.

Overview

The game you create must be a recognizeable descendant of Floaters.  You can't, for example, take a Java version of Minesweeper you wrote or found on the Internet and turn it it.

The game should be playable.  A computer-savvy person should be able figure out how to play the game without you standing there explaining what to do (someone might have to start the Java program for them).

The class with the main method must be named PlayGame.java.  No command line input should be required for the game to be played, but you could define command arguments for some optional purpose if desired.

Starting Code

The code directory above includes a new utility file, Vector.java, which encapsulates a math/physics two-dimensional vector (as opposed to a Java collection Vector).  Feel free to use it, or any previously supplied CSE143 utility classes or solution.

Any .java files you use must be turned in.

Review the course and departmental guidelines for use of work not your own.  In particular, any scrap of code you didn't originate yourself (or that isn't CSE143-supplied) must be acknowledged.

Written part

1. Turn in two more more screen snapshots showing your program at some typical or interesting point of its operation. 
2. Draw a class hierarchy chart which includes all classes (and yes, interfaces) mentioned by name in the code you turn in.
3. Conduct and write up a usability experiment.  This will consist of recruiting a couple of volunteers who will play the game, without coaching by you, as you take notes.  Details later. Separate due date.
4. Instead of turning in the printed turn-in receipt on the usual day of written turn-in, bring it to the scheduled grading appointment.  If the receipt does not show all of the code you turned in, print out any missing code to bring to the grading session. 

Some rules:

The code should follow all the usual rules of good programming practice, as we understand it from this class.   This includes (but is not limited to): class design and relationships; style and commenting; programming by contract practices;  error detection and handling; MVC design.

There are no specific requirements on what data structures or algorithms you choose.   Still, your choices should be appropriate, with proper attention to structure and efficiency, and this will be considered in grading.

Some advice: The usual.  Plus:

Don't get too carried away by the visual and GUI aspects of the game.  This can quickly get very detail-oriented as well as error-prone. 

Buona Fortuna!

Hints, Tips, and Corrections