LightsOut

Work on this exercise in the pairs assigned by your instructor, striving to use good principles of Pair Programming. Feel free to ask questions of your instructor, student assistants and classmates as desired. 4>Goals The goals of this exercise are to:

Learn about informal use of UML to brainstorm a design.
Review use of arrays (1D, 2D) and ArrayLists.
Learn about GUI design in Java
Learn about event-driven programming.

The Exercise

Instructions Part 1 - Demo and Specification

Your instructor will demo LightsOut.

For this assignment you will design and implement a variation of the electronic game "Lights Out." But your virtual game can add features that a physical game could not easily support.

The user will initially be presented with a 5 by 5 (in this case we'll say that numRows=5) grid of buttons, representing lights that are on or off. The object is to end up with all of the lights off. When the user presses a button, the on/off state of that button is toggled, along with all of the "vertically and horizontally adjacent" buttons in the grid. For example, if the user clicks the [2,3] button, then the on/off states of the following buttons are toggled: [2,3], [1,3], [3,3], [2,2], [2,4].

We will do some in-class exercises that will help with various aspects of this assignment.

Detailed specification

You game should meet the following specification:

Your game behaves like the example shown above, with regard to button-clicking and toggling of lights on and off.
- You may add additional functionality if you wish, as long as the prescribed functionality is there.
- Your project does not have to look exactly like the example shown above; you may be creative.
- Experiment as you like with user interface features, but not to the extent that you neglect your other work in this class. Additional features/creativity are NOT required.
Your game has controls (probably buttons) that provide at least the following features:
- Reset. Turns all of the lights off.
- Setup-mode toggle. After the user presses this button, pressing a light button toggles only that button. This is to allow the player to set up a custom initial configuration. Pressing the setup-mode toggle button again returns the game to ordinary "play mode."
- Random. Turns off all of the lights, then randomly generates a set of "on" lights, from which it is possible to get back to the "all lights off" configuration.
- Increase. Adds one to numRows, enlarges the grid of light buttons to contain one more row and one more column, and turns all of the lights off.
- Decrease. Subtracts one from numRows, shrinks the grid of light buttons accordingly, and turns all of the lights off.
Your game displays the name of its author.
Your final project is delivered as an applet. (You can write it as an application while beginning development; it's easy to change it to an applet later.)

As always, your project should have a design that is easily extended and an implementation that is clear, per the next section.

In addition, we may have you do a peer review of classmates' projects after the project is turned in.

Instructions Part 2 - Design

This project requires some interesting design decisions. UML is a great tool to do this. Your instructor will have you go to a whiteboard with your partner (and maybe another pair) to brainstorm which classes we'll need and how each one needs to know about each other.

Your UML disgram must have the names of the classes and the relationships (IS-A, HAS-A) between them. You might also find it helpful in some cases to add some more details: the fields and methods of each class, and even the types of the fields, methods and method parameters.

Here is an example of a UML class diagram for a game called HiLo.

Instructions Part 3 - Create a basic Iterative Enhancement Plan (IEP)

Software engineers typically implement their projects by using Iterative Enhancement, which means:

They implement the project in stages.
Each stage adds more functionality.
- Each stage must be testable by running the application.
The final stage implements all the required functionality.
They test each stage as they implement it, rather than doing all the testing at the end.

An Iterative Enhancement Plan is a list (in ordinary English) of the stages.

Each stage's description explains what functionality must be supplied at that stage.
- The description must refer only to the project's functionality, not the project's code.
- The description should make plain what test(s) one would do to test that stage.

Overall, I recommend working on the array logic first, and leave the GUI enhancements until last.

Instructions Part 4 - Start working on your IEP

You should be committing code via Subclipse to your team's repository at least at the end of every phase of the IEP. Format:

http://svn.cs.rose-hulman.edu/repos/username1-username2

(where the 2 usernames are alphabetized).