is on the Apple Store. Still free. Download here.
Coupla new features in this version. First of all, it shouldn't crash if the critters start reproducing out of control. Now it detects if the critter population is too high or the frames per second is too low, and it brings on a natural disaster that kills off 75% of the critters randomly.
Added a "follow top critter" feature, inspired by GenePool.
My personal favorite new feature is the Genology feature, which shows the ancestry of species. I also rewrote the help system. Both use an embedded web view, which is pretty easy way to handle documents in a mobile app.
Enjoy, and please give it a good rating if you think it deserves it!
Aside from a possible bug fix or too, I think I am done with this particular AL paradigm, unless someone out there wants to pay me bocoup bucks to work on it. ;)
Sunday, December 28, 2014
Friday, February 15, 2013
MutationPlanet for iPad
It's been a long time since I posted to this blog. Artificial life development has been largely displaced by actual life development. My son will be three in June!
But anyway, I have managed to do a little hacking on the side, and present to you this free iPad app:
https://itunes.apple.com/us/app/mutationplanet/id595896452?mt=8
Working on something else now which should be a bit more compelling...
But anyway, I have managed to do a little hacking on the side, and present to you this free iPad app:
https://itunes.apple.com/us/app/mutationplanet/id595896452?mt=8
Working on something else now which should be a bit more compelling...
Monday, June 8, 2009
VatLife update
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.
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.
Wednesday, October 8, 2008
No, this is IT!
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.
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.
Friday, October 3, 2008
okay, but that's IT!
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.
Thursday, October 2, 2008
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
Wednesday, October 1, 2008
new improved VatLife posted
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.
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.
Subscribe to:
Posts (Atom)