Darwinbots Forum

Bots and Simulations => Evolution and Internet Sharing Sims => Topic started by: shvarz on April 12, 2005, 01:53:02 PM

Title: Mutation Sims
Post by: shvarz on April 12, 2005, 01:53:02 PM
Following Nums' advice I decided to share some of my experience in running evolution sims that actually get some positive results.  It does not imply that this is the only way to do it, just one of them.  Besides, the approach will be different depending on your starting bot, your goals and other stuff.

I wanted to evolve a bot that can live on variable-in-abundance food source in large, high-friction environment.

My veggie was Alga Grexa, which runs around and follows any bot that it meets.  As a result they tend to accumulate in groups of 2-5 and run in circles.  This also means that they will survive well in places with low number of predators, multiply and then spread through the field.

My starting bot was Dominator Invincibalis.  Simply because it already had two essential features that a bot needs to survive in environment I wanted to create: it waited until food came to it and it was very good at killing the food.  It also did some other things, but that was not important.

Important things to consider before you start (run sample sims to figure these out):

1. Sim size.  It should be fairly large, because you need a lot of bots for evolution and that means you need a lot of space.  But very large sims result in pretty large variation in your population (until bots are adapted).  I started with size 5.

2. Energy input.  This is very important!  It should be barely enough for bots to survive, but it should not be too low to result in random "dying out".  Run several sims until you get reliable "predator-prey cycles" - your predator population should go up and down in more or less evenly spaced cycles.  The lowest number of predators in these cycles should not get below 25-30, or you'll get "dying outs".  Cycling between 50 and 150 is good.  Try to set "repopulate veggies" value as low as possible, and not to reseed too many veggies (and not to give your veggies too much energy).  If your "predator-prey" cycles are following the "reseeding" cycles, then you are doing something wrong!

3. Mutation rates.  These will depend greatly on DNA size of your bot.  For bots with short genomes mutation rates should be higher, with long genomes - lower.  If you are not sure, always go for lower rate!  My starting bot, DI, had ~ 400 DNA commands and I set all mutation rates to 25000 and that worked fairly well.  Mutation rate of mutation rate..  I don't think this is important.  I had it disabled completely.

4. Friction.  I wanted to adapt bots to friction.  You may go for something else.  Advice here is: Be patient. Don't start with very harsh conditions right away.  I set my initial friction to .3, because from sample sims I could see that DI still survived at that friction.  Then later I adjusted the slider higher and higher but very slowly, by about .01 every 2 million cycles.  Simultaneously I raised the energy input, because moving in higher friction would require more energy.

OK, now you are ready to start the sim!  Start it and open "Population" and "Average mutation" graphs.  Turn off the visual output and let simulation run.  Keep an eye on the graphs.  You should see cycles in population and slow, very slow rise in "average mutation".

Interpreting "Average mutation" graph: It is not as easy as it may seem.  Your average mutations will always go up over long periods of time.  It does not indicate that your bots are actually adapting, it may simply mean accumulation of neutral mutations.  One good way to distinguish "neutral" from "good" mutations is to look at the graph: "neutral" mutations will result in "Average" going up and down erratically, while "good" mutation results in slow but steady increase.  

Tracking the adaptations: Every now and then (1-2 million cycles) stop the sim and make a snapshot of your population (or just pick a random bot).  Choose the DNA that is the most frequent and compare it to the parent (I do that in Excel).  Highlight somehow the places where changes have occured.  Save.  Repeat.  After some time you'll see that some mutations persist - these are likely to be "good" mutations.  Don't start a new sim with only the new mutant bots!  Your best chance to get adaptations is to keep the whole population!  Just let the program run for as long as your patience allows you (and then a bit longer).  You can always go back to your saved sequences if you have to.  If your program crashed, or you had to reboot then it is fair game to take the latest mutant and start new simulation only with it.  BUT BEFORE YOU DO THAT:

Make sure your evolution is going the way you want: Before you start a new sim, take you parental bot (the one you started with) and put it in competition with your latest mutant.  If your mutant wins (or at least stays even) then all is well, keep mutating.  If your mutant bot is losing, then something is wrong, and you need to start over. :(  The easiest way to remedy that is to reduce you mutation rates even further.

Well, that is about all.  Ask me question if you have them!
Title: Mutation Sims
Post by: PurpleYouko on April 12, 2005, 02:01:05 PM
Could you please post "Alga Grexa" to the beastiary. A lot of members may not have it.
Put it in the "Veggies" sub forum and if you like also post it to the "Interesting behaviour bots" sub forum
Title: Mutation Sims
Post by: Light on April 12, 2005, 03:14:03 PM
I allways thought mutating highly tuned bots would result in them getting weaker, what sort of results did you get mutating Dom inv?
Title: Mutation Sims
Post by: Shen on April 12, 2005, 03:25:26 PM
Agreed Light. I always mutate simple bots and change the enviroment to see how it affects them.

Also shvarz do you actually have a working database and snapshot feature? I can never get it working. 'File Error 52' :(
Title: Mutation Sims
Post by: shvarz on April 12, 2005, 03:41:47 PM
Well, "highly tuned" is a relative thing.  What is good in one environment will suck in another environment.  Dom.Inv. was not perfect in sim with a high friction, so there was room for improvement.  And it improved.  In addition, it had several genes that were designed for F1 conditions - to fight attacking bots.  These genes became useless in my sim (there was no one to fight), so they served as "junk DNA", something that bot can mutate and maybe make use of.

Snapshot feature does not work right now.  I just use "find best bot" feature, take their DNA.  This is not a big problem when mutation rate is low.

One interesting thing I noticed that DomInv never turned cannibalistic (a huge problem with evosims, as we all know).  I have some ideas why that might be, but I'll try to test them first, then post them.  I think it has something to do with environment, not with bot.
Title: Mutation Sims
Post by: shvarz on April 12, 2005, 03:50:44 PM
Look in the attached file for the example of "predator-prey" cycles.
Title: Mutation Sims
Post by: Shen on April 12, 2005, 03:56:24 PM
Recently Ive had a new approach to the cannibal problem of evosims. Just accept that your bots will probably at some point start eating each other and look at it another way.

Really we dont care if bots eat each other, we care if parents eat there kids. So instead of a conspec avoid gene I just set a timer of 50 cycles that ran when a bot was born and when a bot gave birth. The timer made them flee other bots but only for that short period the timer was running. The interesting thing was that, unlike conspec genes, the kid protection genes never devolve. In fact having such a hostile sim where its a Bot Eat Bot world they tended to evolve the genes to flee from any bot all the time and just eat alga.

Edit: an example of cyclic growth just to backup shvarz :P
Title: Mutation Sims
Post by: shvarz on April 12, 2005, 04:38:42 PM
Actually, I noticed that our two graphs are quite different - you have more veggies than bots, me - more bots than veggies.  Probably due to the fact that I started with a very efficient bot and you are evolving from scratch.  My only concern is that your bot's population may drop so much that it results in Mueller's ratchet...
Title: Mutation Sims
Post by: Shen on April 12, 2005, 05:53:43 PM
What do you think the lower limit for number of bots is? I try to get a range of 25-100 in size 4 fields and never really goes lower than that.
Title: Mutation Sims
Post by: shvarz on April 12, 2005, 06:02:45 PM
That is good.  I think if it starts to go below 25, then it is not too good.  But then again if your mutation rates are low enough so that bots simply cruise through this tight spot without losing much fitness, then that works too.
Title: Mutation Sims
Post by: Numsgil on April 13, 2005, 03:07:17 AM
Schvarz, alot of what you do seems alot of work.  Are there any kinds of macros or anything like that that you'd like to be included in the program to speed up the process?

Maybe some kind of statistical check on the snapshot DNA.  Some way to highlight modified DNA between a distant offspring and the parent?
Title: Mutation Sims
Post by: shvarz on April 13, 2005, 11:02:56 AM
It would be nice.  Actually most of the work is to figure out the correct starting conditions.  After that PY's snapshot analyzer (excel sheet) works very nicely in figuring out the most common genotype.  And once database recording and scripts are working, this will be even easier.

One thing that may help though is some way to get a sense of frequency of mutations for a given bot expressed in a form of: "One in N offsprings will be mutated, out of those mutations x% will be insertions, y% deletions and z% substitutions."  Some kind of routine that uses the current mutation values, compares them to DNA of your bot and calculates those frequencies.  Alternatively, we can have N, x, y, z to be set up by user and those would automatically adjust the (somewhat criptic) mutation rates values.
Title: Mutation Sims
Post by: Endy on April 17, 2005, 12:14:04 AM
I think evolution tends to conserve the stuff we add when it is vital to the current sim. I added code that checks that refage and robage are greater than 0, prior to firing. The bots, even Canni's, never stoped using it, providing mutation rates/nrg levels were bearable. Evolution "wants" at least some children to survive, but has to make do until a better method evolves.

Most Canni's seem to occcur whenever food is scarce, caused by either over population or actual lack of food. The continual shooting variety are interesting, since as population drops, the bot's fitness decreases allowing normal bots to increase in numbers.

What is so bad about Mueller's Rachet? It seems to speed evolution more than hurt it, since only the best normally survive the harsh periods.

Endy B)
Title: Mutation Sims
Post by: shvarz on April 17, 2005, 12:37:10 AM
Mueller's ratchet is bad because any small number of bots is likely to have some bad mutations.  Without competition from good mutants these bad mutations will be passed to future generations.  If you repeat the situation several times in fast succession, it is bound to reduce the overall fitness of population.

Just google it if it is still not clear...
Title: Mutation Sims
Post by: Endy on April 17, 2005, 03:30:09 AM
What about if we post the type of behaviors the bots evolve with the different settings? This way we can make bots already evolved to that type of sim. Since the Dna just defines a type of behavior, making a similar species should be possible.

Endy B)
Title: Mutation Sims
Post by: Shen on April 17, 2005, 02:38:25 PM
Do you mean like, High energy sims tend to produce cannibots, KE sims produce slow bots? Ive found that bots will get rid of *any* artifical restrictions imposed on them except where it genuinly is in their interest. That goes for Conspec genes, speed restrictions and anything else you can think up.

An interesting thing confirming Endys results is using *.numties 0 = to stop bots killing there kids instead of a conspec gene is that bots as we know get rid of conspec genes, but Ive yet to have a bot get rid of *.numties 0 =.

Also try running a sim with a basic bot limited to a velocity of 10 in a normal sim, one of the first things they do is remove that restriction and take over the sim. However if you use KE mode they wont because moving at maxvel all the time = death.

I like the idea of similar bots though. What we really need is a standard evolution settings distributed with DB acompanied by a basic bot. Its very tricky to sort out the correct settings and stuff for your average newbie so if us lot could come up with a 'Standard Evo Sim' and get Nums to put it in the next DB release it would be very newb friendly.

Any ideas for a standard?
Title: Mutation Sims
Post by: Numsgil on April 17, 2005, 03:11:00 PM
Definately something about size 3.  Too small and nothing interesting happens.  Too big and you'll get slow simulations (I've gotten 5K robots in the latest version on size 4).

Also, you'll probably want corpses enabled.  I've found they slow down both vegs from growing and animals from eating them.  Animal Minimalis takes forever to chomp through a corpse to get back to the main 'meaty' vegs.  And obviously a line of corpses will prevent vegs from growing in that direction.
Title: Mutation Sims
Post by: Shen on April 17, 2005, 04:27:49 PM
5K bots? wow, Im guessing thats an F1 bot or something designed specifically for those settings. Either that or your settings are unbalanced :P

I was thinking that any bot to be used the the standard settings would be very basic and unable to reach that sort of level. I use very low energy but very large fields but of course any settings depend entirely on what the bot you use in them.
Title: Mutation Sims
Post by: Endy on April 18, 2005, 02:34:57 AM
I not sure which size is the best. It seems interesting stuff always occurs as long as finding food is hard enough(but not too hard). In this latest sim I'm running the Brownian Motion is at the highest. At first this led to an evolved blob of tied bots using shots to feed. Later, as Canni's evolved, they droped the ties, trying to keep their distance from one another, at the expense of easier feeding.

I've started adding genes for the bots to evolve around. Stuff like repro @ 99% and fire -2 shots for bots past 1000 cycles. This way the first bots [you]have[/you] to die off, until evolution steps in.

Any way if you could post your run-away dna, Shvarz? I tried to make a similar gene, but was having trouble getting it to work right.

Endy B)
Title: Mutation Sims
Post by: shvarz on April 18, 2005, 11:58:03 AM
It's in bestiary - look for Alga grexa.
Title: Mutation Sims
Post by: Shen on April 18, 2005, 12:33:23 PM
Im currently experimenting with Day/Night cycles but havnt had much success. All it seems to do is destabilse the growth cycles of bots and vegs. Instead of nice smooth curves you get constant spikes. Anyone had luck with them?

For standard settings Im thinking:Then make like 2 or 3 seperate setting files for small, big and huge.
Title: Mutation Sims
Post by: shvarz on April 18, 2005, 01:31:38 PM
What do you mean by "standard"?

As for day/night cycle: try giving veggies twice as much nrg per cycle, but make a gene for them to store extra energy as body.  Then during night, let them feed from body.
Title: Mutation Sims
Post by: Shen on April 18, 2005, 02:15:10 PM
By standard I mean a setting file and bot that would be distributed with DB so newbies wont have to mess around with the settings, they can just click and go so to speak. I mean I have trouble with the sets and Ive run quite a few sims.
Title: Mutation Sims
Post by: shvarz on April 18, 2005, 02:21:16 PM
Oh, OK.  I'd set brownian motion to 0 though.
The important thing about the default settings is that it should have bots with fun behaviour.
Title: Mutation Sims
Post by: Botsareus on May 10, 2005, 01:40:27 PM
ok, I am trying some stuff from shvartz method on my firstBot now, no more messing with the source code.
Title: Mutation Sims
Post by: Greven on May 18, 2005, 10:42:27 AM
I agreed on PY and Sprotiel on this one!

I think DB needs to get stripped of all these artificial caps there is on various things.

F.exa.: Instead of having a maxvel cap, make it so that the bots cosumes extremly much energy, and will die off or something like that, and let evolution really work on this!

Alot have been done to make fighter bots, leagues and so on, but I think we need a lot more work to be done for the evolutionary simulations.
Title: Mutation Sims
Post by: Greven on May 18, 2005, 10:43:44 AM
Maybe make an option so you can run leagues on old capped DB and evolution sims with new un-capped!!???
Title: Mutation Sims
Post by: Greven on May 19, 2005, 10:41:12 AM
What I really like to see in evolution simulations:Millions of these things you all design has yet to show up in the real simulations! I have not seen one of these things.

When I run evolutionary sims, I always use a very simple bot. Simple to not have the many advantages from the design of fighterbots and ideas from all you, but complex enough to survive in a very hostile enviroment.
The only logical mutation I have ever seen (or so I think) is the veggies evolve into a cancer-like veggie.  

I would dare say that 99 % of all simulations we run is unsuccesfull, and the original bot often devolve into lesser fit bots.

I see [you][span style=\'font-size:21pt;line-height:100%\']SO[/span][/I][/you] much potential in DarwinBots, but it is lost somewhere in the middle of the code and because DB slowly evolves into a game, which it is in some ways, instead of evolving into the evolutionary simulation / artificial life simulation it actually is!

I really like DB, but I think we need a little more concentration on evolution and stuff like that.

I think sharz will agree in someways with me, but what do you all other think?

Should DB continue becomming more of a game, than a AL sim?

Check this poll/topic:
Evo sims (http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=468&st=0&#last)
Title: Mutation Sims
Post by: shvarz on May 19, 2005, 12:04:07 PM
As long as DB is developing I am happy.  I can use it for evo-sims and have some fun :)

This particulat thread actually describes the spontaneous appearance of conspec. recognition gene :)

As for interesting behaviours, I have seen bots use ties to "float" in gravitation sims.
 
We've discussed this topic a lot and mostly agreed that complex behaviour can only develop in a complex environment.  DBs is lacking the complexity of environment right now.
Title: Mutation Sims
Post by: PurpleYouko on May 19, 2005, 01:02:47 PM
Another problem is the relatively small population available in DB. If you get a couple of thousand bots then the program slows to a crawl so nothing much ever happens.

The introduction of the e-grid and other proposed improvements should help to diversify the population.

I don't actually see DB evolving to become more of a game. It has the capability of being a game and that is great, but it has lost none of the evolutionary side of the program in making it usable as a game.
The fact is that I have put in quite a significant amount of work on improving the evolution aspects of the program. I am still doing so when time permits.

The reason that so many of our evo sims are unsuccessful is because DB is much truer to nature than some other evo-sim programs.
We have no artificial fitness criteria to control evolution so DB evolution is 100% random. The problem is in designing a sim in which natural selection is able to hone the species
Title: Mutation Sims
Post by: Botsareus on May 19, 2005, 07:39:40 PM
I truly agree with Greven here, I dont know mutch about it , but personaly was arguing for a while with the crew over here that: "Evolution in Db does not work"
The only truly meaningfull thing I got out of them was the e-grid idea, hopefully that will help out , but if it does not , then we know for sure that somthing is wrong with the program.

(And no , I was not the first one to suggest the e-grid idea, been a while)
Title: Mutation Sims
Post by: Endy on May 20, 2005, 02:30:49 AM
I zeroed the delete data location mutation after noticing that all of the false mutations appeared to be from it. Seemed to fix the problem completly, with the Mutation Info area actually giving meaningful results and all mutants being legitimate.

Endy B)
Title: Mutation Sims
Post by: shvarz on May 20, 2005, 10:55:54 AM
Greven, regarding your comments in the "Do you run evo sims?" thread - did you look at the file that is attached to This Thread (http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=454)?  There is a comparison of original bot and the evolved bot - look at all the changes!  What do you mean DNA structure is not flexible enough?  It is very flexible and allows a lot of changes.  When Nums finds time to implement the junk DNA idea it will be 10 times as flexible as it is now.
Title: Mutation Sims
Post by: PurpleYouko on May 20, 2005, 12:33:33 PM
I still say it isn't so much the DNA structure that is the limiting factor as that the program itself limits what the DBs can actually do.
To some degree these are inter-related but not entirely so.

Another example. The much misunderstood and maligned .sexrepro.

Fact: It doesn't work properly.

But then that isn't the point I'm making.
If DB was truly open ended then it would have to be possible for robots to spontaineously develop a DNA instruction which would allow sexual reproduction to work.
They did it in nature!
But there is no way for a DB to do this because they can only evolve abilities which we have previously hard coded into the program.

It would be simple enough to allow mutations to make changes like .aimsx into .aimfx or .aimsg but the program wouldn't know what to do with them.

What the heck would  .aimfx do anyway? I have no idea but wouldn't it be cool if the program had some way of doing something with it anyway?
I can't really think of any way to implement this but I am certainly overworking my grey matter in an effort to do so.
Title: Mutation Sims
Post by: shvarz on May 20, 2005, 12:37:15 PM
A friend of mine (programmer) some time ago mentioned some programming language that can define it's own commands.  At least that's how he explained it to me.  I'll see if I can find out more.
Title: Mutation Sims
Post by: Endy on May 21, 2005, 05:37:41 PM
I wouldn't say sexrepro is a total loss. It does seem to help mix up the species dna somewhat. I've seen a bot with a bad mutation have it's children "cured" after a sexrepro with a normal bot. I've used it on plants and they started flying in opposite directions top/bottom so as to meet each other at the middle. It does however seem to crash the sims more often.

There could be a good reason the bots avoid some mutations. The bots are only striving for adequate mutations. If it takes multiple steps and one of the initial steps is detrimental it would be unlikely to evolve. The birth tie provides a guarantee that the bot will eventually seperate, a tie-removal gene requires that the bot tie then deltie. To deltie however the bot must use the same number, the most likely result being that the bot will not and instead of helping the tied mother/child will hender each other.

The reason why TF doesn't evolve is similar, it requires storing values into tieloc,tieval, and tienum. Shareing, however, can and has evolved since it only requires one number stored.

Shots probably are the best feeding method actually. The incomming shots come almost straight to the bot, they're in relativly small quantities that allow babies some chance of surviving. The bots can then randomly subtract 5/3 from the -1 and lose waste or gain body. Shootval could also have a num randomly stored into it to increase either range or power.

I'm trying to understand game theory so as to help figure out what gives the bots the best payoff evolutionary speaking. From what I can tell a sort of Retaliator bot would be the best for mutation sims. If it is attacked by a canni it responds in kind, if the neighboring bot is peaceful so is it. The only problem is ID between a Canni attack and an accidental discharge, and attacking long enough to have an impact.

Endy B)
Title: Mutation Sims
Post by: S.o.G. on June 14, 2006, 01:04:45 PM
Quote from: Endy
I'm trying to understand game theory so as to help figure out what gives the bots the best payoff evolutionary speaking. From what I can tell a sort of Retaliator bot would be the best for mutation sims. If it is attacked by a canni it responds in kind, if the neighboring bot is peaceful so is it. The only problem is ID between a Canni attack and an accidental discharge, and attacking long enough to have an impact.

Endy


In my latest sim, which is pond mode with fixed alga in the top third, an unfixed alga that spawns at the top (and so floats to the bottom) & mobile I flammi as veggies and a DI to which I added float at birth, sink at age 2500 genes, the bots have evolved a retaliator strategy after at 3 million cycles. They only retaliate when bumped into hard, or hit with feeding shots during feeding. It has started to evolve away though, there is a more aggressive strain. They still don't chase other bots, but they sometimes attack them when they come too close.

This sim is really stable. The pop ranges from 70 - 150 following day night, with a much much flatter curve than that of the blooming fixed algae. A while back there was a mutation that was reproducing in the morning, and the bot population spikes were actually preceding the alga bloom spikes. It didn't last though.
Title: Mutation Sims
Post by: maheshjr2000 on July 07, 2006, 12:47:34 PM
To address the problem that  DB takes up too much power. Im building a medium sized beowulf cluster if I can find a kernel that will let me run it like a normal computer(this is available in linux right?) So hopefully soon we should find out if extra power will help or not. I agree with most of the people here that DB is becoming a game however I feel that the some of the caps are neccessary to simulate real world conditions. I dont feel that the DNA language is that limiting because (to my knowledge) it works as real dna does. Real dna executes a string of commands in the form of ATGC does it not?
Title: Mutation Sims
Post by: EricL on July 07, 2006, 01:18:07 PM
FYI, the VB version is single threaded.  You would be wasting you time running it on a cluster.  It doesn't scale.
Title: Mutation Sims
Post by: Numsgil on July 07, 2006, 02:27:21 PM
It's possible in the future that a version will be built that could take advantage of a relatively small cluster, but I see the main advantage eventually being increasing the actual size of the sim.  More bots instead of faster simulations.
Title: Mutation Sims
Post by: EricL on July 07, 2006, 02:30:48 PM
FYI, I'm working on local multi-instance sharing as we speak.  That will be a highly parallel way to lever multiple CPUs.
Title: Mutation Sims
Post by: Zinc Avenger on October 13, 2006, 09:50:35 AM
I've been trying to run decent evo sims for a while now, my major breakthrough came when I completely disabled Point mutations. This allows each mutation to be evaluated for the entire life of the bot, so a bot that is "improved" by a mutation is not going to get a negative Point mutation to kill it off before it has a chance to pass on the goodness.

I'd also recommend setting an oscillating Mutation Rate, with 1 cycle at 16x and then 5 (or so) at 1/16x. This way there is a one in six chance of a high-mutation reproduction and a five in six chance of a low-mutation reproduction. This allows the dna to do some mutating, but if a bot is successful then five sixths of its offspring will be relatively unmutated. I find this strikes a nice balance between getting serious mutations and letting natural selection reward the fit.
Title: Mutation Sims
Post by: Testlund on October 13, 2006, 11:54:34 AM
That works if you run a sim with any of the default bots. I usually have point mutation set to 10 000 000 when running with those, but in my evosim where the bots started with only 13 zeros in their dna I had to set point mutation to 1 000 000 for anything to happen at all. This gets changed by delta mutation over time though. Zerobot sims are more challenging I think. I whould recommend giving it a try.    But one needs to have patience because it can take weeks before a functioning bot evolves. I'm at 13 million cycles but only got 39 offsprings. It's running 24/7 on my old computer.
Title: Mutation Sims
Post by: EricL on October 13, 2006, 03:30:53 PM
I wonder whether one can conclude from this thread that 4 billion years ago, external, radiation induced mutations were critical to evolving the first replicators from the amino acid soup, but then once the basic mechanisms for evolution are in place - reproduction, etc. that external point mutations become the least interesting type of mutation and can even be detremental....

BTW, the posts above w.r.t. scaling on multi-cpu machines no longer apply.  Teleporters in 2.42.8 allows for multiple DB instances to cooperate on a single OS image, allowing as linear scaling on multi-cpu machines as the underlying OS allows.  Way cool.
Title: Mutation Sims
Post by: Zinc Avenger on October 16, 2006, 05:59:37 AM
Interesting theory, I've always seen Point mutations as harmful, but I'd never considered them as the original driving force in starting the whole thing off. It certainly sounds plausible! I guess Point mutations would become even more harmful once you start getting multibots/multicellular organisms, nobody wants their left kidney to suddenly start moving around on its own or start to produce venom

On a similar note, I've been trying to "vaccinate" a bunch of not-top-rate bots like C. Ancestralis against some of the best by creating a weaker strain of predators (remove .repro and add randomised conditions to a few of the more important genes) and defining them as veggies with a very low pop cap and very very low rate of energy input. It requires a lot of supervision (killing off the predators if they get a little too successful, adding in the occasional batch of non-veg zerobots with high initial energy when the sim is getting a bit low on energy and occasionally repopulating the predators), and although I haven't had any dramatic successes they're starting to move in the right direction.

On your recommendation Testlund I shall prepare a zerobot evo sim. Does anyone have any recommendations for a good setup for this? I'd hate to evolve something useful only to have the entire thing go extinct on me minutes later!
Title: Mutation Sims
Post by: Testlund on October 16, 2006, 12:03:48 PM
I have a settings file here you can check out to set up your sim. Have fun!   Note it's for version 2.42.8 which is the major evosim program.

You can either let the morphological costs be like they are, which will eventually kill off a bunch of them after awhile, or you can chose to have it all set to 0. I whould recommend you start a bot with at least 13 zeros in the DNA.
Title: Mutation Sims
Post by: EricL on October 16, 2006, 12:46:32 PM
FYI, if you use the "No costs applied when population below..." feature, then amazingly, no costs will be applied until you evolve a replicator and the population grows beyond your threshold.  A major reason I added this feature is for null evo sims where you want no selection pressure until you have evolved a first replicator...
Title: Mutation Sims
Post by: Zinc Avenger on October 17, 2006, 06:43:26 AM
The comment above about using teleporters to take advantage of multiple processors is pure gold. I did not know I could do that, and it has opened up some great possibilities for me.

The way I've got my setup running at the moment is to run two sims, a standard size one with bots and veggies and high frequency oscillating mutation rates (1 cycle at 16x, 3 cycles at 1/16x, no point mutations) and a large low-mutation one (1 at 16x, 19 at 1/16x, no point mutations) populated only with a fairly high number of veggies. Both have wandering teleporters set up to exchange only bots between the two.

The idea is that the bots evolve in the high-mutation sim and the teleporters occasionally transfer bots to the low-mutation sim. This sets up a stable population in the low-mutation sim, and regularly introduces bots from the high-mutation sim and transfers bots back to the high-mutation sim. If the currently-dominant strain in the high-mutation sim is not competitive against the low-mutation sim strain (in other words if the descendants are not competitive against their own ancestors) then the influx of ancestor-strain bots from the low-mutation sim will take over. If they are not significantly more competitive than their ancestors they won't get a foothold in the low-mutation sim.

The test sims I ran last night (about 7 hours worth) managed to avoid crunched descendants and showed definite evidence of improving fitness (introducing equal numbers of current-strain bots and ancestor-strain bots to a new sim meant that the current-strain bots always wiped out the ancestor-strain bots).
Title: Mutation Sims
Post by: Numsgil on October 17, 2006, 11:35:27 PM
Quote from: Zinc Avenger
The test sims I ran last night (about 7 hours worth) managed to avoid crunched descendants and showed definite evidence of improving fitness (introducing equal numbers of current-strain bots and ancestor-strain bots to a new sim meant that the current-strain bots always wiped out the ancestor-strain bots).

That's an impressive accomplishment!  Most ancestor vs. current strain sims that I've done have the ancestor win out (That doesn't necessarily mean that the ancestor is more fit than the predecessor).
Title: Mutation Sims
Post by: EricL on October 18, 2006, 11:38:04 AM
Diversity of environments is pretty key I think to providing the selective pressures necessary to evolve greater fitness.    Pressures to evolve can come from both the non-organism environment as well as from direct competition with other organisms.  I.e. an organism will be fitter if it out-competes rivals but also if it evolves a better adaptation to the environment.  Yes the latter almost always results in the former but my point is that a new or changing environment can often proivide directional selection independent of competition whereas a static environment favors stabalizing selection all else being equal.

While DB is pretty limited today in the ability to create different evironments within a single sim (gravity, fluid dynamics, costs etc are uniform throuhout a sim) it dawned me a while back that allowing multiple instances to connect on the same machine would be a cheap way to get greater environmental diversity as well as performance scaling.  The configuration you are using ZA is exactly the kind of thing I had in mind.  I love it.

BTW, I have a LAN at home and have run as many as 10 cooperating instances across 4 machines with a total bot population exceeding 10,000.
Title: Mutation Sims
Post by: Testlund on October 18, 2006, 12:36:36 PM
Quote from: EricL
BTW, I have a LAN at home and have run as many as 10 cooperating instances across 4 machines with a total bot population exceeding 10,000.

I don't know how you can possibly manage that without frezzing up the computer. If I get more than 1500 objects in my sim it freezes. I have.... Oh, my...! I just looked at the specifications and it says my dual core processor is only 989 MHz!!! It's supposed to be 2.2 GHz! Something is wrong here!  
Title: Mutation Sims
Post by: EricL on October 18, 2006, 01:50:07 PM
My machines are single proc P4's running between 1.4 and 3Ghz with 512-1Gb of ram.  Not dual cores, but not slow pokes either.

Note also that in my setup, any given single DB instance genenerly only contains on average about 1000 bots.  The 10,000 number is the total across the 10 connected instances.  

Note that many performance elements of DB are non-linear w.r.t. bot population.  That is, a sim with 500 bots will run more than twice as fast as the same sim with 1000 bots all else being equal.  Said another way, two connected instances with 500 bots each will run faster than a single sim with 1000 bots, all else being equal.   The computation necessary for things like vision, bot-bot collision detection and bot-shot collision detection have artifacts that go up polynomially with population, non linearly, especially if there are lots of bots in close proximity.

Even in a given sim with a constant population, the sim will run as much as 2X slower or even more if all the bots are clumped together as opposed to spread out across the sim.  This is becuase if two bots or a shot and a bot are close enough to possibly collide or see each other, etc. over the next cycle, then certain performance shortcuts in the code cannot be used and the actual, expensive calculations must be performed.  By using multiple instances, no code needs to execute to check for collisions, etc. between bots in differnence instances.  Thus, the overall computation load for the total population is less than it would be for a single instance.

My topology between the 10 instances is a ring and generally self regulates, spreading the population out fairly evenly as the field sizes are not large and thus if the population in any single instance goes up, the increased density tends to increase the outbound teleportation rate over time.

If you suspect a performance problem with the program, I would be very interested in taking a look at a sim which exhibits slower performance in recent versions than in prior versions...
Title: Mutation Sims
Post by: Testlund on October 18, 2006, 02:18:04 PM
Here's a sim with allmost 2000 objects in it, mostly veggies.
Title: Mutation Sims
Post by: Numsgil on October 18, 2006, 09:40:39 PM
As a performance P.S., the C++ fork uses a uniform grid for the what-can-see-what.  The result is that theoretically things scale up linearly as you inrease the number of bots.  In actual profilling bot collisions are now more expensive than bot vision.  A similar approach with bot collisions means everything should scale linearly with bot population size.

Now if someone would polish and finish that code...
Title: Mutation Sims
Post by: Zinc Avenger on October 19, 2006, 10:37:52 AM
Quote from: Numsgil
That's an impressive accomplishment!  Most ancestor vs. current strain sims that I've done have the ancestor win out (That doesn't necessarily mean that the ancestor is more fit than the predecessor).

Yes, the ancestor strain usually does win and that was the idea. The setup I described really raises the bar for mutations to take hold. It created what I tend to think of as a sort of "genetic inertia" (yes I'm aware that I'm just making up descriptive terms!  ), so minor improvements and neutral mutations can't oust the ancestor strain in their "home" sim. It takes a genuine and significant improvement for the ancestor strain to be overrun in the low-mutation sim, and all the while if the high-mutation current strain falls below a certain threshold of fitness the low but regular introduction of ancestor strain bots wipes out the feeble descendants and starts the process again from a known competitive point.

I'd think that in some ways the net effect is similar to what you might get if you just vastly scale up the numbers in a single sim, just with lower computing costs.

It automates a lot of the saving and manually injecting test populations I used to have to do in several sims run consecutively. So you can see why I think everyone should be told, loudly and repeatedly, about the new teleporters function!

(Oh, and also perhaps a couple of hints about having to create a dir to use as a swapping area and having a separate dir for each teleporter pair might avoid 15 mins of head scratching like I had.)
Title: Mutation Sims
Post by: Numsgil on October 19, 2006, 11:00:24 AM
Can't wait to till I can get ahold of some spare computers and set this up
Title: Mutation Sims
Post by: EricL on October 19, 2006, 02:10:34 PM
Quote from: Numsgil
As a performance P.S., the C++ fork uses a uniform grid for the what-can-see-what.  The result is that theoretically things scale up linearly as you inrease the number of bots.  In actual profilling bot collisions are now more expensive than bot vision.  A similar approach with bot collisions means everything should scale linearly with bot population size.
I am dubious that actual linear scaling can be aheived.   In therory, linear scaling might be achievable for interactions which exhibit topological locality such as ties or collisions or vision.  A grid approach there would allow this, or close to it and it makes much sense to move to this architecture at some point.   I will claim however that the clumping issues can still make things non-linear, though with an exponent hopefully much less than 2.

As the number of nodes go up linearly, the average density will go up and thus the number of edges in the potential local interaction graph for local interactions go will up non-linearly.  If you try to increase the field size and other topological artifacts such as shapes that go with it to maintain average unfiorm density as population increases, then I will claim that you will still have a non-linear component because you will get clumping.  Bots tend to concentrate together around veggies, they are born in physical proximity, they chase one another, etc.  and thus adding the Nth bot will on average result in a slightly higher average desnity (even with a corrospondingly incrementally larger field size) and thus slightly higher number of local interactions needing to be calculated than adding the N-1th bot did.  You will get grid hot spots which will work against the linear aspects of grids and thus I will claim that adding the Nth bot will always take more cycles then adding the n-1th bot did.  Note that this ignores non-local interactions such as planet eaters which do not exhibit locality and are thus essentially O(n^2).  A grid approach won't help that kind of feature (although I suppose you could make it must better than O(n^2) by aggregating the masses of bots within distant grids and calculating the attraction forces for the grid itself as opposed to the bots withion a grid) but it can make the exponent for most interations much less than 2.  Unfortunatly, IMHO I don't think it can ever be 1.

Quote
Can't wait to till I can get ahold of some spare computers and set this up
 

Why not do it on a single computer?  There is no problem running multiple instances on a single cpu.  Multiple machines just adds horsepower.  You can acheive the topological advantages of multiple teleporter connected instances on a single cpu...
Title: Mutation Sims
Post by: Numsgil on October 19, 2006, 09:52:45 PM
To be honest, I would side with you.  Linear seems like a stretch of a claim, for the same reasons you outlined, but every resource I find indicates a linear relationship.  If I had to guess, I would have said it's probably a very flat O(n log n) curve, since when you add a bot you increase the complexity for a subset of the total population.  Either way, graphs I've seen of the complexity are very, very, flat.

I'd post the resource but I can't find it.

As to the Planet Eaters, I've seen some research from planetary models that use a grid approach to reduce the complexity in the same way you suggest.  The idea is that you absorb a body that is sufficiently far away into a single mass for the purposes of force calculation.  Might be fun to expirement with some time, but it's not really a huge issue since Planet Eaters isn't a standard option.

Quote
Why not do it on a single computer? There is no problem running multiple instances on a single cpu. Multiple machines just adds horsepower. You can acheive the topological advantages of multiple teleporter connected instances on a single cpu...

I basically just need a spare computer.  I tend to use my laptop for programming, etc. and my desktop is currently busy looking for Alien Intelligences in the noise of space
Title: Mutation Sims
Post by: Testlund on October 20, 2006, 08:27:41 AM
I'm sorry, I didn't read your post properly before I posted my sim, Eric.  I had no idea running multiple instances could be faster. Maybe running two instances at half the size than a single instance and half the amount of veggies and connect them together whould be much better then. The best thing whould be if DB supported dual core so I could run each sim on each half of the processor. Maybe something to implement in the future?    I have never tried using teleporters. I'll give it a try later.
Title: Mutation Sims
Post by: EricL on October 20, 2006, 10:35:52 AM
First, turn off Planet Eaters.  It's killing your sim perf by a factor of 5.  Yoru sim will run 5 times faster without planet eaters.

Second, let me say that DB *already* supports dual core machines.  All a dual core machine is is a machine with two cpus.  They just happen to be on the same chip.  Windows has supportted multi cpu machines for many years, scheduling processes and threads accross the cpus without any required changes to the programs.  It's not uncommon for big Windows servers to have up to 64 cpus for example and server programs like SQL server are designed to scale as much as they can to leverage such machines.  The XP client handles up to two cpus for XP home and four for XP Pro I beleive and those limits are artificially imposed.   The underlying kernal is bascially the same as that used on the server.  Microsft thottles the desktop to prevent server sales cannabism.

So, DB runs fine on dual core today but since it is VB6 and thus single threaded, it can only take advantage of more than one cpu if you get more than one thread of execution going in parallel and the only way to do that today is to run more than one DB instance.
Title: Mutation Sims
Post by: Testlund on October 20, 2006, 05:44:08 PM
How do I set up a teleporter between 2 instances of DB on my machine? Do I select inbound and just set the same path to a folder in both? For instance: P:\PROGRAM\Artificial\DarwinBotsII\Transfers
Title: Mutation Sims
Post by: EricL on October 20, 2006, 06:48:15 PM
1) Create two file system directories somewhere.  As an example, I'll use c:\foo and c:\foo2.
2) Start DB and set up your sim.
3) Create an inbound teleporter.  Give it the path c:\foo.
4) Create an outbound teleporter.  Give it the path c:\foo2.
5) Save the sim.
6) Start a second instance of DB and load the sim you just saved.  Now you have two instances, but they are both writing to the same place (c:\foo2) and reading from the same place (c:\foo).
7) Reverse the paths for the two telepoters in the second instance.  Now one reads from where the other writes and vice versa.

Thats it.  You should now have two cooperating instances of DB.  The first instance will write bots out to c:\foo2 and read them in from c:\foo.  The second will write bots out to c:\foo and read them in from c:\foo2.
Title: Mutation Sims
Post by: Testlund on October 20, 2006, 07:02:32 PM
I did it like this. I don't know if that's what you mean.

The teleporters at the bottom goes to folder A and the teleporters at the top goes to folder B.
Title: Mutation Sims
Post by: EricL on October 20, 2006, 07:13:48 PM
That should do it.  You should see bots dissappear at the red ones and reappear at the green ones.  Changing the size of the outbound teleporters will impact the teleportation rate since the size dictates the area from which to suck up bots....

Let me know what you think and whether you think the aggregate perf is better than a single sim.
Title: Mutation Sims
Post by: Numsgil on October 20, 2006, 07:42:26 PM
Is there a way you could abstract this process for users who aren't as computer savvy?

For instance, maybe a metaprogram that calls up instances of DB.  It would let you graphically drag, drop, and connect various instances with each other so you could orchistrate various topologies quickly and intuitively.

Would be even better to have it be able to coordinate sims across different computers (over the network) but I'm not sure how easy this would be.

I could probably work on something like this as a temporary distraction...
Title: Re: Mutation Sims
Post by: spike43884 on October 30, 2014, 03:08:08 PM
Mhm, could you give links to those bots you start with, I quite like carnivorous ivy, you might want to try it out, it always forms vertically....makes the screen look quite unusual really...plus some really long ones appear you can throw different species at either end, and it be like a fuse :D


Heh, also if you want better mutation, throw about 1k 0's randomly throughout a bots code, I do this always before evo-sims (and most sims actually) it then quickly accumulates around 3000 mutations, giving you a good variety...thats on a x1 mutation sim...w/ delta mutation which gets me results :D