I was worried that the robots would have all died out when I came in this morning but the robots survived and reached the upper limit of 256 robots so the simulation paused.
Step: 975790 NumFood: 8 NumFoodEver: 3115 NumCrit: 256 NumCritEver: 514 numSick: 1 numChild: 5 0 to 10000: 18 10000 to 20000: 28 ... skip a few ... 960000 to 970000: 0 970000 to 980000: 5
I was worried that the robots had died because I changed their bodies from a cylinder to a cube and I reduced their brain updates from 30 times per second to 10 times per second. I originally used cylinders to help the robots not get stuck on walls but this caused the robots' vision to wobble too much so I changed to a cube. I originally had 30 brain updates per second because I wanted the brains to work as fast as possible. This was using too much processing power and I was not sure the benefits were worthwhile so I'm going with 10 brain updates per second for now.
The simulation has been running for 17 real hours from yesterday and 13 real hours today. I had to reset the counter because I've only recently added the counters to the save system. In simulation hours 5 from yesterday and 2 from today. Hmm, 30 real hours for 7 simulation hours.
elapsed real time: 10 seconds elapsed sim time: 0.533333 seconds total real time: 13 hours 27 minutes 7 seconds total sim time: 2 hours 9 minutes 58.0667 seconds
I suspect that I need to prevent the robots from reproducing when I'm resetting their positions. I reset robot positions when they have somehow gone through the wall at the edge of the world and fallen off. I pick up the fallen robots and put them in the center of the world. Sometimes I do this with more than one robot so they end up sharing the same space. Programming things this way was easier. I think the easiest way to fix this is to put the fallen robots back into the world in random positions.
The other thing I'd like to do is slow down robot reproduction. To get the population off the ground I changed the time for robots to grow up and reproduce from one hour to fifteen minutes. I'm going to change this up to thirty minutes. I also changed the time robots had to wait to reproduce again from one hour to fifteen minutes. I'll also change this to thirty minutes.
The latest save file is 110622-1051 (80 MB). The file took 3 minutes to write and 10 minutes to load. Grr. I can't wait to make this take less time. There are 256 robots and I'm going to reduce it to 56, 110622-1112 (17 MB). I really like how changing the number of brain updates per second gives me a huge frame rate boost.
I was driving to uni and I realized their were other areas where I can take advantage of how I'm reducing the number of brain updates per second.
- I can reduce how often I update the view port. Brain updates and view port updates take up most of the processing power.
- I can reduce how often I copy information from the screen into an image. Ogre works by copying the whole screen into an image. I'll probably need a new approach once I start staggering neural network updates. Although this step is not that processor intensive.
Actually, I was wrong. This step takes me from a frame rate of 100+ to about 40.
I'll have to work out whether staggering neural network updates or only periodically copying from the screen to an is better.
- I can reduce how often I information from the image to a temporary vector. Yes, I know this step is unnecessary. I blame programming whilst being sleepy.
- I can reduce how often I copy information from the temporary vector to the neural network inputs.
I've just done (3) and (4) and the performance boost has been great! Ooh. I've just done (1) as well. Huzzah! I've just done (2) too! If a robot requires a view port update then I copy the screen to the image. Nice and easy. Umm. My frame rate has jumped to 100 plus frames per second! I may need to fix the frames per second down to 60 or 30.
I'm of a firm belief that you have to do the work before you get into a position to see these choices and to make them and that this applies to other endeavors in life as well.
Grr. I can't set a break point in one Emacs frame and use GDB in another frame.
Whoa. One of the weaknesses of the AI approach I'm taking is the high computational costs. With the changes I just made, I can now explore how much further I can take things.
Grr. I changed the brain and view port updates from 10 updates per real time second to 10 updates per sim time second. The frame rate dropped back to 30 frames per second. Still, I've gone from 10 frames per second to 30! 50 frames per second if I have 5 brain updates per simulation second.
Robots have 16384 units of energy. Energy drain of 2 units per second means they can survive about 136 minutes or 2 hours without eating. They are born with 500 units of energy. With energy drain of 2 units per second they can survive about 4 minutes without eating.
Grr. Loading a save file with 56 robots takes me 2 minutes 25 seconds.
On an unrelated note, there is a project that has created Zelda in Minecraft.
I'd love to see X-COM in Minecraft.
RELATED
No comments:
Post a Comment