Flatland Simulation

Flatland has a bug problem, that is, it needs bugs in order to be ecologically balanced. To help study the problem, you are to create a simulation of bug life in Flatland. Specifically, you are to provide and use a C++ class that models a Flatland bug. The bug class must have the following private attributes for a Flatland bug object:

• an integer x location
• an integer y location
• a maximum range value for an x location
• a maximum range value for a y location
• the alive state of the bug (i.e. whether the bug is “alive” or “dead”)
• the gender of the bug (Note: Only two genders are possible!)

The bug class must provide at least the following public constructors:

• A default constructor that accepts no arguments and sets the bug created to “dead”.
• A parametrized constructor that accepts the maximum across value and the maximum up value of possible bug locations and stores this information for later reference, then assigns random x and y location values within the range maximums. The minimum location is [0,0]. The constructor must also randomly assign a gender to the bug, and finally it must set the bug to “alive”. The bug class must provide the following functionality in public methods that:
  • returns whether the bug is “alive” or “dead”
  • randomly moves an alive bug one step in one of the 8 possible directions, but only if the move leaves the bug within range
• a method, that when called and if the bug is alive, sets the bug to dead 50% of the time that the method is called (such as when someone is trying to stomp on the bug)
• returns the gender of the bug
• accepts as a parameter an object of the bug class and determines if the bug object calling the function and the bug object passed as an argument have collided (i.e. occupied the same space and are both alive); if the bugs are alive and of the same gender, both bugs die and false is returned; if the bugs are alive and of different genders, true is returned (when true is returned, which is the signal for two additional bugs to be created at random locations by code in the calling function)
• Use the bug class to create a simulation of bug life in Flatland in main.cpp (or whatever you called the file containing the function main).
• At the start of the program, the size of the area that the bugs inhabit in Flatland (the maximum X and Y values that define Flatland), the number bugs that are to exist at the beginning of the simulation and the number of iterations that the simulation is to run are all to be read from user input. Additionally, the user is to input the name of the output file (see more information below).
• All bugs are stored in a dynamic single dimension array of type bug. The size of the array is to be determined by the number of rows times the number of columns in Flatland.
• During each iteration of the simulation, all alive bugs must move and one unlucky but as yet alive bug (randomly chosen) is stomped on (an event that is fatal to the bug 50% of the time), collisions must be detected and if the colliding bugs are of different genders two additional bugs to be created at random locations.
• At the end of each iteration of the simulation, output to a file (also to be chosen by the user) the number of alive bugs, the number of male bugs that are alive and the number of female bugs that are alive. (Note: Only one output file is necessary!)

Programming Tips

• Create the bug class definition (in a .h file) and implementation (in a .cpp file) first, then in the function main, create a bug object and call all methods until you are certain that bug class works correctly. Only then should you move on to creating the problem solution.
• Create the bug class definition in a .h file as in the following example:

#ifndef BUG_H
#define BUG_H
... includes and namespace, if necessary here ...
... class definition here ...
#endif

• Create the bug class implementation in a .cpp file as in the following example:

#include “bugclassdefinitionfile.h”
... other includes and namespace, if necessary here ...
... class method implementations here ...

• In the main file (file with the function main), don't forget to include the class definition file.
• When the array of bugs is created, the default constructor of the bug class will be called for each element of the array. Loop through the array and initialize each bug using the parametrized constructor in an assignment statement.
• To generate random genders and locations, use the void seed(unsigned int) and int rand() functions. This requires that you include the libraries ctime and cmath. To produce random numbers, once and only once in your running program, call the seed function as follows:

srand((unsigned)time(NULL));

• Then, each time you need a random number, call the rand function and modulus by one past the upper limit. For example, to generate an integer from 0 to 5, call rand modulo 6:

int n = rand() % 6;

• to examine all possible bug combinations (for collisions, etc.), use nested counting loops to generate unique pairs of indexes in the way that such pairs were generated in the brute force sort example. For example:

for (int a = 0; a for (int b = a + 1; b < elementsInUse; b++)

Additional Requirements

• The bug class must be written such that bug instance object variables truly function as independent objects, i. e. each bug instance object variable truly maintains its own state after initialization without dependence on variables or values passed to methods or assigned to public variable members.
• The data output to the file must be readable.
• Your program may have global constants but may not have global variables.
• All free functions other than function main must have prototypes (forward declarations) before the function main and implementations after the function main.
• All function prototypes (forward declarations), class method declarations and constructor declarations must include a comment containing a brief description of the purpose of the function.
• Indention of all code blocks (compound statements), including single statements following selection or while statements, is required.
• Identifiers must be descriptive, i. e. must self document. The only exception granted is simple “for variables”, i. e. variables created as simple counters as the control variable in a “for” loop statement.