COMP 303 Software Development - Fall 2011: Milestone 2

Requirements

1. Game boards are currently created randomly, but this potentially results in boards that cannot be solved. Modify your game generation so only boards for which a solution exists are generated. Your design should allow for randomized generation of as wide a variety of initial boards as possible, and should work for (almost) any layout.
2. Add the ability to save and restore the current game state to the file-system. For this you need to add both the functionality to save/restore, as well as an appropriate user interface. Your design must be based on serialization.
3. Solitaire Mahjong can be made competitive by adding timing features, so players can compare their ability to complete the game in a given time limit:
   • Add a timer GUI component, which continuously displays the current amount of time the player has taken.
   • The timer should start once the first valid mouse-click is performed on the board of a new game.
   • The timer should stop once once the game is terminated, either through win, loss or restart.
   • A pause/continue interface should be added to the game interface, so a player can pause the timer and then continue it. While the timer is paused the game should not allow user actions other than quit, restart, save, or restore.
4. Add a hint mode:
   • Clicking the hint button should toggle hint mode on/off. The hint-state is persistent until toggled off, a game is loaded, or a new game is started.
   • In hint mode all tiles that have available matching pairs should be indicated in some fashion.
   • In hint mode all tiles where the entire group of 4 is available should be indicated in some (other) fashion.
5. Add an undo/redo facility:
   • Define an appropriate and obvious interface to let the player undo (and subsequently redo) tile-pair removals.
   • Undo and redo should be unbounded; that is, undo should allow tracing back to the board starting state, and redo should allow replaying undone moves in (reverse) order.
   • Undo/redo information should be contained within the game save files.
6. Add a high-score list:
   • When a player is one of the 10 fastest to win a game he or she should be given the opportunity to enter his or her name in a high score list.
   • High scores should not be recorded if the user has ever turned on hint mode, or used undo within the current game, or has loaded the game from a save file.
   • High scores should be separately maintained for each board layout.
   • High scores should be persistent (so restarting the application does not change high scores).
   • An in-game interface needs to be provided to display the current high scores for the current board layout.
7. All code must be well documented, including javadoc and internal comments as appropriate.
8. You must incorporate (extensive) unit testing into your project. All important game behaviour and all significant methods should have associated unit tests based on JUnit. All tests must be linked from a class named Milestone2Test.java to make it easy to run all of them as a single suite.

What to hand in

1. An exported project in a zip or tar.gz file. This must include all files necessary to build and run your project, as well as all javadoc output. Please include your group number in the archive filename.
2. A 1--2 page document describing your design. This should include components:
   1. a textual description of your strategy for building only solveable boards. Does your strategy allow you to generate all possible solveable boards (at least for, say, the turtle layout)? Give a convincing argument either way.
   2. an application state-diagram. There are now many buttons and options changing the state of your application. Show a state-diagram for your application (as a whole), adding states as appropriate with transitions to indicate how the state changes for each possible user interface action.
   3. a brief description of the specific contributions of each group member.
   4. Note: All documents should be provided using only common, OS-neutral format(s): pdf or ASCII text for textual documents, and pdf, png, gif, or jpg for images.

Evaluation

1. Code is well documented, clear and uniformly structured.
2. Code provides the functionality listed above.
3. Code is correct and does not exhibit bugs or other failures. Note we may apply tests of our devising (ie outside of your unit tests).
4. Code is well-designed following the principles discussed in class.
5. Unit tests provide extensive and relevant coverage of potential bugs and problems.
6. The document supplied includes all components, correctly and cleanly expressed.