Open-sourcing VatLife

I just set up an SourceForge location for VatLife.

However, I don't plan to upload it just yet. While I just don't have the time, resources or knowledge to develop the "perfect" framework, and my plan was always to release a rough cut that might inspire others or be picked up by better developers than I, for VatLife to get any traction at all I think it will need some documentation and better examples. I'd rather have this make a splash later than a thud now.

Given that this is a side project of mine and I don't have that much spare time to work on it, let's figure it will be at least a few weeks before this goes on-line.

I consider that the GreyThumb SV presentation was a launch of a concept more than a launch of the technology itself - and again, I'd welcome feedback of all sorts. Well, most sorts anyway. ;)

In defense of the unreal

I attended GreyThumb earlier tonight and presented VatLfe, and am too buzzed on adrenaline and a can of Coke I guzzled earlier to go to sleep just yet. Having given up sugar for the past few weeks, that single can sent me flying.

Overall, I thought the presentation went reasonably well. It was extremely well attended and a fairly good mix of people. At this moment, I'd be hard pressed to say what the reaction was to my presentation. At times I felt I'd made it too basic, at other times too technical...and then there were the moments where I felt I was transparently making it up on the spot. Zann's talk and mine were different enough that I'm not sure if the combined brainstorming session entirely worked.

On the plus side, I was glad I'd gotten the software to the proof of concept stage, and was REALLY glad Osher got the projectors working. When the projectors cut out on Zann, I was worried I was going to have to talk my way through it, and that would have been ugly. Without the demo, I'm afraid it would have made even less sense.

I believe the reaction to VatLife fell into four camps:

1. Those who found it incomprehensible or boring (hopefully a small minority).
   
2. Those who were interested in its possibilities, and perhaps would even use it.
3. Those who were at least mildly appalled by how it played fast and loose with biology.
4. Those who view this as related to Artificial Intelligence and not Artificial Life.

During the brainstorming session, that last view was expressed pretty vocally. I frankly don't really understand it, unless you take the view that an organism has to exist in the real world to be considered life. This seems somewhat prejudicial to me. Why should A-Life's be given less respect simply because they don't exist? I'm considering leading a march to protest this unfair treatment, billions of non-existent A-Life's marching behind me, of course.

Seriously, my feeling is that simulated organisms within an evolutionary simulation are artificial life. It's a different sort of artificial life than a real-world bacteria containing a designed genome, but it's still AL in my opinion - at least if you can get past the fact that the environments are either simplistic representations or may bear little resemblance to our own reality.

To point #3...I am sympathetic to this viewpoint. Frankly, I do feel slightly uncomfortable borrowing rudimentary principles of biology and incorporating them into my simulations, as if I were some New Ager appropriating bits of various religions for my own without fully understanding them. However, in the same way that flight was inspired by birds but airplanes do not flap their wings, I think it's legitimate to learn from nature without being compelled to copy it.

But perhaps both of these last points beg the question: what is it good for? If we're evolving stuff that doesn't teach us about actual biology, and doesn't necessarily translate into the real world, isn't it simply a toy?

First, my hope is that VatLife could support simulations involving real world physics, so objects that evolved could be built in the real world. But putting that aside, why should simulated environments have to resemble our own?

I've used this analogy before - chicken breeders may select for chickens that have meatier breasts. This is not an adaptive trait in the real world, so in a sense, breeding chickens puts them in an artificial environment with an artificial fitness function to achieve a specific goal. In our simulated environments, we can lower gravity, or make representations of inanimate objects breed, or even impose conditions and fitness functions that have no real world analogues at all. Why not breed AL's like chickens to serve our own purposes, whether or not the environments and selection criteria have analogues in "real" biology?

Ultimately, I believe the technology of evolving computer systems will have enormous implications that will touch all of our lives in very real ways. While the Evogrid and perhaps Vatlife may be interesting tools for exploring biological evolution, my personal interest is in what they can teach us about evolvable software. And if that leads to the emergence of Artificial Intelligence, then so be it. ;)

Hate to spoil a perfectly good closing line, but I did want to add that I did get some positive and encouraging interest in this technology. The comparison to MVC architecture made me happy, the use of Java as a foundation platform seemed to make the crowd happy, and OSGA is apparently something I need to learn.

source code for Micropond v1

Due to the overwhelming demand for Micropond source code (I think I've been asked twice, but I'm easily overwhelmed), I've decided to go ahead and post it.

So here it is. It's written in C++ and MFC, and is poorly documented and is totally unsupported. Caveat emptor!

MicroPond v1. source code

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