When trying to program collision detection it was essential that the reptile class include the ListControl class so as this was where the plant list was made and stored and the reptile needed a pointer to the plant class in order to know the positions of a each plan and test them against it’s own. But the Reptile class also needed to be included in the ListControl class so as it could declare and draw a Reptile. This caused this error to be thrown :#include nested too deeply. It was thought initially that this was a constraint of C++ and many solutions where attempted which involved getting round this, but all these attempts led back to this error, it was then found that actually there is a solution described here: http://stackoverflow.com/questions/396084/headers-including-each-other-in-c
This will be fully described at a later date.
The next objective was to get a second organism into the environment which would evolve, these would be the main focus of the project as the plants are essentially a food source. These creatures would represent the reptiles. Time was spent investigating how to program organic looking motion and deliberating about how to make the reptiles move round the environment when they where not really doing anything. It was decided that the best way to do this was to give them a set of rules much like other algorithms which simulate biology which would control what they did so for example if they were hungry they would go looking for food. This would mean that they would always have a purpose and would not just be moving aimlessly.
Time has also been spent planning how the classes will fit together as it will make the program a lot more elegant and cut down the amount of work to use inheritance. So there will be a generic node from this reptile and plant node shall be derived.
A more up to date UML class diagram has been drawn by hand.
The next task is collision detection as this was essential to the reptiles eating as the program would have to know when they encountered a plant. So Reptiles need to be implemented in the environment with a member function which tests when the collide with plants.
When making the animals in the environment the problem was encountered of how to give them motion which is; natural looking, random (to start with) but with purpose, e.g. moving in order to find food.
Work has been done on a draft report, an introduction and background chapter are complete (drafts). The introduction to along time to write but this is the most important chapter in the report as it is the first thing that will be read. The introduction should be used to grab the readers attention and inform them about the rest of the report.
A draft background chapter had already been written but this needed to be modified in order to put forward an argument, showing what had been done previously and what ReptileX would do that others have not.
One of the key parts to simulating evolution is organisms need to die, this is because in nature animals that have disadvantageous mutations will not survive and only the fittest organisms that are best adapted to their environment will.
There are two aspects to this: Firstly the visual aspect this is what the user will see in a game an animation of the player dying is usually triggered but on the simplest level this is to just make the dead plant no longer visible. Now the project thus far was just doing this, ceasing to draw the plants when they where dead, but there is still one problem with this the object its self needs to be deleted or there will be a memory leak, that and that death is a key part of evolution.
First it was attempted to kill the plants in the environment as once the logic for this was implemented it could be easily used for the animals.
So just to recap the plants are kept in a linked list, this is a data structure made of objects linked by pointers each one points to the node in the list and the plants currently have a boolean variable which becomes true if they are dead. As each node is an instance of an object which is defined using struct it is possible to implement member functions which will be accessible by every node. It was first attempted to delete the plant within one of these functions if it was dead and then make another boolean true. Then in the function that went through each node and called the functions of the plants they held it could be tested if any node held a dead plant. This approach was incorrect as everything needs to be deleted in one go or the program would through the error BAD ACCESS (INSERT REASON WHY).
So to delete everything in one go when the node holds a dead plant delete needs to be called on that node this calls it’s deconstructor. A deconstructer is used to delete everything that is no longer needed once an object goes out of scope. So in the deconstructor for the node the delete must be called on the plant it holds and anything else that is not needed. Now it was thought that any pointers made needed to be deleted in order to be deleted in the decontructors so as they where not just left once the object was out of scope. So this is the deconstructor for the node:
plantNode :: ~plantNode
and for the plant:
Plant :: ~Plant
It was decided to carry on with the rest of the program before the problem was finally fixed. So an animal class has been made and animals can be created which move (randomly) this will represent a generic reptile. But it needs to be able to interact with the plant objects in order to eat them which involves collision detection
The problem discussed in the previous log has now been fixed and is discussed in more detail here: Log 18/03/2012.
This put back development slightly but this was an integral part to the project and a hard concept to be grasped. Now this hurdle has been passed things will hopefully move more swiftly.
Work has not progressed as much as it was intended to by this point, in the post: tasks to complete for 20/03/2012 it was stated that to complete a complete demo for presentation there where six tasks.
A problem was encountered with the first task make plants die from old age. There are two aspects to this: Firstly the visual aspect this is what the user will see in a game an animation of the player dying is usually triggered but on the simplest level this is to just make the dead plant no longer visible. Now the project thus far was just doing this, ceasing to draw the plants when they where dead, but there is still one problem with this the object its self needs to be deleted or there wil be a memory leak, that and that death is a key part of evolution. The problem encountered was because this involved deleting the node in the linked list which held a dead plant, deleting the plant itself and relinking the list afterwards.The problems where with getting the order and right and making sure the wrong things did not go out of scope. This problem is discussed in full detail here (INSERT LINK). This is an ongoing problem which is yet to be solved….