This is your brain. This is your brain in a vat. This is your brain in a vat on the EvoGrid.

You're undoubtedly familiar with some form of the brain in the vat argument, which suggests that your brain might actually not be connected to a nervous system connected ultimately to muscles and sense organs, but instead to a computer that simply receives the outputs of your brain, runs them through a giant virtual reality simulation and simulates inputs. Yeah, Descartes first considered it, and then there was that little film you might have seen called The Matrix. Sigh.

As tired as this concept is, I think it could have a great application towards a generalized artificial life platform, which could play really well on the EvoGrid.

What the model gives us is a layer of abstraction. Let’s say our A-Lifes are simply brains in a vat, hooked up to a computer simulation that processes their inputs and outputs. This model gives us the ability to separate the evolution of the control code from the simulation, so that the control code could theoretically be connected to any simulation. Perhaps the control code is operating a simulated robot, or perhaps it’s responding to musical notes. Maybe it’s in a 2D environment, or maybe a 3D environment. The point is that the “simulation” is a black box from the point of view of the A-Life.

Perhaps this is sounding more like AI than AL, to which case I plead somewhat guilty…although I frankly am more interested in evolution as a creative force than I am in these distinctions. But what about the morphology of these ALifes? In our case, we’re born with more or less the same kinds of bodies with the same kinds of inputs and outputs. But anything is possible in simulations, and so I propose that some simulations might choose to interpret “outputs” as instructions to change the morphology. Perhaps in one simulation, writing “3” to pin #2 would a new limb to be generated, along with new inputs and outputs. In another simulation, every ALife might control the same make of robot.

Here’s my proposal for a new generalized ALife platform, which I’ll call VatLife. The intent is to make the environment as much as a black-box as possible, to separate evolutionary computation from simulations.

The main classes/components are:

VatLifeEnvironment
VatLife
VatLifeGenotype
VatLifePhenotype
VatLifeMind
VatLifeController

Here's the basic design. A VatLifeEnvironment may contain a number of objects, which can include VatLife artificial life forms. It maintains information about those objects (the VatLifePhenotype) and handles all of their interactions, as well as any physics (if applicable). This is meant to be a “base class”, so there may be many different types of VatLifeEnvironment simulations with different properties. Each VatLifeEnvironment should essentially determine the fitness function of the objects within it. This could be as general as determining that one VatLife has eaten another, or as specific as rewarding individual VatLife objects based on their ability to replay a series of inputs.

Each VatLife would contain a VatLifePhenotype, VatGenome, VatMind and a reference to a VatLifeController. The VatLifePhenotype is used by the parent’s VatLifeEnvironment, and will be treated (except perhaps for simple initialization purposes) as a black box by the VatLife.

The VatLifeController would be a program that has two main tasks. The first is to take the VatGenome and produce a VatMind, as well as an initial VatLifePhenotype. The second is to respond to inputs and produce outputs by interpreting the VatMind – but not by referencing the VatLifePhenotype directly. Instead, it might read input pin #2 from the VatLifeEnvironment it’s in, which could get data based on the phenotype. For example, this could return the relative brightness that the left “eye” is receiving, the angle of which is controlled by another pin.

To make this work across different types of VatLifeEnvironment simulations, the VatLifeController might be coded in something like Java bytecode. This way, when one VatLife enters a simulation from another, the new VatLifeEnvironment might note that the new VatLife uses a different controller and automatically download it.

A word on input and output pins – the basic idea here is very simple. A VatLife object might have a set of hierarchical pins, each of which can be read and written to. To use a grossly simplified model of the human body, you could say that we have four top-level pins (our two arms and two legs), with our two arms each containing five child pins controlling to our fingers. Each pin when written to activates a muscle, and when read returns the level of strain.

Each VatLifeController should be given a certain amount of processing time, and can also be called when input pin values change, executing “attached code” (essentially interrupt processing).

While I’m not claiming this should be the design for the EvoGrid, I think it might be a very interesting design for an “island” within it.

One open question I have is how ALife’s will breed. Should there be a standard way of breeding different VatGenome objects (and is there a generic representation?) and leave the interpretation open to the VatLifeControllers, or should the VatLifeControllers be responsible for the breeding? I’m inclined to go the first route, but perhaps the more flexible solution is to give the VatLifeController a crack at it first, and if it doesn’t handle it, fall back to a generic handler.

Any feedback would be much appreciated!

YouTube video

Here's a YouTube video I created for MicroPond v1. Unfortunately, the audio is a bit garbled and out of sync at times, as MicroPond uses a ton of cycles when run at full-speed and interfered with the video recording - but it's still worth a watch.

http://www.youtube.com/watch?v=GuWJ1ZiwO2g

A vaguely interesting critter (MicroPond V2)

<-Could these be the "Omega-Critter"?

This was a surprise to me. I thought it would take eight segments to produce a critter that protected its photosynthesize segment (the green pixel). But random mutatation and natural selection found this simpler solution, which is seven segments long. Because critters can't attack diagonally, the center area is safe.

MicroPond v2

In MicroPond v1, there's food and then there's critters. The evolution of the critters is simply driven by competition between the critters for food, and the food does not evolve.

For the second version, I wanted the critters to eat each other in the hopes that this would drive critter evolution naturally. My thought was that the evolution of predators should drive the evolution of natural defenses, which should in turn drive smarter predators.

Additionally, I planned for the "critters" in MicroPond V2 to develop a richer instruction set. While one goal I had for MicroPond V1 was to create an evolving ALife simulation that could be understood by a non-programmer, I hoped for more interesting instruction sets to evolve in V2. In V2, some instructions map to segments, while others do not. For example, while there's a Photosynthesize instruction that maps to a green pixel, an Eat instruction that maps to a red pixel, there are other instructions that don't map to segments at all.

One problem I faced was coming up with an "attack" instruction that allowed for intelligent strategies to develop. If you can't defend yourself from attack, there's no need for much intelligence on the part of the attacker or prey. My solution was this: a critter gains energy each turn for every exposed Photosynthesize instruction (a green pixel), but the Photosynthesize instruction leaves a critter open to attack. Normally one critter cannot move on top of another, but if a critter attempts to move over another critter's green/photosynthesize segment, it will eat the critter.

One defensive strategy is for a critter to curl up around its photosynthesize instruction, so no part is exposed. Colonies also form, which provides lesser protection.

There are three territories in MicroPond V2: a shaded center square in which photosynthesis operates at reduced efficiency (every time a Photosynthesis instruction executes inside the center square it produces a third of the energy compared to elsewhere), a small square in the lower left that contains randomly placed gray obstacles, with a solid wall on its right side, and the remaining area which is unobstructed and photosynthesis runs at full efficiency.

Also, MicroPond v2 is multithreaded, and so two separate "worlds" run simultaneously. There's no synchronization between the worlds, but it uses my dual-core process to good effect, and it's interesting to see how differently they can develop. I'm curious if this could be a useful metric for the "interestingness" of a particular simulation - let it run several times for a set number of turns and see how different the end result is between runs. Also, in a future version I'd like critters to migrate from one "world" to another.

Finally, there's a pretty nice close-up view in MicroPond v2 that shows the individual "critters", along with their head, orientation, and a bar of their energy level on the tail.

The program can be downloaded here:
http://www.badongo.com/file/9705866

MicroPond v1

My first real foray into AL was what I'm now calling MicroPond v1. The original inspiration was the book Chaos by James Gliek, specifically the part where he discussed the chaotic nature of predator/prey populations. I set about to try to simulate this, and then realized that the predators needed rules. It was purely an afterthought to allow those predator rules to randomly mutate, but it soon became the main subject of my interest.

In both MicroPond v1 and v2, "critters" are simple worm-like creatures on a 256 x 256 pixel 2D grid. They have a head which can be oriented up, down, left or right, and can contain multiple segments. They cannot travel over each other.

In MicroPond v1, each critter contains a series of instructions which are executed sequentially, restarting at the beginning after the last instruction. Each critter is as long as the number of instructions. For example, "MZ>" would be a three pixel long critter that would move, sleep, turn right and repeat.

Critters gain energy by moving over green dots, which are randomly distributed, and lose energy each turn. If a Critter's energy level goes negative, it will die. If it exceeds an energy threshold, it produces a copy. If mutation is enabled, the copy may have a random mutation, which can be either randomly losing an instruction, gaining an instruction or having an instruction randomly changed.

The executable (Windows only) can be downloaded here:
http://www.badongo.com/file/9689782

You'll need to insert a critter to get the ball rolling. Start with "M", which will simply move forward, hit food and produce copies. Add mutation, and interesting results occur. Click on "Instruction Set" to view and enable/disable certain instructions.

Introduction, my ALIFE projects

My name is Scott Schafer. While I've been involved in developing commercial software for about twenty years now, I've had an unprofitable hobby in the field of ALife.

I've only recently found a community who share my interests - and I'm very excited where this field seems to be headed. So in the interests of sharing my work and discussing it further, I've created this blog.