UW Home     CSE Home   Announcements    Message Board    Contact Info 

 
 
 

CSE143 Autumn 2004 Project #1 Part B

A Virtual Jurassic Park - Animated Dinosaurs

Due: Wednesday, October 20, at 9:00 pm. No late assignments will be accepted.

This is the second part of a project to create a dinosaur safari. For this part you will take the Dinosaur classes from Part A and add controller software and a graphical display to show the dinos walking around in a Java Swing window.

You should continue work with your assigned partner on this project using the pair programming style discussed in class. While it makes sense to think about the project, sketch ideas, and try them out on the computer yourself (when your partner is not around), it works best if the two of you write the actual project together at a single computer, trading off the keyboard regularly. You and your partner should turn in a single set of files under the same name you used for part A.

Grading: As with part A, this part of the project will be evaluated on a scale of 0-3 to give you quick feedback on whether there are any significant problems that need to be addressed. Be sure to include appropriate JavaDoc and other comments in your code, use meaningful names, indent sensibly, and so forth.

Overview 

In Part A of this project we created a set of Dinosaur classes to model dinosaurs or other creatures of different types. In this part of the project we want to add a graphical view and introduce a simulation so we can watch the Dinosaurs as they walk around. This should not require many changes to the existing Dinosaur classes and few, if any, changes to the JUnit tests. At the end of this part of the project we will have a model (containing the information about the state of the simulation), one or more viewers (regular Java Swing windows and panels), and a way to make the dinos walk around as the simulation progresses. There are no interactive controls like buttons, mouse clicks, or keyboard events yet. (That's next!)

A key difference between this part of the project and part A is that instead of walking for arbitrary intervals, as done in the JUnit tests from 1a, we want the dinos to walk smoothly under control of a time-based simulation. During each clock tick, or cycle, of the simulation, we want each Dinosaur to move a small amount, possibly with some small changes in direction, speed, or other characteristics. The changes in any one cycle should be fairly small, to create reasonably natural movement. (It would look odd if a dinosaur suddenly changed direction 90 degrees in one clock tick. Though if you want your dinos to be breakdancing or something that requires sharp movement, go ahead.)

The main difference between the code controlling the dinos for this part of the project, compared to the JUnit tests for part A, is that the controller code needs to be aware of the passage of time, and needs to wait appropriate amounts of time between changes to the dinosaur's direction or speed. In part A, a test might have contained code like this to make a dino rex speed up, walk a bit, turn left, and walk a bit more. 


    rex.changeSpeed(1.5);
    rex.move(3.0);
    rex.turn(-5.0);
    rex.move(5.0);
For this part of the project, you will want to speed up the dinosaur gradually over several simulation cycles, wait several cycles while the dinosaur continues to move, turn the dinosaur gradually, then wait some more. The dinosaur should move a small amount on each clock tick instead of moveing a large distance in a single call to move(...).

The interesting question here is where to put the code that controls the dinosaur. It really isn't part of the model in the sense of the model-view-controller (MVC) design - it actually corresponds to the controller part of MVC. But it does need to know when the clock ticks. An easy hack is to implement this code in "controller" objects that are outside the model, for instance a DinoBrain class, and register these objects with the model so they will be notified each time another cycle of the simulation is performed (i.e., each time the clock ticks). The control code can then count the number of ticks and control the dinosaur as desired. Alternately, the Dinosaur subclasses themselves could just have action methods which perform these updates.

You should add a Swing-based viewer to show the locations of the various Dinosaurs as they walk around. This can be fairly simple, or more elaborate, but at a minimum should be able to show each Dinosaur using a small graphic (a small circle is fine) plus a number next to each Dinosaur showing its energy (if you want, you can add controls in the final part of the project to toggle parts of the display, like the display of energy). More elaborate views and multiple viewers are fine, but get a simple version working first before you try something more elaborate. The viewer does not need to be able to display all of the Dinosaurs in the simulation -- if some of them walk off the screen, that's fine. Alternately, if you'd like to keep all of your dinosaurs visible at all times, you may decide to "wrap" the world -- when a dino walks off one side of the window, it reappears on the other side. Not realistic, but fun!

You are welcome to program this in whatever sensible way you like, but you may find the code for the bouncing ball animation, presented in class on October 15, a good place to start. You are welcome to use that code or other properly attributed code as a base for your project. (But remember that the work done to complete the basic requirements of the project must be that done by you and your partner, not someone else. Specifically, modifying code from someone else's Aquarium or Airplane simulation from previous quarters and turning it in as your own is not allowed, and we will be comparing projects from this quarter with the projects from previous quarters looking for duplicates.)

Testing

You should retain the JUnit tests from part A and run them every now and then to be sure that any changes you make to the code don't introduce bugs. You should also add tests to check significant new code. One way to test something like a 45 degree turn would be to have the test execute a loop that calls the action() method a sufficient number of times, and verify that the dino does turn properly.

If you choose to put your dinosaur controllers in classes separate from the Dinosaur class, write JUnit tests for the controller classes as well.

Minimum Requirements

This project is very open ended, with plenty of opportunities for creativity and extensions. But your project should meet the following minimal requirements:

  • There must be at least three distinct kinds of Dinosaur in your class hierarchy (this was a requirement of part a) and at least one instance of each of these classes in the animation.
  • Each Dinosaur object must have an action method that applies to it, either
    1. implemented in the Dinosaur subclass in question, or
    2. implemented in a controller class associated with this Dinosaur subclass, and where an instance of the controller is associated with this Dinosaur object.
  • At least some of the Dinosaurs in the simulation should have relatively smooth motion, turning, and changing speed gradually. If you want to have some additional kinds of motion in other combinations (sudden jumps and turns, etc.), that's fine.
  • There must be some sort of interaction between some of the objects in the simulation. For instance, dinosaurs might eat food that they find (other dinosaurs or plants), dinosaurs who get near to each other might form a heard that moves together, or whatever your imagination can come up with.
  • Your program must be based on the Model-Viewer architecture, with as minimal a coupling between parts as possible. In particular, your Dinosaur objects (and their controller objects, if any) should calculate and store positions using "real world" coordinates (feet or meters), not pixels. The conversion from real coordinates to screen coordinates must be done by the viewer object (the one dealing with the graphics).
    [Exception to the strict separation between model and viewer: You may augment the Dinosaur classes so they can draw themselves on a Graphics object at coordinates supplied by the viewer when requested, similar to what was done in the bouncing ball demonstration code.]
  • You should retain the JUnit tests from part A and add a few JUnit tests to verify that the control of the Dinosaurs works as expected.

Possible Extensions

Some amount of extra credit will be awarded at the final end of the project for particularly impressive technical, artistic, or other extensions that go beyond the basic requirements. Here are some possibilities to get your imagination going - but you don't need to limit yourself to these

  • More realistic Dinosaur behavior
  • Food - dinosaur eating plants or other dinosaurs; dinosaur energy levels, dinosaur hunting for food
  • Interactions between objects in the simulation - Dinosaurs walking in herds or chasing each other, running away from predators, falling in to tar pits, etc.
  • Interesting scenery, things for Dinosaur to walk through
  • Population dynamics and growth, with males and females, juveniles and adults, where dinos make nests and lay eggs, whatever you want.
  • Graphical images for Dinosaurs and other items in the simulation (you may find it worth learning Java2D if you want to do sophisticated things like rotating images)
  • Storms, tidal waves, earthquakes, volcanoes, a representation of the ice-age, other natural or man-made events
  • Spaceships, alien abductions, etc.

You might also start thinking about extensions you could make when user input (keyboard, mouse, etc.) is added in the final part of the project, in case that influences your decisions about what to do now.

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 suggested if you are planning to add extensions. 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.