Bots and Simulations > Evolution and Internet Sharing Sims
Zerobot Evolution - Where to now?
googlyeyesultra:
Dopplepost! Anyways, I've got some mild improvements going. Negative costs work wonders for reinforcing behaviors. I've got a bot that reproduces, moves, and then later annoyingly fixes itself. It still gets fed solely through negative costs, though. Can anyone offer me some suggestions to evolve against these buggers fixing? I really, really don't like it. It's probably the first major example of Muller's Ratchet I need to deal with so far.
Anyways, here's the code. I think it stores 2 into .fixpos, although I don't know when.
--- Code: --- << >
-4 ceil 47 2 ^ floor or
store
dup *.maxvel pyth or
19 ~ pow -- stop
-10 << >
-4 ceil 47 2 ^ floor xor
store
dup *.maxvel pyth or
19 ~ pow -- stop
0 << >
-4 ceil 47 2 ^ floor xor
store
dup *.maxvel pyth or
19 ~ pow -- stop
0 << >
-4 ceil 47 2 or
floor ^ store
dup *.maxvel pyth or
19 ~ pow -- stop
0 << >
-4 dist 47 2 ^ 494 angle or
store
dup *.maxvel pyth or
19 ~ pow -- stop
0 << >
-4 ceil 47 start
<< floor or
store
start
add pyth inc
19 ~ pow -- stop
0 << >
-4 ceil 47 0 << >
-4 ceil 47 start
<< floor or
store
dup *.maxvel pyth ~ add 8 ~ pow -- cond
angle 47 inc
>=
%=
not
sub store
and
store
xor
-14 ~=
dec
| 41 .dx store
1 pyth else
& pyth rnd 1 -6 =
or
or
floor stop
start
store
inc
*.timer -- ~ inc
22 %=
!~=
add << >
-4 pyth 47 2 ^ floor or
store
dup *.maxvel pyth or
19 ~ pow -- stop
0 << >
-4 ceil 47 2 ^ floor xor
store
dup *.maxvel pyth or
19 ~ pow -- stop
0 << >
-4 ceil 47 2 ^ angle xor
store
dup *.maxvel pyth or
19 ~ pow -- stop
0 << >
-4 ceil 47 2 ^ floor or
store
dup *.maxvel pyth or
19 ~ pow -- stop
0 << >
-4 dist 47 2 ^ 436 floor or
store
dup *.maxvel pyth or
19 ~ pow -- *.dx 0 << >
-4 ceil 47 start
<< floor or
store
start
add pyth inc
19 ~ pow -- stop
0 << >
-4 ceil 47 0 << >
-4 ceil 47 start
<< floor or
store
dup *.maxvel pyth ~ 19 ~ pow -- else
angle 47 inc
>=
%=
not
sub store
and
store
xor
-14 ~=
dec
| 41 .dx store
1 pyth else
& pyth rnd =
-6 -5 or
or
floor stop
start
store
inc
*.timer -- ~ inc
22 %=
!~=
add
--- End code ---
Trafalgar:
I know one way to select against it - have a shepherd bot which kills any fixed bots. Of course, if they always repro before fixing, then that won't stop it.
Personally, I decided viruses were too dangerous since if they got into the veggies, they could bring non-evolved code to the zerobots. Worse, once I put mobile shepherd "veggies" in the sim, which are almost entirely SGized*, having a virus steal their genes for the zerobots would be a catastrophic corruption of their evolving genome. So, the shepherds destroy any bot which has vtimer above 0. (They also have Guardian's antivirus code in them, slightly modified and slightly less effective, since they have 2 genes normally instead of just 1)
* = They have 3 genes, one is deleted immediately after spawning (it sets initial values for non-reproduced shepherds), the next is the core logic, and the last one causes repro-suicide if the shepherd's pwaste exceeds 10000.
Most random complex behavior I've seen in my bots has been due to something like 'start angle inc' or 'start dist inc' - since those functions take their input and add your position to it, when getting identical input (like 0 0), they return different values based on the bot's position. For instance, I had one bot which tied to everything possible when it was on the left 1/3 of the screen or so, but not on the rest of the screen (Despite having no real conditions, no SGized conditions, and nothing referencing .tie - it was all powered by angle and/or dist).
googlyeyesultra:
Lolz, I tried the gardener bot approach. I wrote this uber-complex thing that would assign things priorities based on refvars and feed them that way. It didn't work. At all. Unfortunately, they don't use the standard commands, so. . . Instead, I just feed things energy via negative costs. Seems to work well, and encourages some behaviors. Unfortunately, there isn't a cost option for fixing, which means that my usual approach doesn't work all that well. In the past, I could use small populations and high mutations, since the bots didn't do all that much. Now I've gotta deal with a hell of a lot of Muller's Ratchet. . .
Update: I've used the gardener bot approach. I toss 300 or so bots in with about 15 of these, and I end up with 15 of these and two remaining bots. Although those bots gladly have lost the ability to fix, they've also lost the ability to reproduce. I wonder if the two are linked somehow in the convoluted DNA. I'm gonna try again with my fixing-but-otherwise-so-so code.
Also, interestingly enough, I've been evolving this on F1 field size, torroidal, no grav, no brownian, etc.
Update: With around 600 bots plus the anti-fix gardeners, I was able to evolve one that fixes later on within a thousand cycles or so. Going to continue with that one.
Update: Well, the bots are willing to learn to fix later on, but they never refuse to do so altogether. All 600 of them would rather die than not fix. I really think it must be tied in with some other vital gene, but I'm not sure how. Also, my gardener occasionally misses shots, adding in a very bad random death factor.
One rather important question: In the costs panel, a bot is charged for voluntary movement. Does that charge (or in my case, benefit), apply to bots that try to move but can't because they are fixed? If not, then I can rig up the costs in such a way to kill off anything that fixes instantly dies but everything else gains a small but steady energy income.
Another bloody update: I've found that all selective pressure against fixing destroys reproduction. They're probably intertwined somehow. I'll leave the fixing alone for now, see if it "fixes" itself (pun intented), and just shoot for some sort of rotation for now.
Numsgil:
That's interesting that fixing and reproduction are so closely related. I'm not sure how fixing effects costs from trying to move, but it would be consistant with my mindset for it to only cost a bot if it's unfixed.
Trafalgar:
I bet you it's just incrementing or decrementing fakerandom* memory addresses, or storing a value to them, and selecting against that kills repro, fixpos, and anything else it is screwing with. However, none of the zerobots I have which are powered by fakerandom inc/decs reproduce. So hmm.
* = Couldn't think of an already existing word off the top of my head which means "returns a value that may appear random but is actually based on non-random variables" - like angle and dist and such, which return different values for the same input.
As for my shepherds, I'm having them try to select for greater amounts of genes at the moment, by rewarding (with energy) bots with lots of genes, and taking away energy from bots with less than the maximum they've seen.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version