CSE 142 Spring 2002 Homework #7 Lights!  Camera!  Action!! Due: Project description/partner declaration due    via email by 6:00 pm, Friday, May 31;   electronically 11:00 pm Wednesday, June 5;   written report due in sections, Thursday, June 6;   grading demonstration with TA at a time tba.

IF your code compiles, and IF you've looked at it closely and it seems to you that it should work, BUT you experience a problem like one of these:
• objects in the GWindow don't move smoothly, but "jump" from one place to another, or
• your program (or BlueJ) doesn't respond to input any longer
you may be having a problem whose cause is explained at http://www.cs.washington.edu/education/courses/142/02sp/homework/hw7/AnimationExplanation/

An experimental version of uwcse.jar that allows you to move GWindow's on the screen, and to set their background color, is available.

We will not be making bug fixes with this version, and will not help with installation problems.

If you want to try it, go here.

Overview

For this assignment you may work with one partner.  If you work with a partner, the two of you should turn in a single program and report with both of your names on it.  Somewhat more work will be expected from a group of two than from an individual.

Minimal Requirements

Your project should:

• Be controlled by keyboard or mouse events, or some combination of these.
• Contain at least two kinds of objects (classes) that have interesting behaviors (two different kinds of objects participating in a simulation or game, for example).  These must be classes you create, not just instances of library classes like Rectangle or Oval.  The two classes must be different in some non-trivial way - an example of something that's not sufficient would be having two kinds of spaceships that are exactly the same except that one kind is blue and the other red.  Something that would be sufficient would be having two kinds of flying objects (spaceships and asteroids) that fly in different ways.
• Contain a standard Java main method that creates some initial objects, and starts the action.

A good example of a suitable project would be a game or animation, where there are several different kinds of objects that react to events and/or interact in some way.  If you're having trouble thinking of good ideas, you might think about building a scaled-down version of a video game you like.  You don't necessarily need to implement a game, as long as what you do meets the minimal requirements.

You are free to use other Java classes and code that you find in libraries, however, you must give credit in your report explaining anything you used outside the basic CSE142 and Sun standard Java libraries.  You also must do a non-trivial amount of programming, creating new classes - you can't just, for example, take the GraphicsComposer program from lecture and add mouse handling to it.

Project Description and Partner Declaration

You and your partner (if you have one) should write a short one- or two-sentence description of your project.  Don't describe the code, but tell what the program is intended to do.  It should be a description that a non-programmer would understand.  Obviously, as you implement the project the details may change, but this description should reflect your intentions for the final project.

Email this description along with your name and section and (if you have one) your partner's name and section to your TA by 6:00 pm, Friday May 31.  If you are working with a partner, both of you should send a copy of this message to your respective TAs.  The TAs will check to be sure that what you are proposing sounds reasonable and, if there are any problems, will get in touch with you via email.  This is meant as a quick check to alert you to possible problems; if everything looks ok, your TA may not need to reply. 

Implementation Suggestions

Here are some ideas to help you start organizing your project. 

• Start small.  This is the most important hint of all.  Figure out some minimal set of features in your program that you can implement without having to implement anything else.  Then add to it. You could start by creating a window with a single object that does something simple - maybe wanders back and forth, reversing direction when something happens.  This way you've always got something to show for your efforts and you don't risk trying to do too much and not having anything actually working at the end. Remember, you can turn in your program repeatedly.  It would be a good backup plan to turn it in each time you get a major new part of the code working.
• Don't start with GraphicsComposer.  A sure way to get yourself into trouble is to download the GraphicsComposer example from lecture or some other program that doesn't match what you're trying to do, or that you don't understand, and try to modify it into something that does what you want.  While it's often helpful to start with some existing code and build on it - most programmers do this most of the time - the GraphicsComposer example, for example, is probably too complex, containing irrelevant code.  Feel free to look at examples of code that do things similar to what you want, but be sure that you understand all of the code that winds up in your final project.  
• Assuming that you're doing a simulation or game, the virtual world will consist of two or more kinds of objects that interact or update their state as the simulation progresses.  A good way to organize the code is to use the model-view-controller structure talked about in lecture.  The model would contain a collection of these objects.  When something interesting happens, iterate through this collection, tell all the objects to update themselves, then notify the viewers that the model has changed so they can update their display of the model.
• Interfaces:  To simplify the model, you can define an interface that specifies behavior common to all of the objects in the simulation, then implement that interface in each class that represents objects in the simulation.  See the Dugan notes for more discussion.

Animation

The basic idea behind animation or simulation is to repeatedly change the state of the objects involved, then update views so they reflect those changes.  For graphical views, you've already seen something similar in HW3 - bouncing balls - but we didn't explain the details at that time.  Here's how it works.  When it's time to update the state of all of the objects, send a suspendRepaints message to the GWindow, e.g.,

   theWindow.suspendRepaints();

   theWindow.resumeRepaints();
   Thread.yield();

Written Report

Prepare a short (at most 2 pages) written report with the following information:

1. A brief description of your program - what it is and what it does.
2. Give simple instructions for running the program and interacting with it.
3. Give a brief description of how well you achieved the goals you set out for yourselves at the beginning of the project.  Where there any substantial changes from your initial project description?
4. If you had more time to work on this project, how would you like to have improved it?  What additional programming knowledge would have helped?
5. What are the most important things you learned from this project?

Notes about grading

If you work with someone, both of you will receive the same score for the assignment, except in unusual circumstances.

Grading will be done in person with a TA, with both partners present.  You will have to make an appointment with the TA to meet in the IPL.  Details will be discussed in sections. If you and your partner have different TAs, make an appointment with one of them; we reserve the right to switch you to the other TA if necessary for scheduling or load-balancing reasons.

At the grading appointment, be prepared

• to show off the features of your project, and
• to answer questions about the code

Both partners should be fully prepared to handle either aspect.  The demo will be done from our on-line copy of the code as turned in electronically.  You will not have to bring the code on a diskette.  The demo period will be short.  It would be a good idea to rehearse a 4 or 5 minute demo in advance.  Both partners need to show up, at the scheduled time, or the project may receive a grade of zero.

Turning in Your Work

Electronically turn in your files using this turnin form.  Turn in your report in sections on Thursday, June 6.  Remember that if you work with a partner, the two of you should turn in a single program and report.

Have lots of fun!