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.
Wednesday, October 8, 2008
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.
Tuesday, September 30, 2008
VatLife online
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.
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.
Tuesday, September 9, 2008
insomnia + NetBeans = VatLife?
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.
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.
Monday, August 18, 2008
No news...
...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.
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.
Subscribe to:
Posts (Atom)