There will be done in two groups of five each. It is a full-group effort, which means that the five of you will work on a single implementation. Other than your responses to the concurrency-related questions (below), you will turn in a single deliverable for all of you. That is going to impose some interesting challenges in project management, and you will probably struggle with trying to keep a single, consistent code base. Get to know and use SVN (or Git, if you must).
The Fifteen-puzzle, a classic toy of the late 19th-century, consists of a 4x4 frame, holding fifteen numbered tiles (1 - 15). A tile can only be moved by sliding it into the blank space. The object is to move the tiles such that they are arranged in the following order:
Construct a program that presents the user with a scrambled 15-puzzle, and lets them play at solving it. You should add the following features:
The puzzle and the control panel should be in separate windows.
In the puzzle window, add a bit of animation to the tiles, so that a tile appears to "slide" when it is moved. We discussed the use of Thread.sleep() for such tasks. A much more nuts and bolts description of animation and threading is given in Chapter 2 of Killer Game Programming, available from our library reserve.
Obviously, the graphics themselves are very simple. The relevant tasks can be accomplished using the Java2D framework, in particular the Graphics2D and/or the BufferedImage classes. Chapters 5 and 6 of Killer Game Programming give a nice tutorial on the relevant topics: it's really pretty easy.
Add a "scramble" button, which generates a random permutation of the squares. It should be possible at any time to re-scramble the puzzle by clicking on this button.
Note that half of all possible permutation are, in fact, unsolvable. For this version, it is acceptable to produce such unfair games, but you might give some thought to only producing solvable permutations (HINT: starting from a solved board, any permutation you create by legal sliding move alone will result in a solvable permutation).
Add a "timed mode" feature, in which the player must solve the puzzle within a fixed amount of time (this should be user-controllable). If the puzzle is solved in this time limit, the timer is stopped and a congratulatory window should be displayed. If the puzzle is not solved in the time limit, the game is halted and an announcement of loss is made.
Display the timer counting down.
Bonus feature idea #1: replace the numbers with tiles of an image, so that a solved puzzle is the correct arrangement of the image.
Bonus feature idea #2: Add sound effects and/or music.
In addition, for each of the non-trivial, public methods include a specification and enforcement of each method's contract through the use of assert statements. I will leave it to your judgement to determine which methods are "trivial" or not, but if the method is public and not trivial, it must have a contract.
Finally, it should be clear that many of this program's components must run in parallel, and that means you'll have to think about controlling access to shared resources. Which methods (or blocks) will need to be synchronized? Are there instructions running in different threads for which you must guarantee a happens-before relationship? How will you enforce that?