Author Topic: 1000 hour zerobot sim  (Read 5155 times)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
1000 hour zerobot sim
« on: January 26, 2007, 01:06:40 AM »
Attached is the long running zerobot sim I discuss here.  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!
« Last Edit: January 26, 2007, 01:15:33 AM by EricL »
Many beers....

Online Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7716
    • View Profile
1000 hour zerobot sim
« Reply #1 on: January 26, 2007, 02:36:01 AM »
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?

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
1000 hour zerobot sim
« Reply #2 on: January 26, 2007, 09:46:12 AM »
Quote from: Numsgil
Your sim is torroidal, right?
Correct.
Many beers....

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
1000 hour zerobot sim
« Reply #3 on: January 26, 2007, 04:26:30 PM »
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.
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
1000 hour zerobot sim
« Reply #4 on: January 26, 2007, 06:25:33 PM »
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.
Many beers....

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
1000 hour zerobot sim
« Reply #5 on: January 26, 2007, 06:35:17 PM »
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?
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
1000 hour zerobot sim
« Reply #6 on: January 26, 2007, 07:46:29 PM »
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).
Many beers....

Offline Sprotiel

  • Bot Destroyer
  • ***
  • Posts: 135
    • View Profile
1000 hour zerobot sim
« Reply #7 on: January 27, 2007, 12:48:49 AM »
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:
Code: [Select]
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:
Code: [Select]
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.

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
    • http://www.franontanaya.com/blog/
1000 hour zerobot sim
« Reply #8 on: February 02, 2007, 03:53:28 PM »
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.
« Last Edit: February 02, 2007, 03:54:34 PM by MacadamiaNuts »
Sometimes you win, and sometimes you lose...

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
1000 hour zerobot sim
« Reply #9 on: February 02, 2007, 09:29:34 PM »
Quote from: MacadamiaNuts
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.
Many beers....

Online Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7716
    • View Profile
1000 hour zerobot sim
« Reply #10 on: February 03, 2007, 04:02:36 AM »
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!)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
1000 hour zerobot sim
« Reply #11 on: February 03, 2007, 12:18:15 PM »
Quote from: Numsgil
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.
Many beers....

Offline scood

  • Bot Neophyte
  • *
  • Posts: 40
    • View Profile
1000 hour zerobot sim
« Reply #12 on: April 08, 2007, 08:25:03 PM »
GUYS!!!!!!!!!

there should be a speciation feature in db for this kind of stuff.

so it could identify a different spiecies somehow

Offline Peter

  • Bot God
  • *****
  • Posts: 1177
    • View Profile
1000 hour zerobot sim
« Reply #13 on: June 26, 2007, 04:19:01 PM »
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.
Oh my god, who the hell cares.

Offline Peter

  • Bot God
  • *****
  • Posts: 1177
    • View Profile
1000 hour zerobot sim
« Reply #14 on: June 27, 2007, 02:44:09 PM »
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.
« Last Edit: June 27, 2007, 03:19:58 PM by Peter »
Oh my god, who the hell cares.