Scott Schafer's A-LIFE blog

VatLife update

2009-06-08T12:35:00.000-07:00

The latest on VatLife: I've done very little coding on it, mainly owing to a lack of time. I began an attempt at a tic-tac-toe playing environment, I've thought about adapting both Tom's noble ape brain as a controller, and Scott Davis' Bubble Pond as an environment, and I rambled about it on "Visions of the Evogrid".

Which on the one hand, seems entirely inappropriate, given that the Evogrid (opposed to Biota Eve) is now about artificial chemistry, and VatLife abstracts all the details of self-replication and has the genome as a primitive. And this isn't something I apologize for. I don't think one is necessarily better than the other, they are simply different approaches.

Yeah, the idea of self-replication occuring within an artificial chemistry is more pure and I can see why it would be more appealing to biologists in particular. However, the abstracted approach has produced tangible products, such as circuits and satellite antennae. This is a tiring debate...I wish the two approaches could simply co-exist in peace without the need to rank them or dismiss one or the other.

Anyway, after the recording with Tom I wrote down what I wished I had said, and here it is:

What I attempted to achieve with VatLife was to create a framework that met two main goals: make it a little easier to create a genome-based artificial life simulation by providing a simple set of generic tools, and to put an abstraction layer between the phenotypes of a-lifes and how they act within their environment. My thought there was while A-lifes within a 2D or 3D simulation might evolve to look radically different, they might share the same kind of evolving logic. For example, both a 2D and a 3D environment could contain a-lifes that used something like the Noble Ape brain to interact with their host environments, while these same environments could simulataneously host a-lifes that used different kinds of evolvable controllers.

An a-life in VatLife therefore has two genomes, much as a cell has both nuclear DNA and mitochondrial DNA. The first genome is used by its host environment to produce the a-life's initial phenotype, and the second which specifies its initial control logic. It also contains an ID to the controller that interprets the second genome to produce an initial brain, and interpret it against its host environment. Just as our brains are a product of both biological evolution and development after birth in response to our environment, the idea is that even something like a neural net would benefit from an initial seeding from a genome that evolved through natural selection.

A nice benefit of this structure is that you can author environments and controllers separately, which is particularly useful when the behaviors are not entirely determined from the phenotype. So you can author a simulation and immediately have a-lifes with evolving brains attempting to exploit the constraints of your simulation.

It would also be possible for a VatLife a-life to cross over from one environment to the next, although since each environment would intepret the phenotype-controlling genome differently, it would probably not be likely to succeed.

This model allows for a very different kind of interactions between simulations, one that's less focused on creating a common vocabulary so simulations can interact on a high level, and more focused on leveraging existing code for faster development of evolutionary simulations. At the same time, there's no reason why a VatLife simulation couldn't communicate with other Biota Eve style simulations.

A demonstration of VatLife is hosted at www.ripplingloop.com, which currently has a simple environment hosting a-lifes that can use one of two controllers to interact with their environment. Links to source code and to my blog are also on that page.

No, this is IT!

2008-10-08T02:36:00.000-07:00

Really, I mean it. ;)

Apart from data persistency, the main features are in place, the performance is much better, and the source code is posted. Share and enjoy.

If anyone has luck creating a kick ass controller or environment, I'd love to hear about it.

okay, but that's IT!

2008-10-03T02:31:00.000-07:00

I promised myself I'd stop working on this. My goal is to put together some rudimentary documentation, post the source and be done with it for a while. But lying in bed tonight unable to sleep seemed unproductive, so I implemented another selection strategy in addition to the generational/constant population approach, which is to killing off all a-lifes below an energy threshold and breeding those above. This now happens pretty frequently, and the results seem to be much faster evolution.

2008-10-02T15:31:00.000-07:00

An image from VatLife - the polygonal environment, anyway. Check out the critters on the upper right, which seemed for a while to be about to take over the whole top surface. That line of critters did extend to the left for a while, under another critter evolved that messed up their scene.

I think the constant population selection scheme is unfair to the successful adaptations. But who said a-life is fair?

www.ripplingloop.com

new improved VatLife posted

2008-10-01T12:43:00.001-07:00

A fresh new version can be found at www.ripplingloop.com. Spore it ain't, but I think the scientific underpinnings are better. ;)

So what are all these shapes and lines about?

First off, VatLife is a platform that separates the "environment" that creatures inhabit (which includes their physical form) from their "controllers", which contains logic for how each creature interacts with its environment. The thinking here is that any a-life can use any controller in any environment, and thus could migrate from one environment to another.

Because the environments and controllers are separate from VatLife and are loaded dynamically, what you're seeing isn't VatLife itself, but VatLife running a simulated environment with simulated controllers. The reason this is exciting to me is that someone out there could write a better evolvable controller, upload it, and it would just work in this environment (or any VatLife environment).

Enough preamble. The way this particular environment works is that each a-life has the physical form of a polygon, and will gain energy when "sunlight" (the vertical yellow lines) hits a face. Note that polygons can shade other polygons. Every a-life also loses energy each turn. The energy is shown by the polygon's color. Brighter colors mean higher energy, gray means low energy.

The simulation starts by generating twenty a-lifes using randomly generated genomes and randomly selected controllers. I've supplied two different controllers, neither of which are particularly good. The green polygons use one controller and the red polygons use another. The VatLife produces a polygon for an a-life by interpreting its genome. Complex polygons are allowed, but since they shade themselves, they're quickly selected against.

Periodically, the lowest-energy 50% are killed, and the top 50% are reproduced (with random mutations) to maintain a constant population. When this happens, you'll see a new "Generation #x" appear in the message box. I also give the existing a-life a good shake, so the new ones don't just settle on top of the old ones and shade them out.

So, what do the controllers get to do? Same as any VatLife controller - it can read and write pin values. In fact, I basically reused the controllers I'd used in the VatLife demo from two month ago. The environment handles pin I/O this way:

1) For an a-life, there are as many pins as there are polygon faces, with no child pins.

2) Each pin returns a value from 0 to 1 based on the amount of sunlight that polygon face is receiving.

3) Writing a value to a pin applies force to the polygon in the opposite direction that the face is pointing.

In other words, if a polygon has 4 faces, and it's rotated so that face #2 is on the bottom, reading pin #2 will return 0 (no sunlight) and writing to pin #2 will propel the a-life upwards.

If it's not obvious by now, that's what those magenta lines are about - they indicate the force that was applied from writing to a pin. If you see a line going on and off, that means the controller is using logic to control its propulsion.

Incidentally, the physics here isn't quite accurate on many levels. The force is applied to the center of the mass, not the center of the face as is shown. It's also a reactionless jet, which I'm very excited to have invented. ;) There's no fluid dynamics in play, although the top area above the blue background is a high gravity zone, which gives it some properties of being "above the water line".

Unfortunately, there's no data persistence - the simulation starts when you bring up the page and ends when you close it. With data persistence, you could have multiple environment in the central repository. Different users could sign in and simulate an environment for a number of turns, and evolved a-lifes could migrate from one to the other.

Unfortunately, all of that will have to wait, as I'm needing to turn my focus away from my hobby - and I'm curious to see if other people see value in this platform before investing more time in it.

I'll try to make the source code and some basic documentation available soon. Gerald de Jong has graciously offered to give it a code review, which is like having Leonardo da Vinci for your first year art teacher, so I will be polishing it first. This will be entirely open source.

Feedback, comments, questions are appreciated.

VatLife online

2008-09-30T01:12:00.000-07:00

In advance of tomorrow's GT meeting, I have my my first online version of VatLife up at www.ripplingloop.com. Comments are welcome.

Right now I have a single environment and two different single controllers (which are almost identical), both dynamically loaded from JAR files. In this environment, each a-life is a simple 2D polygon of up to five vertices, and gains energy by having an upward facing face that isn't shadowed by another a-life. The energy of each a-life is gray when low and more saturated when high.

Also, just to keep it interesting, the critters don't get energy if the "sunlight" hits them on the very top of the screen.

I decided to give each critter two different genotypes: one used by the environment to determine the initial form, and one used by the controller to determine the mind. My original thought was to use the same for both, but decided this would prevent the possibility of critter migration between environments.

In this environment, each "critter" has the same number of pins as it has faces, with the pin value returning the amount of energy that face received. Writing to a pin adds force in a particular direction.

Periodically the worst performers (the lowest energy a-lifes) are killed off and the best performers are reproduced with occasional mutations.

And incidentally, this could run way faster. I profiled it and found that the collision detection (from the Phys2D library I'm using) is taking about 90% of the time. I'm sure this could be cut down significantly. But of course, the environment is really just another proof of concept.

insomnia + NetBeans = VatLife?

2008-09-09T05:08:00.000-07:00

At least that's what I'm hoping.

So I've switched from using Eclipse to using NetBeans IDE 1.6. Originally I was considering using JavaBeans as a component model, but that seemed like overkill. I looked into OSGi and Knopplerfish but found myself getting lost in documentation...and it again seemed like overkill.

At the moment, I have controllers and environments dynamically loaded as JAR files. Nothing mindblowing there, but it's a good start.

I really love the NetBeans IDE, even if I am using just a small fraction of it. Although it does have a few quirks I'm learning about, it's remarkably intuitive and just a GREAT tool for someone like me who's learning the language. The warnings are clear and helpful, the interface is intuitive and flexible, and it's just extremely well polished. I love the refactoring (just drag code from one package to another - or even one project to another - and it fixes all the references), the automatic code formatting, the list goes on.

Excellent job, Sun engineers.

No news...

2008-08-18T15:21:00.001-07:00

...is, well, no news.

VatLife is on hold for now. I've gotten busy with work, remodeling the houseboat and family visits. However, my wife is going to a five day conference in early September, and I'm planning to spend some time cranking on it while she's gone.

It don't mean a thing if it ain't got that swing

2008-08-03T15:03:00.000-07:00

Would jazz make any sense if you'd never walked through a city, heard a train whistle, knew speech patterns? Would blues make any sense if you never felt blue? Actually, would music make any sense at all if you'd never heard (or possessed) a heartbeat?

This, oddly, is an inspiration for VatLife.

Let's say the fitness function in a evolving environment is that a-lifes are rewarded if they can predict the next number in a sequence. So, let's say the sequence is 1, 2, 3, 4. It world not be difficult for most evolvable machines to predict the next number. 1, 2, 4, 8 would also be a fairly easy sequence to predict.

Now, let's say the sequence is 3, 1, 4, 1, 5, 9. Clearly, these are the base 10 digits of pi, but since it's not a smooth problem space to go from the first two sequences to that one, I don't think there's any way for a-lifes to make that evolutionary jump. Not without some outside experience. And even then, it seems necessary for the a-life to learn the digits of pi, rather than to figure that sequence out. It seems pretty safe to say that there's never been a human being born on this planet who could predict the digits of pi without some kind of mathematical training.

Could an a-life evolve in a different environment and gain the knowledge to be able to solve that problem? It's hard for me to picture that happening with that specific problem. But just as life experience in extra-musical domains is necessary to truly understand music, a-life experience from many different simulated environments may be necessary to solve the problem at hand.

Incidentally, this may sound like AI training, but I'm talking specifically about breeding ALs that are capable problem solvers. Although...this does argue for individual VatLife creatures with life experience crossing from one environment to another, not just their genotypes and controller IDs. And perhaps a VM that is designed with the goal of allowing VatLife's to pass knowledge between individuals.

Better (artificial) living through chemistry?

2008-08-01T17:00:00.000-07:00

Just got caught up with my Biota podcasts and GT presentations. I particularly enjoyed Bruce's presentation at Greythumb London.

I believe it was in the London GT meeting that Bruce quoted a simulation author who said that there's always an IOU you have to write. In other words, there's always going to be a part of the simulation where you wave your hands a bit. This makes some sense...if you are trying to simulate the spread of a virus in a human population, it makes sense to simulate the mobility of the population, but why waste the effort simulating the internal combustion engines that are getting people from point A to point B?

Actually, that's not such a great example, because no one would expect you to repay that IOU. We all know in abstract terms how cars allow people to move from here to there, and so it would be unreasonable to expect your poor CDC epidemiologist to have to model reality beyond the minimum needed to solve the problem.

So, do we write an IOU that we have to repay when we create simulated organisms that use genetic information to control their form and behavior without actually modeling the underlying chemistry?

I think it all depends on your perspective. If you're a biologist, or if you want to evolve something in your simulation that might exist in the real world, then you'll need a high adherence to reality in your simulation. But since all simulations fall short of reality, I think requiring accuracy is something of a losing game.

Case in point: the three body problem. If you just have three objects that interact with each other - for example, a planet, moon and sun - there's no way of exactly determining what effect each body has on the others. You can only approach a solution. So what if you have a billion bodies in interaction? And how far down do we take this...do we model subatomic particles, and then do we store their location OR their velocity?

But let's say that we model atoms and molecules, and we have good approximations of their interactions. We ignore relativity and just use Newtonian physics. How large a world can we model? As fast as computers get, and even writing our IOUs, I'm skeptical that we could model a very large volume of space in real-time. Since it took something like two billion years for multi-cellular life to evolve in the vast oceans of Earth, I don't hold out too much hope we'd see this in a computer simulation.

But if we did, what of it? Creationists would say that the simulation was flawed and created by proponents of evolution, and both charges would be true. It might be confirming evidence of evolution, but do we need more confirmation?

So while I see this as a very interesting enterprise, I'm skeptical of this approach as yielding useful results. Interesting perhaps, but I'm not sure about useful.

My personal preference at this point is to say: hey, evolution works, and it's given us these great design patterns - such as DNA and a central nervous system. What can else can we do with those design patterns? And then, like the CDC epidemiologist, we can make a simplified simulation that yields useful results without worrying about the tire pressure of the virus' host's car.

All JMO.

Open-sourcing VatLife

2008-07-31T11:37:00.000-07:00

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

2008-07-30T03:03:00.000-07:00

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:

Those who found it incomprehensible or boring (hopefully a small minority).
Those who were interested in its possibilities, and perhaps would even use it.
Those who were at least mildly appalled by how it played fast and loose with biology.
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

2008-06-29T11:52:00.000-07:00

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.

2008-06-26T12:41:00.000-07:00

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

2008-06-03T14:49:00.000-07:00

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)

2008-06-02T22:27:00.000-07:00

<-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

2008-06-01T22:59:00.000-07:00

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

2008-05-31T14:33:00.000-07:00

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

2008-05-31T14:26:00.000-07:00

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.