CompSci 108
Spring 2009
Software Design and Implementation

Animation : Flocks

Leaderless flocks of animals may, at first, seem baffling: how can a large group of animals all move as one if there is no one to tell them where to go? Understanding these systems has long been a goal of artificial life researchers. It is now believed that although a school of fish, a pack of herd animals, or a flock of birds looks like a very complex system, it based upon the interaction of a number of simple rules. In 1986, computer animator Craig Reynolds simulated basic flocking behaviors with only a few simple rules: cohesion, alignment, and separation.

Since then, these effects have become common place in simulations, games, and movies: starting with Disney's The Lion King and continuing through movies like The Matrix, The Lord of the Rings, and Narnia series. When Disney started, they made completely separate programs to animate a herd of stampeding wildebeests, a crowd of dancing people, and an army of attacking huns. Only later did they, and others, realize how to generalize these techniques so that the crowds could be built from any type of character, each behaving uniquely enough to not raise suspicion, but all following the same set of rules to produce an aggregate effect. One company now leads all others and it has become cheap enough that they make commercials using crowd simulations, like this one.

Specification

Work in pairs to write a Java program that simulates a variety of flocks moving within an empty world. Multiple flocks with different rules should be able to animate within the same graphical world. How the flocks deal with the world's boundaries should be configurable by the user, e.g., bounce off, pass through to the other side of the world (as if it were a flattened torus), or ignore them completely.

Individuals members of the flocks can be limited to specific shapes, like ovals, or with images. If you choose to use images, users should be able to select an image to represent the individuals within the flock.

Users should be able to control what rules are active within the members of the flock and change various values within those rules while the simulation is running. The user interface should provide a variety of controls to help the user experiment with their flocks to observe the complex aggregate behavior that emerges. Different kinds of rules might provide different kinds of values that can be set, so the user should be able to save and reload a specific set of rules (and their parameters).

Users should be able to add individuals, entire flocks, or clear the simulation while it is running.

Design Goals

Your goals for this project are to avoid the mistakes made by the software engineers at Disney in the nineties by providing a general engine for animating any number of characters with a variety of behaviors.

Others will use your animation engine for the next assignment. Thus your project should be packaged and documented such that others can use it without needing to consult with you.

Extensions

There are many extensions to the basic specifications. Since an important goal of this project is to demonstrate the flexibility of your animation engine, you must do at least three such extensions if you want to be considered for a grade in the A range (doing just the basic program is worth at most a B).

These extensions must further the good design of your program and not simply be hacks of code added at the last minute. If you do not have time to implement an extension, partial extra credit may be given for excellent justification of how your design either supports adding such a feature already or how it would need to changed sufficiently to support such a feature.

Some suggested extensions follow; most of these hint at future functionality that will be used in later versions of the project:

Finally, producing a well-tested program will be considered extra credit since testing graphical programs is not well supported in Java.

However, note that the amount of extra credit will be in proportion to the amount of intellectual effort needed to implement the option. Of course, a well-tested, perfectly working program that has fewer features (but plenty of clear paths to easy expansion) is always worth more than the leaky kitchen sink.

Deliverables

  1. Tuesday, March 17.
    Email me your preferences for your final project partner (and anyone you do not want to work with).
  2. Thursday, March 19. Submit a README containing the address of your website that contains:
    1. a name for your team's "company"
    2. a description of your team's shared vision of the project, specifically what required and extra credit features your team is most interested in implementing
    3. issues that arise as you try to pin down the requirements, e.g., vague, ambiguous, conflicting requirements, or concerns that you have about specific features
    4. an estimate of how long this project will take your team to code this project
    We will check this page frequently to check on your progress, so you will need to update this web site as you develop your project.
  3. Tuesday, March 24. As a minimum, your program should be able to
    1. view a hard-coded flock moving through the world
    Create a web site that includes documentation for the current implementation.
  4. Saturday, March 28. The final program and documentation site must be ready. No reflection is necessary for this project.