Of course all your classes, and each of their public members, must have javadoc comments which explain what the purpose of each item is. Approximately 20% of your lab grade is devoted to javadoc comments, even for the extra credit points.

• Game initialization
• [20 points] Basic: the board is created with an initial size of 9 by 9 squares, populated with 3 balls in randomly chosen squares, with each ball in a randomly selected color from among red, blue, and green. Always display the current score on the graphical user interface (GUI). Provide the player a "Quit" button which, when clicked, exits the game.
• Ball movement
• [20 points] Basic: The player can move a ball to any unoccupied square by first clicking on a ball, then an unoccupired square.
• [10 points] Extra credit #1: The player drags the ball - the game manager only allows the ball to follow a legal path. A path is legal if it only goes through unoccupied squares.
• [20 points] Extra credit #2: The player just indicates the ends of the path - the game manager finds a legal path between the two positions, if one exists. A path is legal if it only goes through unoccupied squares. If there is no legal path, the move is not permitted.
• Clearing of balls
• [20 points] Basic: clear a line of 5 or more adjacent balls, all of the same color, either horizontal or vertical, whether the line is created through the placement of a ball by the player or by placement of a ball by the game manager.
• [10 points] Extra credit: clear in multiple directions simultaneously. In other words, if placement of a ball on the board (either by a player or the game manager) results in a matching line both horizonally and vertically, then both must be cleared and scored).
• New balls
• [20 points] Basic: they just appear in randomly selected unoccupied positions, after the player has moved a ball.
• [10 points] Extra credit: they show their "intended" positions at the start of the player's turn, and show up in those positions only after the player has moved a ball, and then only into positions still available.
• Levels, scoring and game end
• [20 points] Basic: there is just one level, and scoring and the game end function as described above. Display an appropriate message in the graphical user interface (GUI) when the game ends (either because the required score has been attained, there are no more moves). When the user clicks the "Quit" button the game exits immediately.
• [10 points] Extra credit: the game as described is only level 1. Add multiple levels, such that at level k:
• The size of the board is (7+2k)×(7+2k);
• When the game manager adds balls, k+2 balls are added;
• When the game manager adds balls, k+2 colors are used;
• When n balls are cleared the score is k×10×n
• The level ends when the player scores k×500 points
• Provide an appropriate message when the game ends and when the level changes

Technique hints

Below you will find some hints which you may find useful in doing this lab. Additional hints may be posted here as time goes on, so do check back from time to time.

All sections of the course are having discussions of similar problems in lecture, the code for which either is or will be available in the lecture code repositories. You may mine these examples for ideas about how to approach this lab.

Finally, if you have questions do make use of office hours. Don't leave questions until the very last minute: you won't have time to get answers to them in that case!

Randomness

• Every time the expression utilities.Random.randomInteger(i,j) is evaluated, it will evaluate to a random integer x such that (i <= x) && (x <= j)
• The java.util.Collections class provides a static method named shuffle which takes an object of type java.util.List and shuffles (randomizes the order of) the items it contains.

Board representation

Visually the board must appear on a graphics.DrawingCanvas. However, it is helpful to have a more abstract representation of the board too, in terms of the positions on the board and their contents. A reasonable way to represent the board in this sense is to use a java.util.HashMap. This class will be discussed in lecture and/or recitation.

States and their representation

Notice that the game is state-based: its behavior on a given action (e.g. a ball or square being clicked) depends on the state that the game is in.

It is helpful to draw a diagram (called a state-transition diagram) which shows what the states of the system are, and what triggers a transition between states. For example, a typical traffic light has three states:

• State "R": only red light on
• State "Y": only yellow light on
• State "G": only green light on

The traffic light transitions from one state to another in a fixed and predictable way: from state "G" to state "Y" to state "R" back to state "G".

One way to implement a system like this is to use what is called a state pattern. The diagram below shows the UML class diagram for a simple state diagram for traffic light as described above:

In this diagram the TrafficLight has a state (of type ITrafficLightState). The three concrete implementations of ITrafficLightState are:

• RedState
• YellowState
• GreenState

The code for this example is in the lecture code repositories for both sections A and B. Regardless of which section of the course you are in, you are welcome to look at this code, or indeed any of code the lecture code repositories: it is in a project called TrafficLight.

Running this program displays a traffic light showing a "red light":

Clicking on the button labelled "Transition light to next state" calls a method on the TrafficLight, transitionToNextState. The TrafficLight should in response change its state, but the TrafficLight cannot directly do this. Why? Because the TrafficLight itself does not know what state it is in - it simply knows that it has a state. Each state knows how to transition to the next state, however, so the way that the TrafficLight effects the state transition is to delegate the task to its state object, since it knows what to do. In this case the Red state is defined to transition next to the Green state:

The Green state is defined to transition next to the Yellow state:

Finally, the Yellow state is defined to transition back to the Red state.

These state transitions are written into the state classes, and are revealed by looking at the instantiation dependencies between them:

A benefit of using a state pattern in this situation is that each state class is very straightforward to design, since its methods need only do the right thing when the system is in that particular state. This matters more when the states have more to do than they do in the traffic light example, as they might in this lab :-) All the same, the traffic light example shows all the basic elements of a state pattern implementation.

Working from home

If you are working from home ensure you have the most current copy of the Classlibs.jar file.

Submission Directions

Basic requirements submission

After you are finished writing your code, jar the Lab9 project and submit the resulting jar file, Lab9.jar.

Extra credit submission

If you wish to make an extra credit submission, you absolutely must make a separate basic submission first, and then submit your basic submission with added extra credit functionality in an independent submission named Lab9ExtraCredit.jar.

Due dates