The goal of the course project is to solidify the foundational C++ knowledge obtained in this course by desinging and implementing a functional, larger-scope software system. The project topic has been chosen to necessitate the use of a wide array of language concepts and features we studied/will study, including separate compilation, user-defined types, inheritance, run-time polymorphism, resource management, smart pointers, containers and algorithms, file input/output, and other standard library facilities. We haven't covered some of these topics in details yet, but, generally speaking, you should be able to start working of the project right away.
Note that the project definition includes a couple of "stretch goals". Those are optional enhancements on top of the core project that you might choose to explore to obtain extra credits (or perhaps simply because they seem fun).
The project due date is midnight, Wednesday, May 1st. Late project submissions will be subject to a penalty of a 25% reduction in points for every 24-hour period they are late.
As per the syllabus, the project constitues 30% of your total grade. The project's grade itself will be a function of the following criteria:
| Project Evaluation Criteria | Grade percentage | Explanation |
|---|---|---|
| Functional requirements | 50% | Does the delivered software satisfy the project's stated functional requirements? |
| Quality of the final executable | 15% | Absence of errors during the normal execution, as well as graceful handling of error conditions. |
| Quality of the design and implementation | 15% | Is the project implemented using idiomatic, well-structured C++? |
| Test coverage | 10% | Usage of unit/functional testing to assist project development. |
| Weekly project updates | 10% | See below. |
To help facilitate a healthy development pace, you are required to submit (on Slack) weekly project updates which answer the following questions:
- What have you done on the project so far?
- What are you currently working on?
- Are there any unsolved issues/errors you’re currently trying to debug?
The weekly updates are due at midnight every Wednesday, starting from Wednesday, April 3rd, up to and including Wednesday, April 24th.
If you have any questions or concerns, please reach out as soon as you develop them. Regular demos/office hours visits to discuss your progress are essential for avoiding surprises with your final project grade.
Due to the long-running nature of this project, we'll be using Github (https://github.com) to host the project's code and track your development progress. If you don't have a Github account, please create one using your @uiowa.edu email address. If you have an existing Github account you'd like to use, please make sure your @uiowa.edu email is listed as your public email.
Once you are logged in to Github, follow these instructions to create a private repository for your project, then invite @agurtovoy and @srinvsn as collaborators.
When reporting progress in your weekly updates, please make sure to push the corresponding code to your Github repo. Failure to do so consistently will affect the "Weekly project updates" portion of your project grade.
Use of Github issues and wiki functionality to track & document your project state is welcome and encoraged.
The project objective is to build an interactive command line program that (crudely) simulates a small terrestrial ecosystem according to the rules below.
The core notion of the simulator is that of an iteration: a single "step" of the simulation during which the ecosystem transforms itself to its next state according to its rules (think Conway's Game of Life).
An ecosystem is defined by two inputs:
- a rectangular map of the area that describes the (initial) location of the geographic features and the living organisms (plants + animals) that populate the area;
- a list of species populating the ecosystem, together with their essential characteristics and inter-relationships.
The ecosystem map and the list of species are loaded from the corresponding files provided to the program as command line arguments.
Runing the simulator starts a new simulation session. Within a single simulation session, the user can select to run a single iteration, or a "batch" of several iterations at once (e.g. 10 or 100 iterations). After each run, the simulator prints the session's current ecosystem state to the console. The user can then choose to continue the simulation session (by doing another run), save the current ecosystem state to a file, or exit. If a user who ran at least one iteration chooses to exit, they are asked whether they want to save the current ecosystem state to a file before exiting.
Saving the current ecosystem state to a file simply means saving the current state of the map to a file. This means that things like the animals' current energy levels and the plants' regrowth states will be reset to their initial values when the user saves and then "restores" the state by using the saved map to start a new simulation (but see this stretch goal).
- During each iteration every organism in the ecosystem gets a chance to perform its living functions (move, grow, consume). Plants get their turn first, then the herbivores, then the omnivores, then the cycle repeats at the next iteration.
- Animals move freely around the ecosystem to find food, but they cannot move over the geographic obstacles, plants or other animals (unless they are consuming them). All animals move with the same speed (one block per iteration).
- Plants remain static and don't spread into new areas.
- Each living organism has an associated number of "energy points" it gives to the organism that consumes it.
- Plants don't eat other organisms; herbivores eat only plants; omnivores eat plants and other animals.
- Plants that have been eaten regrow in the same location according to their "regrowth coefficient"; for example, a plant with a regrowth coefficient of 2 regrows in two iterations. A plant cannot regrow if its location is currently occupied by an animal.
- Animals that have been eaten are removed from the similation.
- Each animal has a current energy level as well as a "max" energy level that limits the number of energy points they can absorb. All animals start the simulation with a current energy level equal to their "max" level. Each move subtracts one point from their current energy level. An animal with zero energy points dies and is removed from the simulation.
- An animal can consume another organism only if it can add a greater-than-zero number of the consumed organism's energy points to its energy level without going over its "max" limit. To consume another organism, the consumer has to move to the organism's position.
- Two adjacent animals of the same species with the current energy level that is more than a half of their "max" can produce an offspring (given that there is space next to either of them to place the offspring).
- Animals act in their own interest: e.g. if an animal is in danger of being eaten, it'll try to escape, if it's running out of energy, it'll seek to replenish it, etc.
Add an option to programmatically generate a map of a certain size based on the list of species and possibly other parameters (e.g. area percentage for the geographical features).
Collect the population statistics (number of live organisms for each species) on each iteration, allow user to save the accumulated session stats as a CSV file that can be graphed by 3rd party software (e.g. Excel).
Add an ability to save the full ecosystem state, including current energy levels, regrowth states, etc., to a separate file (complimentary to the map/list of species), and an ability to load the saved state into a new simulation session if it's been provided as one of the command line arguments.
When an animal with 10 energy points is “eaten” by an animal that is at 26 out of 30 max points so it only takes 4 energy points, is the first animal still alive with 6 points or is it dead?
It's dead.
Yes, but if you do want to introduce a coefficient for this to see how it affects the simulation, please go ahead; I'll take enhancements along these lines into consideration when grading.
No, but see above.
Yes, see, for example, line 5 of species.txt. This enables us to specify circular food chain dependencies (species A can eat species B and species B can eat species A).
No.
The map is the only absolute requirement, but feel free to print out anything else that you find useful/interesting. You can also print the map by default, and add an explicit command to print the extended state.
The specific algorithm is up to you, but see ecosystem rule #11. You can still introduce an element of randomness to this — e.g. an animal that is in danger might from time to time get “distracted” and get eaten anyway.
Do I need to test my simulation with any other data other than what's provided in the input directory?
Yes, it's both required and highly recommended to use a variety of inputs (correct and incorrect) to fully explore the system's behavior as it's being developed. You are also welcome to include interesting cases of highly stable or otherwise unsual ecosystems as a part of your project submission.