Predator, Prey, and Obstacles
The goal of this project is to enable you to create your own simulation that incorporates the idea of predator (consumer, an agent), prey (resources, also agents), and obstacles (areas agents can't enter). Continue to use the design framework from project 4, but create a more complex set of agents that will be inhabiting the landscape together.
Here are the links to the API's for the most recent versions of Java:
The goal is to create a balanced simulation with three types of classes: 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 an object that occupies a single point which can (potentially) 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). An Agent class should extend the Cell class. 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.
- An Obstacle is 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.
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 or abstract class for an Agent and an interface or abstract class for an Obstacle as well, if you wish to use that method of defining a set of common functions.
- Update your updateState method so that it no longer has the list of neighbors as its input. The list of neighbors is not something you will, in general, need. Instead, each agent will need access to the Landscape itself. You can give it this access by including the Landcsape as a field in Cell or by adding it as a parameter to updateState.
- 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.
- Make sure each different individual class draws itself in a unique, easily identfiable manner (get creative).
- 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.
- Add an initialization function to the Landscape that generates appropriate initial conditions. You'll need to experiment.
- 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.
- 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.
- Do more than one set of simulation rules.
- Get creative with the visualizations of each agent type.
- Show experimentation with different rules and how these changes affect the simulation.
- Implement an additional data structure, such as a skip list.
- Give each Agent a unique ID and keep the linked list sorted by ID. Does this assist any of the operations?
- Focus on speeding up the simulation. What can you do to make it faster? Show before/after timing to demonstrate your speedups.
Make your writeup for the project a wiki page in your personal space.
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. Your simulation design and the rules you developed are interesting. Any challenging functions are interesting. How you figured out appropriate values for your rules is interesting. Any extensions you did are interesting.
- Pictures, movies, or results to show what you did.
- Results to demonstrate extensions you completed. If you tried different update rules, for example, show how those affected the overall simulation results.
- A brief conclusion and description of what you learned.
- A list of people you worked with, including TAs, and professors. Include in that list anyone whose code you may have seen, such as those of friends who have taken the course in a previous semester.
Once you have written up your assignment, give the page the label:
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 in your folder on the Courses fileserver. Create a directory for each project inside the private folder inside your username folder.