Goals: Upon completion of this lab, you should be able to

• extrapolate from a rapid prototyping experience to design an elegant code base, moving from the concrete to the general,
• design and implement an extensible class hierarchy that supports an application domain,
• design a simple programming language for a user-programmable application,
• implement components of a visual editor for a programmable system, and
• integrate several sophisticated components into a unified application.

Overview: In this lab, you will implement a user-programmable game designed to help special needs children learn their letters and sounds. Your goal is an elegant design and implementation. The aim is not to simply get it to work, as in a rapid prototype, but to create a code base consisting of a set of classes and interfaces that not only cleanly support the application requirements, but also would extend easily to support additional features. You will do the design and implementation in stages, with checkpoint due dates as listed above. Note that the requirements are fairly open-ended, with a lot of details omitted. This leaves room for you to be creative, but if you're unsure about a requirement, by all means ask.

Requirements: We will use the word parent to refer to the person who is customizing the game, and the word child to refer to the person who is playing the game. Assume the parent has experience using a computer, but does not have programming background. The parent will design one or more screens containing visual elements of the game, and each screen will have an associated set of rules that determine what should happen during game play when that screen is showing. The specific way that rules look and are specified is up to you. However, each rule must have a trigger such as a "target letter key pressed" or "timer expired" and a sequence of actions such as "say the typed letter" and "go to screen 3." In addition, each screen may have a sequence of actions that are performed when the screen is first shown, such as "select a target letter", "say: 'find the letter'", "say the target letter," and "set a timer for 10 seconds." Each of the variations you implemented during rapid prototyping would require 2 or 3 screens, with each screen needing 2 or 3 rules. (A variation giving hints would require more.) Use the variations you already built as a guide to be sure that you are providing sufficient functionality, but also think about other possible game variations, such as showing a picture and a set of words, and asking child to choose the correct word.

1. GUI designs Design the GUI layout and write thorough use case scenarios for the following two central pieces of the programmable game, plus a third layout showing the overall integrated layout with multiple screens and sets of rules. One common piece of state in the game will be the "target letter" that might be randomly selected or chosen some other way. When multiple letters, words, or pictures are on the display, it is assumed that during game play one of them (at random) will be the one corresponding to the target letter.
   • Screen layout editor: The parent sees a small-scale version of the game screen that the child would see while playing the game. The required elements available for use on the game screen are: letters, words, and pictures. Note that these elements are simply placeholders (examples) for the items that would actually be shown during game play, since specific choices for which letters and words to show will be determined during play. The editor provides functionality for the user to (1) add elements to the screen layout, (2) control the size and position of elements, (3) remove elements from the layout. There are many different ways to accomplish this, but direct manipulation is preferred wherever possible. Think carefully about what would be the most natural, obvious, and easy for the user. If you want, you can handle the sizing automatically, based upon how many of each type of component are on the screen.

     Note: The words, pictures, and letters on each screen should correspond. For example, if there is a word "duck" on the screen, and there is a picture on the screen, then the picture will always be of a duck. However, if there are two words and two pictures, how the parent specifies the correspondence is up to you. You can also give the parent the option of shuffling them if you want, which could be helpful for creating a matching game.

     Optional: In the screen editor, you could give the parent control over whether letters and words are shown as uppercase, lower case, or mixed case (words capitalized). This could be done by providing different elements for upper and lower case letters, or it might be easier for the parent to specify this as a global setting for the game, rather than having to edit each of the screen layouts.

   • Rule editor: The parent can specify the trigger for a rule, which may be any one of the following types: pressing the target letter or a wrong letter, a timer expiring, or a mouse press on the target element or incorrect element on the screen. The other part of the rule that must be edited is the sequence of actions to be performed when the rule is triggered. These include one or more of the following types of actions: say something (which could be based on the target letter, the typed letter, or a specific prompt), choose a target letter, and go to a given screen (which may be the same screen). Users should be able to create and reorder actions within a rule. How you present rules visually, and how users choose the trigger and action types is up to you. For example, you could use a JPopupMenu, a JList, a JComboBox, etc. Keep in mind that some action types have extra parameters that the parent must specify, such as the amount of time for a timer, the words of a prompt, etc.

     Optional: In the rule editor, you could use icons to represent the triggers (picture of an A key for the correct letter, X key for the wrong letter, a happy or sad mouse for clicking on the correct or incorrect item, and a picture of a timer.

2. Model class hierarchy: The model for your implementation is the set of objects that hold the application state. Your view classes will wrap model classes to display content to users. Design and implement an extensible class hierarchy that captures relationships among the screens, elements, rules, triggers, and actions. (In the model, a screen is just the relevant information about the elements to be displayed on the screen, not the graphics components themselves. Those would be the view of the screen.) Include all of the required element types, trigger types, and action types. Use abstract classes to hold common implementation, such as a PropertyChangeSupport object for firing events that notify listeners about model changes. It is strongly recommended that your rules and actions implement Runnable to make it easy to use them as the basis for game play. The model classes should be Serializable to simplify saving and loading edited games to disk. However, if you wish to avoid saving property listeners to disk, property change support instance variables should be marked transient and reinitialized each time the game is loaded. When you do the model hierarchy implementation, use test-driven development and create thorough JUnit tests and complete documentation. For the demo, included a test case that creates a model and saves it to a file, and another test case that loads the saved model from disk and spot checks it for correctness.

3. Screen editor and rule editor implementations: Using your model to hold the application state, implement the editors according to your GUI layout design and use case scenarios. When you implement the screen editor, provide a way for the user to see a full-scale version of the screen as the child would see it. (For example, they could click on a "show full screen" button, and the full screen version of that screen is shown. Before you implement these editors, draw a 1-page module interaction diagram (see the "what to turn in" section below) to help guide your design. Most of your model classes will probably have a corresponding view class. For example, you would have a RuleView class that lets the user interact with an underlying Rule object in the model. Similarly, a ScreenView class would let the user interact with the Screen object that knows about all of the elements to be shown on that screen. These views may be defined in terms of views of the parts inside their model. For example, a RuleView might include a TriggerView (of a model object represnting a trigger) and an ActionListView (of a model that holds a list of actions, which would each have their own views in the action list). If this is unclear, please ask, because it is a central concept in the model-view-controller architecture.

4. Integration: The integrated game should work as follows. There is a default game, which is the game you would provide to the parent, or most recently edited game. When the game starts up, the child can play the default game, and the ESC key exits the game as usual. However, pressing shift-ESC takes the parent into the game editor, where they see the integrated layout showing all the screens of the game and their rules. The parent can add, edit, and remove screens. Also, the parent can add, edit, and remove rules for each screen. You should also integrate your audio clip manager into the application, allowing the parent to record any missing audio clips. Ideally, your program will keep track of which words/pictures/prompts have not yet been recorded, and you can directly call the batch recording method in the audio clip manager for them to record the missing sounds.

   Optional: Let the parent create copies of screens and rules to save time during editing. Copying screens is particularly important for games in which elements need to be at the same exact position on different screens. Otherwise, those items will appear to "jump" during game play when switching from one screen to another.

   Optional: Provide undo/redo support for all editing actions, making use of the javax.swing.undo package. This takes considerable planning and care, and we will be impressed if you do it. (If you plan to do this, it would be a good idea to design it into your model from the start.)

   Optional: Provide the ability to open and edit different game variations, possibly in different tabs (see JTabbedPane) in the editor.

   Optional: Provide the ability to track how well the child has learned each letter (percent correct) and give the parent the ability, in the editor, to control which letters are used in the game (e.g., 26 checkboxes, where each shows the letter and a percent correct history of some kind).

   Optional: Allow the child to select a word/picture category (animals, transportation, etc.) when starting up the game.

What to turn in: You are required to attend your scheduled lab section throughout the semester. During lab section, we will review your design, see demos, and review your code. We may sometimes ask you to electronically submit your code and/or print out certain sections of your code for grading, but most feedback will occur interactively during lab sessions.

Use a small 3-ring binder to keep all of your design notes throughout the semester. Include each design decision, the reasons for that decision, and what other alternatives were considered. There are forms on the CSE132 web site for this purpose. You will need to submit your design notebook at the end of the semester.

There are several design review and demo dates for this assignment, as shown in the list at the top of the assignment. On Thursday, April 3, you will do a demo of your completed Lab 2 during your lab section. After the demo, and any accompanying review of your code, you and your lab partner should prepare the following packet to be turned in for grading on Tuesday, April 8. However, many of these items are due for discussion in lab section on earlier dates, as specified above.

1. A completed cover sheet.
2. Your initial GUI layouts and screen shots for the screen editor, rule editor, and integrated view.
3. Your final class hierarchy and specifications and for the model classes.
4. Your final contract form, showing who completed which items of the project. Include each major class (model, view, and controller classes). Show who completed the JUnit tests for each model class.
5. Two completed design decisions form per person, reflecting on a significant design choice or design change you made. Each person should write their name on their design decision forms.
6. A 1-page handwritten module interaction diagram for the screen editor, and another one for the rule editor. Show each of the major model objects, view objects, and controller objects in your system. Arrows should indicate communication and be labeled with the name of the corresponding method call or event responsible for that communication. Do not go overboard with this, but it should be enough to explain at a high level how your code fits together.
7. 4-5 double-sided pages of code per person, including documentation for each class and method that you turn in. This code should be a good sample of the various aspects of the project. You can turn in portions of classes, leaving out the boring parts, like standard accessor methods. Please do not turn in extra code. Be sure it is clearly identified who wrote which sections of the code.

Note: For the forms, handwritten is fine, but if you prefer to type them, there are Word documents for these forms available on the CSE132 menu.