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

• use rapid prototyping to work through the core functionality of a software system,
• identify useful abstractions by implementing variations of a prototype,
• manage user keyboard events, even when they are interleaved with program output.
• have experience evaluating the usability of your own software (the audio clip manager)

Overview: In this lab, you will implement prototypes of two variations of a simple game designed to help special needs children learn their letters and sounds. This will be a rapid prototype, with only the most basic features. Since the purpose of a prototype is to explore the basic structure and functionality of an application, you will make many simplifying assumptions. In other words, you should implement as few features as possible in order to get the basic game running. You will use this experience in the next assignment to create a more general game architure that supports customization, but at this stage you are not aiming for a general extensible system. The goal is to explore the territory by getting a simple implementation up and running quickly.

Some say rapid prototyping is equivalent to "quick and dirty," but it's probably better to aim for "quick and clean." Since this code is not expected to be long lived, you are not responsible for writing any documentation. However, you will save yourself time in debugging by keeping the code reasonably well organized. If it's too "dirty," then you'll have a hard time getting it to run.

Since integration takes time, and this is a fairly small project, you may find it faster to work through the entire project side by side with your partner, but feel free to divide up the work if you want.

You have been provided with a Picture class to display an image, as well as a collection of image files. One image is a picture of a keyboard (Keyboard.jpg), and other 26 are GIF images, each one with a file name beginning with a different (lower case) letter of the alphabet from the free worksheets page at beginningreading.com. You will need to use (the batch recording feature of) your audio clip manager to record sounds for the game. You can write a separate little program that starts up the audio clip manager and passes it arrays of strings to record these sounds. If you built your audio clip manager well, you should be able to record all the sounds you need in just a few minutes. Before recording your audio clips, you should probably change the sample rate in the player and recorder to 44100 (instead of 88200) so the files aren't so large. Take notes on your experience in using your audio clip manager, particularly noting changes that might make it easier to use. You don't necessarily need to make these changes now, but it's good to get in the habit of noticing usability issues. The following sound clips will be needed.

1. voice prompts such as "press any key" and "find the letter..."
2. the spoken name of each letter (you could compute or hard-code an array containing the letters of the alphabet to pass into your audio clip manager)
3. the spoken word describing each picture (to get an array of these strings, put the image files in a directory in your project, and let your program get the list of file names from the directory and trim away the file extensions from the strings in the array)

Requirements: You will implement two variations of the game. Both variations of the game take over the entire display. On the display are two items side by side: A huge letter and an image of something that begins with that letter. In both variations, pressing the escape key (ESC) should terminate the program.

• Variation 1: At first, the text is a question mark and the picture is of the keyboard. The user hears "press any key." Each time the user presses a letter, the text display changes to the upper case version of that letter, and the picture changes to the picture from the images folder that begins with that letter. Then, the user hears the name of the letter, followed by the word for the image. For example, if they type A, they would see "A" and a picture of an apple, and they would hear "A... apple", as two separate sound clips, one after the other. The user can continue to type letters and get this kind of feedback. Whenever the user goes 10 seconds without typing anything, the prompt is repeated.

• Variation 2:The user is shown a random letter (and the corresponding picture is not visible). The user hears, for example, "Find the letter... A" as two separate audio clips in sequence. If the user types "A," then the picture appears and the user is rewarded with the corresponding picture and gets a congratulatory message such as "Awesome... you found... A!... Apple!" as four separate clips. If you user types any other letter, then the user hears, for example, "No. You found... Q... Find the letter... A" This continues until the user types the correct letter. Then a new letter is chosen at random and the same process continues.

• Optional: Set the background color to match the color of the key on the accessible keyboard. If, in variation 2, the user gets it wrong twice, the program can provide a hint suggesting the color of the key on the accessible keyboard. For example, the user might hear, "try a yellow key..." Also, if the user chooses wrong another time, the program could suggest trying the "top row," "middle row," or "bottom row." If you think of A=0, B=1, etc., you can use these constants to determine the color and row of each letter.

Many other variations are possible, such as asking for the letter without any visual cues, showing only a picture that starts with that letter, showing only the lower case letter, etc. For now, just implement the two variations listed above. Later, you will create a customizable game that will allow a parent or teacher to create and save different game variations, as well as record the necessary sounds, create categories of images that the child would find particularly motivating, etc.

Some implementation advice:

• Register a KeyListener on the frame and use the keyPressed method to process keystrokes. Use the getKeyChar() method on the event object to find out what key was pressed.

  Old keystrokes will get queued up, but you probably only want to process the most recent keystroke. To see if an event is recent, you can call the event object's getWhen() method and compare the time to the value of System.currentTimeMillis(). If they are within 200 milliseconds, it's probably recent enough.

• To set the frame size to fill the screen, you'll need to find out the size of the display using Toolkit.getDefaultToolkit().getScreenSize(). You should set the font size of your JLabel text display to about 3/4 the height of the screen. Also, set the preferredSize of the picture to be the same as the preferred size of the JLabel. (You'll want to create the JLabel with a letter in it, or else its preferred size will be too small.) FlowLayout is recommended, since you just want two items side by side.

• The keyCode for the escape key (ESC) is 27. If e is a KeyEvent, then e.getKeyCode() provides the key code. After you are absolutely sure that your key listener is working to terminate the program by calling System.exit(0), you can get rid of the border of the JFrame (including the "X" in the upper right corner) using setUndecorated(true).

• As you may have already discovered, Java's graphics sytem generally avoids repainting components while it is processing an event. For example, if in a key event handler you change the picture and then play a sound, you may find that the picture doesn't actually change until after the sound is done playing. Using start to play the sound may not be a solution either, because if you have more than one sound to play, they will play simultaneously. You want to play them one after another, but after changing the text and picture. To solve this problem, you can enqueue a runnable object into the event queue. It will run after the current event is finished processing and the screen is repainted. For example, you could add the following method to the player. Each call to this method would put a sound into the event queue, and they would be played in order.

  	public void enqueue(final File f) {
  		EventQueue.invokeLater(new Runnable() {
  			public void run() {
  				play(f);
  			}
  		});
  	}
  

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.

On Thursday, February 21, you will do a demo of your completed Lab 1 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, February 26:

1. A completed cover sheet.
2. Your final contract form, showing who completed which items of the project. Include each major class (view components, controllers, model components, etc.)
3. One completed design decision form per person, reflecting on a significant design choice or design change you made. Each person should write their name on their design decision form.
4. A 1-page handwritten module interaction diagram showing each of the major objects in your system, with labeled arrows showing the way they interact (events going to controllers, etc.) Do not go overboard with this. This is a high level sketch to explain at a high level how your code fits together. Use whatever notation you find natural to express the relationships between the objects in your system.
5. 2-3 pages of code (double sided) per person. This should be clean, but since this is a rapid prototyping exercise, we don't expect thorough documentation. Include comments for anything unusual. This should be a good sample of the various aspects of the project. 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.