CS150 Lab 8: I Rode Through the Puzzle on a Class With No Name...

Due Sunday Nov. 19, 2000, 11:59 PM

This week's lab is about writing and using anonymous classes as listeners for user-generated events. The Java 1.1 Event Model, so called because it first appeared in Java's 1.1 version, specifies that graphical components (Component class), utilize objects implementing "listener" interfaces as receivers of events such as keyboard or mouse actions. This is the Observer-Observable design pattern , where the Component is the Observable and the listener is the Observer. These actions include, but are not limited to, clicking the mouse, dragging the mouse, resizing a window, passing the mouse over a component, pressing a key, etc. Since each component often (usually) has a unique response when an event occurs, the listener object(s) that is(are) attached to it are usually unique. That is, components do not usually share the same listener. Anonymous classes are the perfect solution to situations like this where only one instance of a particular class is needed.

To illustrate the usage of anonymous classes, we will build an interactive picture puzzle game. This puzzle will take an image file, JPG or GIF, and slice it into many small blocks. The user will then be able to drage the blocks around on the sceen and reassemble them back into the original picture. To accomplish this, will require anonymous classes to listen for mouse events and move the mouse accordingly, plus "for" loops to initialize the game board and puzzle pieces.

Note: This lab is in keeping with the trend of letting the student be more and more autonomous in writing code, so the directions are deliberately sparse in places. The bottom line is to have the game run as described below, with a reasonable architecture underneath.

Description of the Puzzle Game

The picture puzzle game will perform as follows:

Any Java readable image file can be loaded, independent of the size or shape (within memory restrictions of course).
The image will be broken up into smaller rectangular blocks (puzzle pieces). The number of number of rows and columns a picture can be broken up into is unrestricted, within memory restrictions, though a 10x10 puzzle is pretty hard since all the pieces are the same shape.
When the game starts, the puzzle pieces will be scattered randomly across the frame.
Using the left mouse button, the puzzle pieces can be dragged anywhere on the frame.
Right-clicking the puzzle piece will cause it to "snap" to an underlying grid, so that the pieces will automatically properly align themselves. Thus the image can be reconstructed.
The puzzle can be reset with new numbers of rows and columns at any time.
A new image can be loaded and a new puzzle created at any time, using the desired number of rows and columns.

Structure of the Picture Puzzle Game Program

Click here to see the documentation for the classes needed for this project

Synopsis of structure:

The JPanel called jPanelPuzzle holds both the puzzle pieces and another JPanel which in turn holds a "snap-to-grid" of Canvases (like JPanels, but simpler). The puzzle pieces themselves are extensions of Canvas and are the same size and shape as the snap-to-grid Canvases. Listeners for mouse clicks and movement are added to the puzzle pieces to enable them to be dragged around the screen and to enable them to "snap" into place on the grid. The seemingly odd layering of panels and having the puzzle pieces on jPuzzlePanel and the grid on a different panel is to separate to puzzle pieces from the grid so the system can figure out which grid Canvas is underneath the puzzle piece of interest.

A more detailed look:

The class structure and associated behavior of the game is as such:

An ImageIcon object that holds the image to be used for the puzzle has been declared.
There are two JTextFields that are used to input the values for the number of desired rows and columns of the puzzle.
jPanelPuzzle -- the main panel of the frame that holds the game board and and the puzzle (image) pieces.
jPanelPuzzle has a null layout so that components can be placed in arbitrary places upon it. Failure to use a null layout will cause one's pieces to places themselves everywhere but where you want them!
jPanelPuzzle is the same size as the image.
jPanelPuzzle holds an unnamed JPanel that is not a property of Frame1. By "holding" I mean that this panel has been added as a subcomponent of jPanelPuzzle. This is the game board.
The game board panel is the same size as jPanelPuzzle and is placed in the upper left corner of jPanelPuzzle. That is, it completely covers jPanelPuzzle.
The game board panel has a null layout.
The game board holds Canvas objects that are arranged in the desired number of rows and columns in the game board panel. The Canvas objects are non-overlapping. These Canvases form the "snap-to" grid.
The Canvas objects are the same size as the puzzle pieces, which are determined by dividing the image size by the desired number of rows and columns.
The puzzle pieces are also Canvases but are added to jPuzzlePanel, not the game board panel.
By having the puzzle pieces on a different panel than the snap-to grid, the puzzle pieces can be distinguished from the grid.
Mouse listeners are added to the puzzle pieces to detect the depressing of a mouse button, the dragging of the mouse and the depressing of the right mouse button.
A puzzle piece will follow the mouse when left-button dragged.
When the right button is clicked, the snap-to grid Canvas that is below the mouse at that moment will be determined and the puzzle piece will be set to the same location as that Canvas.

We will break this lab into two parts: initializing the puzzle game and creating puzzle pieces that can be dragged and dropped on the screen. Follow the sections to the left in order and do not proceed until each section (and sub-section) is working!

This lab involves significant usage of methods that are part of classes in the Java AWT package. You are expected to look up these methods in the Java API documentation and figure out what they do.