ension
  UW Home     CSE Home   Announcements    Message Board    Contact Info 

 
 
 

CSE143 Winter 2005 Project #1 Part C

Traffic Jam! - Handling User Events

Due: Friday, February 4 Saturday, February 5, at 9:00 pm. No late assignments will be accepted.

This is the last part of a project to create a traffic simulation. For this part you will take your code from part B and add code to handle keyboard, mouse, or other events to control something in the simulation. This should include using the mouse or keyboard to control one or more of the things in the simulation (e.g. taking over control of one of the vehicles). In addition, you can add menus, dialogs, slider bars, or other event-driven user interface components to alter parameters or characteristics of the simulation.

You should continue work with your assigned partner on this project using the pair programming style discussed in class. You and your partner will turn in a single set of files under the same name you used for parts A and B. After this final part of the project is done, each of you will individually produce a written report. (Details about that will be supplied separately.)

Grading: This is the final code turnin for the project -- it is not a checkpoint. You and your partner will receive the same scores on the programming parts of the project. Programming projects will be evaluated both for how well the code works and how well it is written, each on a scale of 0 to 4 (see the project assessment guidelines on the main projects page for details). Be sure to include appropriate JavaDoc and other comments in your code, use meaningful names, indent sensibly, and so forth.

Overview

For the final part of the project, add event-driven user control to your traffic simulation. The exact form of the user interface is up to you, however, it must allow the user to control at least one vehicle or other object using the keyboard or mouse. Include at least two user events for the simulation to respond to. They must be nontrivially different from the events in the BallSim code. (That is, they can't just cause a new vehicle to be created.) Some possibilities:

  • Display a control panel with several buttons to change the speed of some or all vehicles slightly each time the appropriate button is clicked. (E.g. if you have a class representing slow drivers, you could let the user adjust how slow they are. Or make all green cars speed up. Or change how fast your traffic lights cycle. Etc. etc.)
  • Control the choice of what turn to take at an intersection by using the left, right, up, or down arrow keys.
  • Use the mouse to drag a vehicle along.

How you choose to control multiple vehicles and other objects on the screen, if you want to do this, is up to you. Your could have one controller per vehicle (say, a palette of control buttons, one for each), or you could select a vehicle with the mouse and have the controls apply to that vehicle until another one is selected. But if you want to keep things simple, you could just control one vehicle with the mouse or keyboard. Other vehicles in the simulation should probably continue to move as they did in part B of the project.

Your project should continue to be structured using the model/view/controller framework. The model should definitely be separated from the view and controller (with minor exceptions if you implement the drawing code the way it was done in the bouncing ball demonstrations). Depending on how you design your user interface, the view and controller(s) may be separate, but there are reasons to do otherwise. For example, it often makes sense to handle mouse events in the same viewer object that draws the window containing the vehicles.

The simulation must continue to meet the minimal requirements from part B of the project: at least two distinct kinds of vehicles and roads, relatively smooth motion under normal circumstances, etc.

Extra Credit

Some extra credit will be awarded for projects that go substantially beyond the basic requirements. This is cumulative over all parts -- the extra credit for all parts will be included in a single extra credit score. You don't have to hope we'll notice your extra credit work -- you can tell us about it in your reports.  Remember to report extra credit from parts A and B as well as C.

The lists at the ends of parts A and B have some ideas. In addition, user interactions that go beyond the basic requirements can also be worth extra credit. However, simply adding new vehicles to the scene in response to a mouse click, for example, wouldn’t be worth extra credit by itself since it is something that was already present in the sample programs shown in classes (and in fact, just doing this would not meet the basic requirements of this part of the project).

Some examples of extra-credit-worthy additions:

  • Add a panel with graphics and controls for a steering wheel, accelerator, brake, turn signals, so the user can control a vehicle with them.
  • Let the user "draw" a road network by placing intersections with the mouse, and clicking on entrances and exits to connect them with roads.
  • Use Swing widgets that aren't in the sample code to control some simulation settings, operate vehicles, etc. To get ideas, look at Sun's Swing Tutorial, especially this page on using Swing components, and this visual catalog of widgets.
  • Make your simulation window respond in interesting / appropriate ways when the user does things like resize the window (e.g. add scroll bars, or have the display expand or contract to match the window size).
  • Provide controls to zoom in and out.
  • Do interesting things with mouse dragging, e.g. implement a "grab hand" that lets the user slide around the part of the simulation window they're looking at.
  • Give the user a display of simulation statistics, maybe letting them select the information they want to see from a menu.
  • Turn your simulation into a game. Maybe allow multiple players.
  • Use game controller hardware instead of a mouse. Got one of those steering wheels from a driving game?

What to Turn In

Use this online turnin form to turn in the Java source files that make up your project, including your JUnit tests. If your project uses any other files, such as images, turn those in also. If you have many files, including things like images, you can bundle them into an archive file (zip, jar, or tar) and turn that in. Multiple turnins are fine and highly recommended if you are planning to add extra credit features. Once you've got something that meets the basic requirements, turn that in. Then if you add to your project, turn in the extended version(s) later - we'll grade the last one you turn in.