Darwinbots Forum
Bots and Simulations => Evolution and Internet Sharing Sims => Topic started by: EricL on January 26, 2007, 01:06:40 AM
-
Attached is the long running zerobot sim I discuss here (http://www.darwinbots.com/Forum/index.php?showtopic=1967). It has just passed 1000 cummulative hours of run time and for all of that time has had at least 1000 heterotropic bots (with veggies and corpses, the overall total is usually around 1500). It's currently just over 20.5M cycles, which means I have run well over a million bot-simulation-hours or over 20 billion bot-cycles with this sim.
It started out as a standard no-costs zerobot sim with 1000 pure hetertropic zerobots whose DNA consisted of nothing but 30 0's. The mutation rates have always been set to the default.
The first replicator emerged at around 11 million cycles at which time I added a couple (yes, just a couple) of the attached 'bleednrg' veggies with mutations and reproduction disabled. I turned on everlasting nrg shots and set the autotroph nrg intake level sufficiently high to cover the veggy's nrg loss. This filled the sim with nrg shots and provided a means for my replicators to replenish the nrg lossed during reproduction through random nrg shot impacts.
Replication was very slow at first, but over time, the generation time dropped, the reproduction rate increased and I started enabling some costs. There was some die off even before I enabled costs as some bots would shoot away all their nrg or were unlucky enough to encounter another bot shooting away with feeding shots. For the first few milliong cycles with costs, CostX would zero quite often, either nautrally or due to hitting the safty net threshold.
Once replication was going, I was surprised at how quickly average DNA lengths grew (virus driven in part I suspect - more below). I went from average DNA lengths of 30 to 100 in a million cycles (it has stayed around 150 for the past few million cycles) and soon the DNA was long enough for quite a diverse set of morphs to emerge.
The problem with filling the sim with nrg shots is that while it provides a lot of nrg to encourage faster generation times, it does not provide any (or very little) directional selection pressure. There is very little nrg locality, no strong directional pressure for bots to evolve strategies for locomotion as a means of aquiring more nrg. In fact, most of my bots had fixed themselves. They had stumbled upon reproduction by writing random stuff to random mem locations and a side effect of that was fixation (as well as occasional furitless movement attempts, tie firing at nothing, virus generation, etc.) One could actually see the populatuion pulse every 1000 cycles as bots walked the memory in sync writing values. Perhaps siblings had all inherited the same algorithm based on the same random number source. I never investigated, but the saw tooth population pattern was obvious in the graph for millions of cycles and it can still be seen even today though quite a bit less pronouced. Reproduction rates have climbed since then and become more evenly distributed accross time.
Around 15M cycles, I disabled everlasting nrg shots and increased the veggy population to 350 (just a guess. I eyeballed how many veggies would be necessary to get the veggy/nrg density I wanted for the largest field size). This provided islands of nrg locality and directional selection pressure for bots to move to aquire nrg and my bots did indeed evolve movement. Within a couple million cycles, the fixed bots were gone and the survivors were all in motion at the max speed. They had evolved not to fix themselves (with the loss of everlasting shots, staying fixed had become deadly as the probability of a veggy materializeing by you by chance was too low. Ancestrial lines that fixed themselves died out over time.)
Movement increases the probability of impacting an nrg shot often enough to offset both costs and the nrg given to offspring during reproduction. Moving faster increases this. The cost multiplier crept up and hasn't hit zero in several million cycles. The reproduction rate also continued to go up, fueled by the nrg aquired via movement through the islands of veggy spawned nrg shots. Selection was favoring faster reproduction and shorter generation times.
It was about this time when the virus described in the other topic started infecting veggies regularily (was probably around even eariler). I'm sure it or it's ancestor was involved in the rapid increase in average DNA length noted earlier. (The subject of viruses and their relationship to organism evolution is I'm sure a fasinating subject, one worht exploring further.) But over time, the virus would infect too many veggies and it stopped them from shooting! I was forced to repeadedly kill off the virus-infected veggies by hand once a night lest the nrg supply to my zerobots dry up completely. Eventually, I tweaked the body upkeep cost and the nrg intake level so that an autotroph with 32000 body would die eventually even if it stopped bleeding nrg. In this way, a virus infected veggy woudl still die over time to be replaced with a preistine, uninfected one (remember, they can't reproduce). I also set the starting nrg for the veggies to 30000 to make them last longer as they bled away nrg. A cost on DNA length also helped put heavily infected bots with long DNA at a competitive disadvantage, keeping DNA length reasonable and the virus in check.
A side effect of this change is that the landscape is now constantly changing. Veggies blink into existance, bleed nrg for 300-400 cycles (or longer if they are close to one another and absorb each other's nrg shots) die leaving a corpse, decay and vanish. My goal was to put in place pressures that would encourage bots to evolve more sophisticated adaptations over time rather than just constantly moving. The idea is for selection to favor conditional behaviour such as "stop when I see or bump into something." Stopping next to a bleeding veggy while it exists would increase the nrg intake relative to constant motion but stopping forever would be deadly.
Things have been pretty steady the last million cycles, but as I write this, I snotice the cost multiplier creeping up slowly over the past 10,000 cycles. This is an indicator that bots are getting more adept somehow at aquiring nrg and turning that nrg into reproductive success. The slope of the cost multiplier curve can tell you a lot about the health of the sim. What I think might be happening is that bots have evolved the strategy of not only moving constantly but of constantly shooting nrg feeding shots ahead of them also. This means that when they hit a veggy directly as oppsed to simply flying through it's cloud of shots, they get an extra nrg boost from the nrg shots released in response to their feeding shots. This adaptation is more surprising than it sounds at first since it means the bots have evolved the beginnings of longitudinal asymmetry. They could have evolved to move in any of the four movement sysvar directions and in fact, a few milion cycles ago, I had just as many bots moving sideways or backwards as I did forwards. But shooting shots ahead of you in the direction your moving is clearly an advantage when it comes to getting the most out of an impact with a veggy. Anyway, the total nrg sequesterred by the zerobots is also slowly increasing (as it must to offset increasing CostX) even though the population is kept in a range and constant on average over time by auto costs - another sign that directional selection is underway. What's more, the nrg level of the the veggies is creeping down ever so slowly, which would be consistant with my const shooting ahead adaptation hypothisis.
I've attached a screen shot of the increasing cost multiplier graph. I plan to keep this sim running and running and running. Hopefully at some point in the not too distant future, I'll see some conditional logic emerging!
-
That's very interesting. I'm impressed they learned to shoot, move and reproduce. They're approaching (or surpassing) the complexity of Botsareus's Firstbot, which is probably the simplest human authored bot I'm aware of.
Your sim is torroidal, right?
-
Your sim is torroidal, right?
Correct.
-
Very cool!
I grabbed your sim and I also see dynamic costs going up. I'm gonna run it for a while. Then we can compare the results Maybe even do some competitions.
-
I think what may be happening with the rising costX is that bots are being selected for reproduction at younger ages and lower nrg levels. Kids grow up so fast these days...
I think the age cost is the main driver of this as the total cost increases the older a bot gets, favoring younger reproduction. A younger popuatlion overall can withstand a higher CostX at the same or lower total species nrg since the age cost toll will be less.
The average zero bot age in the sim is falling and the total nrg sequesterred by the zero bots is also falling. This can't continue forever of course and shorter generations means evolution can proceed faster, so it's not all bad I guess. At some point, there should be selection the other way (you have to live long enough to find some nrg) and generation time should stablize.
-
Yeah, I noticed that too.
One striking thing is that the evolved zerobots are so different from each other. There are clearly two different species - one is large, dark-blue and shooting and the other is tiny, light-blue and non-shooting. Has it been awhile since they split?
-
I've done no analysis, but it would not surprise me if the common ancestor is 100 generations back - one advantage of keeping the population high I guess.
But with generation time dropping and costX rising, I can't imagine multiple lines will last for very much longer. We just don't have the niche space. Auto-costs with a uniform cost distribution across the sim means one species' effecieny gains or gains in reproductive success are always at the expense of anothers. Costs as the primary selection mechanism discourage diversity since the most effecient species in the sim will always win.
I think the solution to this is to add non-cost based population control and selection mechanisms such as a built-in uber-preditor whose killing ability is a function of population targets. In this way, diversity is encouraged, not discouraged since novel ways of avoiding preditors (like being smarter or runnign sooner or hiding better or being small enough to avoid shots, etc. ) can be favorred (even if the posessor of such a trait is less effecient in other ways like reproduction effecieny compared to other species).
-
I'm trying to make a script to deobfuscate evolved DNA as much as possible. Here's what I've got for a dark-blue bot:
cond
start
-- 0 dist << dec
10 pyth .setaim store
49 >> >> rnd *.dx 3
cond
27 1 -7 >=
start
angle rnd inc
dist 3 29 6 dist >> * inc
*.dx 6 ceil - 1 1 14 dup 52 dist << dec
10 dist 36 | ^ mult inc
*20 6 angle << 1 1 dist *.robage dec
49 inc
10 ceil angle >> >> * inc
*.shootval *.aimright angle & 1 0
else
1 add 47 dist << dec
-1 * inc
*.robage 26 1
cond
0 27 1 0 !~=
xor
mult 5 add pow >> 3 22 49 >=
not
<< >> *.dx 6
start
27 1 1 dist * inc
dist 29 5 dist ^ * inc
*.dx 6
cond
and
sqr - -6 0 !%=
start
2209 dec
dist 49 >> ^ * inc
*14 .robage inc
ceil << -8 angle - 5 -10 47 dist << dec
0 >> sgn inc
*.robage 6
else
^ store
dist *23 inc
49 inc
16 ceil 29 >> >> * inc
and for a light-blue one:
cond
start
| 1 add dec
dist << dec
10 ceil .setaim store
49 >> >> * *.dx 6 angle 1 add 1
cond
27 <
-7 >=
start
angle rnd inc
dist 3 29 -4 dist >> * ceil - 1 1 14 dup 51 dist << dec
10 dist 36 | ^ mult store
*20 angle << 1 1 dist *.robage dec
10 inc
49 angle ceil >> >> * inc
*.shootval *.aimright pow & 1 1 47 dist << dec
-1 * inc
Note that both store 10 in .setaim. They probably share a not too distant ancestor, considering the similarity of their first gene.
-
I'm curious... can you find any bot in your sim that carries an eye sysvar, even if it's junk or a fresh mutation?
I've got to see one in an evosim yet. Aren't we biasing the results by starting always from zeros? Maybe one third should be zeros, one third 499 and one third 999, so mutations are distributed equally through all the sysvar range.
-
I'm curious... can you find any bot in your sim that carries an eye sysvar, even if it's junk or a fresh mutation?
I've got to see one in an evosim yet. Aren't we biasing the results by starting always from zeros? Maybe one third should be zeros, one third 499 and one third 999, so mutations are distributed equally through all the sysvar range.
I havn't seen one, but I don't find that surprising.
First, assuming completly neutral mutations, there is only a 9 in 66,571 chance that a bp will be an eye sysvar. Pretty slim.
Second, there are many, many ways to address the eye memory locations without using eye sysvars. Even if there was selective pressure to use vision, it is debatable whether bots would evolve direct utilization of the eye sysvars. They may do something like 505 * or *.robage * making it harder to detect in the tokinized DNA.
Third, the bots in an early stage zero bot sim simply arn't sophisticated enough to use vision. You either need conditionat logic
cond
*.eye5 50 >
start
10 .up store
end
or you need the equivalent w.r.t. direct storage logic.
start
*.eye4 *.eye6 sub .aimsx store
end
Bots have yet to evolve either. Thus, there is no selection pressure (yet) to preserve eye sysvars in the DNA since bots have not yet evolved any ability to use their eyes.
Yoru point about the starting distribution is well taken, but I do not think that has much baring on why we don't see bots using their eyes. The bottom line IMHO is that they simply haven't evolved that ability yet.
-
Speaking of starting distribution, I'm working on a few edits to the mutation and DNA code to address these sorts of issues. The mutation code was sort of thrown together last minute for 2.4, and Eric's never really played with it, so alot of things are still rather raw (not that I blame him, it's very scary code!)
-
The mutation code was sort of thrown together last minute for 2.4, and Eric's never really played with it, so alot of things are still rather raw (not that I blame him, it's very scary code!)
And more to the point, my spare time is finite.
-
GUYS!!!!!!!!!
there should be a speciation feature in db for this kind of stuff.
so it could identify a different spiecies somehow
-
Very nice, the evolution from a bunch of zero's to blindly schooting en reproducing. Wait that sounded better in my head.
Has anything happened in the simulation jet, it's been already 5 months ago, even exactly 5 months . Had the sim been stopped, have they continued evolving, anything. I'am interested what has happened. It would be nice to post another simulation of what you have done.
-
This evolution is interesting. I've just playing with the code, and because an explanation what the code means did'nt come earlier, I'am now telling what strange thing I found.
Sprotiel found two different specie.
specie A
4 genes
specie B
2 genes
Both the first gene is almost desame both storing into .setaim.
I found the first gene is, well junk. I hope somebody can convince me else.
I found that Specie A, the second and third gene and specieB the second gene look kinda each other, and are working like a virus it's spreiding itself trough virusshots. And even more important the virus is controlling the bot, it's reproducing it, it's schooting, it's randomly moving. There is here no bot-evolution but a virus-evolution, becouse there will be multiple genes into a bot it will probably making less mistakes even most of it it's doing is random. There's even an virus-fight going on I've seen the virussus are sometimes randomly deleting some genes.
The fourth gen of A
I gues it's a broken virus, doing nothing and it's not spreiding itself.
Edit (it's not broken it's working too made a mistake)
This is just going further then sexual reproduction, the bots are continualy sharing each other genes.
-
This is one thing I've noticed. Viruses are very common in zerobot sims. Which is weird when you think about it. Viruses tend to be rather convoluted to set up for people. But evolution loves them, and they can cause rapid evolution if they don't get too out of hand.
-
What do you mean with the virus getting out of control. These both creatures have both virus's the one even three. In fact virus's are controlling the bot. Can the virus get even more out of control.
I've put this virus into a fighting-bot instead of it's own, the bot is spreiding the virus like it's supposed to do, the virus is on his term randomly deleting genes, result the bot was spreiding gene2 becouse and of deletion's almost all of it's genes spreid out of the sim.
Result after the fighting-bot is destroyed by veggies.
veggies are hunting each other down.
After a while the veggied aren't moving anymore and shooting in circles.(to protect themself from others who are schooting in circles and against the few veggies who where still hunting)
Becouse the virus kept the effective virus-spreiding gene. Bot where having extreme loads of genes I found one with 355 genes and 8755 lines of code.
This all happened within 15 minutes, virus are really speeding up evolution.
-
If you have a virus that tends to grow genomes more than shrink them (say, creating thousands of copies of itself in other bots over time), it can start to slow the simulation down and possibly even make your computer run out of memory (though this would probably be rather uncommon).
I would add a very minor DNA upkeep cost to try and counter this. Think about our own genome. It's gigabytes of data, and most of it is probably the deactivated bits from viruses and other self replicating code. You probably don't want to simulate gigabytes of data per organism, which viruses might end up doing if they get too out of hand.
Looks like the virus from this sim is self regulating though. I think Eric might have actually set up some DNA costs with this in mind. This virus would be the result.
-
Yes, I think Eric has issued some DNA costs, the virus from the other(virus EricL) topic was a lot bigger the virus has even shrunk itself down. And for no real reason the dna length were after that not becoming any bigger and sometimes even smaller. I don't now I have said it but the reason the virus was spreiding so fast was becouse of the virus-spreider of the fight-bot. The virus itself without the virus-spreider was spreiding itself seldom and randomly.
-
this is probably the best simulation that has ever been made!
-
this is probably the best simulation that has ever been made!
Well, atleast the longest(I think), I think Testlund has the best results with zerosims, I just discovered that some of the sims he has posted came from evolving zerobots.
Are you trying to get your post-limit up or something like it, you're posting everywhere shortly after eachother.