Category Archives: Log

Log 05/05/2012

The project report is finished.

The drawing of the plants has been slightly advanced using a simple algorithm which uses lines to draw what looks like blades of grass which slowly sway. Thus greatly sped up the program and allow for a lot more plants to be drawn and it to still run smoothly. Up until now spheres had been being used and these take up a lot of computational power.

Reptiles can only eat plans within their own height range and there are two tarting populations of plants of two different heights. The reptiles all start with random heights, this is is on order to be able to see an evolution of reptiles to be able to eat plants of a certain height. This has not been tested properly and there  is a new problem of now multiple invisible plants which kill the reptiles and in the end cause extinction. Biut tit has been tied up ready to hand in.

At the last minute the deadline was extended until the 8th of May so this will give time to do a little more testing, sort out these errors and proof read the report.

Log 01/05/2012

As was stated in the previous post in order for the program to work the reptiles population needed to be sustainable for a number of generations. There were many factors that could have been affecting this so a number of steps were taken.

A spreadsheet was made to get an overview of all of the variables and how they were working together, as in order to be have a population which could be sustained over a number of generations a balance needed to bed struck between the number of plants, the number of reptiles, the flow of energy and all the other affecting factors.

Firstly collision detection was implemented for the reptiles this simply involved overloading the function which detected collision with reptiles and took a plant node as an argument to take a reptile node as an argument. This would allow it to search through the reptile list and check for collision with every other reptile. The reptiles need to check that they are not looking at themselves when checking for collision as they are all in the same list.

It was found that one of the problems was the reptile population was not growing quick enough, this was partly because each reptile was currently only able to have one baby so it was made possible for them to breed a number of times in there lives with a gap after each time.

There were still errors remaining and this was now the main reason the population was growth was becoming stunted. There was the invisible plant which was trapping all the reptiles which was the main problem but also reptiles seemed to sometimes disappear . After much painstaking debugging it was found that some how the initialisation of the root of the plant list was no longer happening after the start population had been implemented. This was meaning it was not drawn with any size but had a position and this was what the reptiles were getting stuck on. The problem with them disappearing was that when a reptile went towards a plant of a different size than itself it would accelerate in the y direction and fly off, so when heading for food or mates the y part of the acceleration vector had to be zeroed.

With these errors fixed it just took some tweaking of the lifespans energy transfer etc… to get a population of reptiles which laste for a number of generations. The next task was to test some simple evolution and finish up the report for hand in.


Forage, bask() and findMate() have now all been put into the behaviours function with the correct operators and work together apart from the problem of the invisible plant which they all get stuck on. This is getting more of a problem because the reptiles population is being stunted by it.

The timer so far was only counting virtual days and the organisms’ age was only in days as well. It has been now fixed to count years as well using a given year length, the organisms ages ar now counted in years as well, this will make the program much easier to control.

The aim is to get a steady population of reptiles which does not die out at least for a number of generations as currently the last no more than two generations. This is imperative to the development of the project.


Log 23/04/2012

Each organism in ReptileX is stored in a node of a linked list each node has aplace number but as the nodes are deleted and relinked when organisms die these change. Mainly for debugging purposes a number was needed which could be used to uniquely identify each organism. Soi each organism was given a model number which was stored in the node and the reptile class itself. This number is assigned when the reptile is first made and then not changed.

Now the reptiles were mating and having babys, up to this point all of the behaviours had been implemented separately and tested in isolation. In Log 30/03/2012   it was stated that a good way to simulate the biological process would be to give the reptiles a set of rules controlled by logical operators. Fig 1 shows a plan for an algorithm which would control this the basic logic is that the reptiles chooses a behaviour to perform in order of importance to the organisms survival so it is most important that the reptile eats, the next most important is keeping warm etc.


So a behaviours function had to be written which implemented this algorithm using if statements to choose which behaviour function to call. So firstly a boolean called hungry was set to become true once the reptiles stored energy was too low. But when forage was turned back on there was a problem, the reptiles would after some time had passed all start to go to eat a plant which as not there and then get stuck after a while more and more reptiles would do a similar thing and all start dying. This problem is ongoing but as it does not stop the program running it is still partially testable.

Next the boolean called cold which was turned on and off depending ton the reptiles body temperature was used so the reptile would check, if it was not hungry, if it was cold . and then it would call the bask function if it was. The problem mentioned in the previous post  where making the body temperature affect the reptiles speed had slowed them to a halt was solved. what had been happening was the speed was being multiplied by say 0.7 every frame that there body temperature was below a certain amount :

speed *= 0.7

using *=  like ++ will make the variable, in this case speed, equal itself multiplied by 0.7 each frame so the value of speed will slowly decrease bringing speed closer and closer to 0 and therefore slowing the reptiles down to a halt. The solution for this is to keep the speed the reptile has as an attribute in a variable which remains unchanged and if a new speed is needed it is always calculated like this:

newSpeed = speed * 0.7

so speed never decreases.

The next task is to get all the behaviours properly working together and fix any problems.

Log 19/04/2012

Regulating temperature

In real life reptiles are cold-blooded, this means that they cannot regulate their own body temperature. Reptiles bask in the sun to keep themselves warm and this is a behaviour that the virtual reptiles in ReptileX will exhibit.

In order to implement this the environment in ReptileX needed to have different temperatures, a nice way to represent this would be to have different coloured sections of the ground which were different temperatures, these colours would relate to the temperature i.e. red for hot and blue for cold. Initially it was decided that the simplest way to represent this would be using a grid so different squares would be different temperatures. In order to do this a function was made which draws a rectangle from the corner in the x and  z direction when given a x and z position and a width and depth. This is very similar to the ofRect an rect (in processing) functions which draws a rectangle from the corner in the x and y directions when given a width, height and x and y positions.

Once the grid had actually been implemented using though it was found that it would be to complicated to find out wich square the reptile was on and which colour it was as the grid was drawn using nested for loops and time was getting short for getting into complex problems. The grid also looked very basic, a much simpler and nicer looking solution was to still draw one large plane using the plane function and use OpenGL’s special feature which blends colours between vertices making the plane red at zero z and gradually blend to blue as it moved in the minus z direction. This meant that the reptiles could just find out their temperature based on their z position.

So in the environment function a was written which returned a temperature between zero and one hundred, this could be called from within the reptile class and given one argument, the reptile calling its z position. So now depending in where in the environment a reptile is it can will be given a different value for temperature, once properly calibrated this related directly to the colour of the plane so the redder it was the hotter it was and the bluer it was the colder it was.

Next the reptiles were given a body temperature and this was made to change at all times subject to the temperature their current position in the environment. Then a function was made which made this affect the reptiles, firstly a boolean called cold was switched on if the temperature went below a certain amount and secondly the reptiles speeds and speed and health was decreased if they were to cold. But initially this stopped them moving so it was taken out and left to troubleshoot later.


Next the reptiles needed to mate, up until now only the plants have been able to breed and they have done this asexually, as a simplification of nature. The reptiles on the other hand needed to mate sexually, mixing their genes. The reptiles were all given a gender randomly wether they were in the start population or not. Firstly only two reptiles were created and the nearest neighbour algorithm was tailored to search for females, making sure to store the pointer to the node that holds them as well as their position, this function was only to be called by male reptiles. Once the nearest female had been located her position was used to calculate her direction so as to move towards her. The male then uses a specially tailored version of the collision detection algorithm which checks only for collision with the female its heading for.

A function was written which could be called by the male reptile once the female was hit using the pointer to the her node in the linked list which was stored when she was located. This function was called inseminate and it takes a pointer to males gene as a parameter and switches a boolean called pregnant to true. So once the male has called this function in the female she holds the adress of his gene.

Mixing and mutating genes

Now the genes just had to be mutated and mixed then a new ‘baby’ reptile needed to be created which would inherit the new gene. So the female was given a function called mix genes which is called by her inseminate function, this first mutates both the females own gene and the males gene before they are mixed, the mutate function the plants used was improved and used for the reptile this randomly picks a few random places in the genome vector and changes the value there by a random number. The two mutated genes are mixed by stepping through the chromosones and randomly picking the attribute from the male or the female to put in a new chromosome vector for the baby. Once this has happened the female holds a new gene for the baby and pregnant is true. In the code for the reptile node each time the runtime functions are called each node checks if the reptile it is holding is pregnant. If it is then a function is called that makes a new reptile using the and gives it the new gene.

Meeting with supervisor

Had a meeting with the supervisor and it was decided that a complete project report and a working version of the program should be handed in on the 25th of April so as to get some feedback. This interim deadline would give a week and a half for any improvements.

Log 15/04/2012

Planning work was done on the project report which had to be handed in as part of the project. A short summary of general research on evolution was written in background chapter, an effort was made to keep this concise so as not to go off topic as evolution is such a broad subject with so many areas, more research had been done which was more closely related to RetileX but this was to be added later. Thought was put into the overall structure and what should be written in the other sections.

The startPopulation function was also extended to take a number and make this many reptiles when the program was started all with random genes.

The next task is to Implement the basking function for the reptiles and the mating, once these are finished then all the behaviours will be put into a behaviour function which picks which behaviour should be performed subject to a set of logical operators.


Log 11/04/2012

Log class/Writing to files

A class was created which was intended to write to a file, this would be used to record information about the organisms in the environment. This was attempted using ofstream. It was firstly tested in a empty program which worked but it was found that when this was implemented into the current version of the project it either did not make the file or put it somewhere hard to find. Time was wasted trying to rectify this problem and attempt other approaches, so it was decided to just use this class initially to print out and come back to trying to make it write to a file later. This Log class was still extremely useful as it simplified writing to the console considerably with the use of a function which took the text and variables to be printed out as arguments.

Finding food

The reptiles need to find food, the simplest way of dong this is using a variation of the nearest neighbour algorithm, this was not copied from anywhere, it was implemented from scratch. The algorithm simply steps through each element of the plant list, when it first reaches a node holding a plant it gets the plants position and stores it, each following plants position is then tested to see if it is nearer to the reptile than the one that is stored, if it is then the stored position is discarded and the new one is saved. Once the end of the list is reached the position of the nearest plant will be held. The reptile then moves towards the plant by setting it’s acceleration vector as the direction of the plant. The direction is found by calculating the difference between the plants position vector and the reptile in question’s position vector . In OpenFrameworks the difference between to vectors can easily be found by using the minus operator: -, this was also used to find the distances when finding the nearest one.

Problem with dead plants still mating

A problem was encountered here which was extremely challenging to solve, sometimes a plant would continue breeding once it had been eaten. After much painstaking searching for the reason for this problem it was decided that it could have been the organisation. The nature of this program by this stage was that had many parts all working together, this resulted in a very complicated program and there were some problems organisation problems with how these parts all fitted in i.e. what was called from where. There was also code left in which was no longer needed but had not yet been properly deleted and was still affecting the program. When debugging these bits that should po longer be there would continue to pop up so it was decided to take some time properly organising everything and taking out the unwanted code in the hope that this would sort out the problem.

Along with this it was decided to implement a starting population of plants as the program was currently starting with one plant and all the others would be descendants of this single organism. This was extremely helpful when initially implementing the reptiles collision detection and finding food functions as it kept things simple for testing but for the simulation an initial population would be needed. A startPopulation() function was written which took the number of plants as an argument and created that many plants when the program was started each with a random gene and position. In addiction to this in order to make the reptiles genome, inheritance (in the programming sense) was implemented for the genome classes. This is a feature of object oriented programming which simply allows multiple classes to be derived from a base class. This meant that a generic base genome class holding the functionality and attributes generic to both organisms could be set up and the individual gene classes for the reptiles and plants could be derived from this. The reptiles attributes were then linked to those in its genome.

Finally, the reptiles were moving around using random ‘organic motion’ which used the sin, cos and random functions in unison to create smooth natural looking random movement. This was thought to also be linked to the problem so it was taken out and the reptiles only moved if they were finding food.

Once these three measures had been taken the reptiles finding food function was re-tested and there was no evidence of the problem persisting.

Next tasks

So the next tasks are to draw more than one reptile and implement the reptiles breeding.