Colby across Johnson Pond
CS 231: Data Structures and Algorithms
(Fall 2013)

Syllabus

Teachers
Lanya
Tyler
Hieu
Bilal
Scott
Terrence
Charles
Matt


Assignments


Other Pages

Project 5:
Predator, Prey, and Obstacles


Assigned: Mon Oct 07 2013
Due: 11:59:59 PM on Mon Oct 21 2013
Team Size: 1
Language: Java


Lab:

  1. Re-implement your LinkedList class as a doubly-linked list with a head and a tail pointer and prev/next pointers at each node. It should have the same functionality as the original LinkedList.

Assignment:

The goal of this project is to enable you to create your own simulation that incorporates the idea of predator (consumer), prey (resources), and obstacles (places an agent can't go). Continue to use the design framework from project 4, but create a more complex set of agents in inhabiting the landscape together.

Documentation for Java 1.6 is located at: Java 1.6 SE API


Problem Description

The goal is to create a balanced simulation with three types of agents: consumers, producers, and obstacles. For example, the consumers could be broccoli fiends, the producers could be broccoli plants, and the obstacles may be fences. You can choose your own scenario (zombies and plants, hobbits and mushrooms, etc.).

At a high level, the consumers need to get broccoli from the plants or their health goes down. If a consumer's health gets too low, they die and are removed from the simulation. Producers make broccoli at a certain rate over time, but may die from overharvesting, and obstacles block consumers from moving inside them. Both the broccoli plants and the broccoli fiends should create new plants and new fiends when the conditions are right. Plants don't move much, except when they split off from their parent plant; fiends move around when they don't have much to eat in their local neighborhood, and sometimes they move even then.

Continue to use the concept of a 2D Landscape with agents representing their location on the Landscape as continuous variables. A Landscape should support agents and obstacles. While you can hold both agents (Cell child classes) and obstacles (also a Cell child class) within the same list, it may be easier to separate the two so that obstacles can be accessed separately from agents.

  • An agent is any class that extends Cell. An agent can move about the landscape. An agent can collect or provide resources (possibly both), but cannot move into or through obstacles relevant to that agent (some agents may be able to pass through some obstacles). The agent determines its own actions through the updateState method and can interact with other agents nearby. An agent needs to keep track of its current resources. An agent does not necessarily move.
  • An agent can be a resource for another type of agent. For example, broccoli does not move, but grows in value over time unless harvested. Squirrels move, but might be eaten by a hawk, providing resources for the Hawk, but removing the Squirrel agent from the simulation.
  • Obstacles are a Cell subclass that represents an area on the landscape one or more types of agents cannot inhabit. The simplest obstacles will be circles or rectangles. In general, an obstacle must be able to specify if a location is inside or outside its area. Obstacles might move.


Tasks

  1. Plan out your simulation. Select a consumer, a producer, and an obstacle and plan out the rules for each. Then build a subclass of Cell for each one that implements the concept. You may want to add additional abstract methods to the Cell class to guarantee that all of the different sub-class types implement a minimum set of methods.

    You are free to create an interface for an Agent and an interface for an Obstacle as well, if you wish to use that method of defining a set of common functions.

  2. Write the individual agent classes. As you write one class, you may want to test it out to see if it is behaving correctly in the absence of other agents. For example, broccoli plants should grow in health and make new plants; broccoli fiends should start out numerous, shuffle around, and quickly die away with no broccoli to eat. Obstacles should draw their extent and just sit there.
  3. Make sure each different individual class draws itself in a unique, easily identfiable manner (get creative).
  4. Update your Landscape class code as you update the individual agent classes. You may want to have separate lists for agents and obstacles, and separate accessor methods, since you'll need to loop over the list of obstacles any time an agent moves.
  5. Add an initialization function to the Landscape that generates appropriate initial conditions. You'll need to experiment.
  6. Update the main method in LandscapeDisplay to call the Landscape initialization function and start running the simulation. Enable it to save each step of the simulation to a file so you can create an animated GIF.
  7. Run your simulation for 100 iterations. Do this several times. Include in your writeup a fairly small simulation that demonstrates the system is functional and working correctly.

Extensions

  1. Do more than one set of simulation rules.
  2. Get extra creative with the visualizations of each agent type.
  3. Show experimentation with different rules and how these changes affect the simulation.
  4. Implement an additional data structure you haven't implemented before, such as an ArrayList.
  5. Give each Agent a unique ID and keep the linked list sorted by ID. Does this assist any of the operations?
  6. Focus on speeding up the simulation. What can you do to make it faster? Show before/after timing to demonstrate your speedups.

Handin

Before handing in your code, double check that it is well-styled:

  • All variable names and function names use camelCase.
  • All class names are in PascalCase.
  • All public classes and methods use complete JavaDoc.
  • All private class members (fields and methods) have their own descriptive comment (but not JavaDoc).
  • Comments are added to explain complicated code blocks.
  • All variable and function names are appropriately descriptive.
  • All indenting and squigly-braces are properly placed.
  • Each concrete (non-abstract) class should have a unit test (main method) that calls and tests all methods in the class.

Make your writeup for the project a wiki page in your personal space. If you have questions about making a wiki page, stop by my office or ask in lab.

Your writeup should have a simple format.

  • A brief description of the overall task, in your own words.
  • As explanation of your solution, focusing on the interesting bits. The interesting bits here are how you modified the basic design and implemented different simulations.
  • Printouts, pictures, or results to show what you did. For this assignment, include your animated GIF movies.
  • Other results to demonstrate extensions you undertook.
  • A brief conclusion and description of what you learned.

Once you have written up your assignment, give the page the label:

cs231f13project5

You can give any page a label when you're editing it using the label field at the bottom of the page.

Do not put code on your writeup page or anywhere it can be publicly accessed. To hand in code, put it on the Courses volume in your folder within the COMP/CS231 directory.