Designing our Simulation System
So far, the design of the simulation system has been determined for you. This week you'll start to design a system yourselves based on some specifications, interfaces, and parent classes.
Documentation for Java 1.5 is located at: Java 1.5 SE API.
Documentation for Java 1.6 is located at: Java 1.6 SE API
You need to design a system for simulating entities on a landscape. Conceptually, the landscape should be a continuous planar surface (not a grid of boxes).
The Landscape should contain three kinds of things: Agents, Resources, and Obstacles.
- The Landscape is a collection, or perhaps three collections, and does not know anything about the particular objects it contains. The landscape knows about spatial relationships and must implement various methods that query the spatial relationships of things on the landscape.
- An Agent can move about the landscape. An agent can collect or harvest resources, but cannot move into or through an obstacle. The Agent determines its own actions and can interact with other Agents. An Agent needs to keep track of its resources.
- Resources are things an Agent can manipulate, trade, create, or deposit. Resources generally cannot move, but they do keep track of their current situation and may change their state or status over time.
- Obstacles are spaces on the landscape that Agents and Resources cannot occupy. For our simulations obstacles will be either circles or rectangles. In general, an obstacle must be able to specify if a location is inside or outside its area. Obstacles might move.
Using the above four base types (parent classes or interfaces), we will write a generic Simulation class that iterates over time, updating the landscape. The Simulation should know nothing about the specific rules for Agents, Resources, or Obstacles, and should use nothing but methods defined by the appropriate interfaces or parent classes.
This week we will begin the process of defining the task using a top-down design methodology. We will start by designing the Simulation parent class, which will help us to design the interfaces and parent classes for the base data types. The goal this week is to develop a design only. Throughout the design process, keep in mind that the system should be flexible enough to implement any of the prior three scenarios.
Create a brand new Simulation class. This class will be the parent of
all simulations. The simulation class has to be able to do four
- Initialize a landscape. There should be a default behavior (e.g. the game of life), but each simulation child class will overwrite this method to set up different simulations.
- Execute one iteration of the simulation. This function should be generic for any simulation. It should execute an update on each obstacle, an update on each resource, an update on each agent, and a post-update on each agent. We'll talk about this in lab.
- Display the current state of the simulation and pause for a given amount of time. The simulation should not know anything about how to do the mechanics of the update except call the appropriate method on the appropriate object.
- Run the simulation in a main function. You can avoid writing new main functions in your child simulation classes by have a system that selects which simulation to run based on command line arguments.
- Focusing on the Initialize and Iterate methods of the Simulation, plan out what methods the Landscape (class), Agent (interface), Resource (interface), and Obstacle (interface) classes or interfaces require. We'll go over this in lab. After a collective design phase, I'll link the three common interfaces here. You are welcome to add to the interfaces to implement extensions, but you cannot subtract from them.
- Agents, Resources, and Obstacles should know how to draw themselves. Add draw functions to your design and think about how your system should pass around the appropriate information. Each of these things, for example, needs to know where to draw itself and how big to make the drawing. Only the landscape display class knows anything about the scale of the display and the relationship of the viewing window to the Landscape coordinates. Use this LandscapeDisplay class to design your system.
- Your task this week is to write an initial version of the Simulation class, a skeleton Landscape class (methods and fields, but no code), and the three interfaces. You should be able to compile your simulation class, but it won't do anything yet. Your writeup will be your primary output, as it will explain your design and the functionality of the methods defined in the interfaces.
- Complete a simple simulation, such as the social simulation from lab 2, using your new system. Something even simpler is to have the agents just wander randomly around the landscape.
- Designs that are exceptionally well presented will receive extension credit.
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. Your overall design is what you want to describe this week. This is a design document from which you will build a system. Make sure it has enough detail so that when you sit down to write the code it is clear what you want to do. Any extensions you did are interesting.
- Printouts, pictures, or results to show what you did. You can do screen captures of your terminal to show the initial and final landscapes.
- Other results to demonstrate extensions you undertook. If you tried different update rules, for example, show how those affected the overall simulation results. A graph of the number of Entities over time would also be helpful.
- A brief conclusion and description of what you learned.
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 on the Academics server in your folder within the COMP/CS231 directory.