Zombie code

I’ve come up with a mixed bag of modifications to my artificial life system. I’m trying to get my digital creatures, which I call “figures,” more stable, quicker to emerge from randomness, and better able to tolerate mutations. As far as quicker emergence and greater stability goes, the tricks are working out. The system as gone from requiring multiple runs of 8 to 12 hours each, just to generate one stable population; to a system that can make a stable population consistently in less than 15 minutes, usually less than ten, and often less than 5. As far as tolerating mutation goes, it still isn’t any better. One single mutation is still enough to kill off the entire population, no matter which trick or combination of tricks I use.

The tricks I’m using all have clever names—snapcom, skipcom, ice, fat ports. Ice, short for induced copy errors, didn’t help at all and has been abandoned. Snapcom still needs testing. It seemed to make things no better and even a little worse, but there was a bug in the birth object that I didn’t find and fix until I implemented fat ports, which didn’t happen until I’d already given up on snapcom.

Snapcom is short for snap to command. It insures that the beginning of each instruction held in a figure’s memory happens in specific places. I think it will help with stability. I’m certain it would make a figure’s code much easier for a human to follow. That’s good, because solving the issue of mutation being so deadly will require digging through the code, and finding out what the mutation has done. To do that, I’ll need to catch it in the act.

I suspect monsters in the realm. If a figure just looped, calling find empty and outer write over and over again, then it would continually make a new baby figure in each empty slot. None of those babies would be viable—they wouldn’t be able to make copies of themselves. They’d still count as new births, and if the population is at the maximum size, each new nonviable figure born would cause an older viable figure to die. Meanwhile, the monster is also doomed. Since it doesn’t make copies of itself, that line will die as soon as the monster does. This will spam the realm with useless do-nothing figures, until the monster does it once to often and is itself killed, leaving behind those do-nothing figures to do… well… nothing… until they all die of old age.

I was chatting with my brother about this possibility—how I suspected that some figure that was doomed was killing off the rest in its death throws. He laughed, saying that they’re like zombies—already dead and driven to kill.

At the moment, I don’t actually know what happens to kill off the entire population. The monster I just described is only one possibility. Artificial life systems find ways of doing things that the designer, (you know, me,) never considered. That’s nice when they do something nifty, troublesome when they’re committing suicide. I’ll need to set up the system to save the figures just before and just after a mutation, then to keep trying until it finds one mutation that wipes everyone out. Then I can look at the mutated figure to see what it does differently after being mutated.

First, snapcom. Then, monster hunt.