LightsOut

Objects, classes, event-driven programming and arrays

1. The software design process, including:
   • Design before implementation: using a UML class diagram.
   • Implementation in stages: using an iterative enhancement plan.
   • Documentation using Javadoc.
   • Using a standard style to make your product readable and reusable.

2. Using object oriented programming to create complex behavior. In particular, using:
   • Objects and classes.
   • Expressions and statements including conditionals and simple loops.
   • Arrays.

3. Development in a graphical user interface (GUI).

4. Event-driven programming and the Swing extension to the Abstract Windows Toolkit (java.awt).

Individual work

Do LightsOut by yourself, so that you can be confident that you have mastered its ideas. However, feel free to seek help from assistants and classmates.

As with all your individual work, if you get help:

• Acknowledge it (give proper attribution).
• Don't turn it in if you don't understand it.

Overview

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]. Play with the sample implementation to get an idea of how the game works.

We will do some in-class exercises that will help with various aspects of this assignment. You will have some time in class to work on this project.

Specification

You game should meet the following specification:

1. 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/creatively are NOT required.

2. 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.

3. Your game displays the name of its author.

4. Your final project is delivered as an application.

What to do

You will create this project by applying the software engineering principles:

• Design before implementation: using a UML class diagram.
• Implementation in stages: using an iterative enhancement plan.
• Documentation using Javadoc.
• Using a standard style to make your product readable and reusable.

1. Stage0 contains:

   • A UML class diagram
     • Your diagram should have all three levels of detail for Stage 1
     • Your diagram should have your best guess for all stages, at least at the classes-only level of detail
     • Your diagram is a living document that you update as you proceed

   • An iterative enhancement plan, as described in the link.

2. Stage1Stub and Stage1 implement stage 1 of your iterative enhancement plan, where:
   • Stage1Stub is a stub for stage 1.
   • Stage1 is an implementation of the stub for stage 1.

3. Stage2Stub and Stage2 implement stage 2 of your iterative enhancement plan, and so forth.
   • So each stage has first a stub and then an implementation of that stub.

4. StageFinal is the final versions.

5. You can, and normally should, have several CVS versions for each stage.
   • Remember: a stage means a CVS version that is tagged with the given stage number.

6. Please take care to name stages exactly as stated above.

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

Deadlines

• Stage0: Midnight on Day 3
  
• Stage2: Midnight on Day 4
• StageFinal: Midnight on Day 6
  
• Peer reviews: In class on Day 7