Alife stands for Artificial Life.
I've always wanted to do my own alife program, but I didn't want to simply duplicate what had already been done in programs like Tierra, Cosmos and others. While I don't kid myself that I could make an original contribution, neither am I interested in reinventing the wheel. Recent discussions about genetic algorithms (GA) caused me to take a look at recent developments on the alife frontier, and I came up with some ideas that may be worth exploring. I outline these ideas here in the hope that people can provide a useful check on their quality and sensibilty.
C E L L S C A P E
The name of the program will be Cellscape. My original choice was Worldscape, but that name is taken. My next choice was Microscape, but a day later I fixed on Cellscape. The name will change again as soon as someone suggests a better one.
Obviously, Cellscape will need a logo. TrueCreation did the current EvC logo, we need a similar fine effort for Cellscape. Of course, there are no screenshots yet, but use your imagination.
The Cellscape Universe
The Cellscape universe will be a 3D grid that wraps at the limits. The universe needn't be a cube but will definitely be rectangular and not some irregular shape.
Each grid location is characterized by properties. Examples of properties are temperature, density (like of air or water), direction (like wind), and so forth.
Technical Issue: Since a universe of reasonable size (say, a million by a million by a million grid units) could contain a gazillion grid locations, this represents a serious software design issue. Each grid location of a large universe cannot be explicitly represented and still fit in available memory, so we must use a sparse array for the universe, but how would one represent, for example, varying temperature across the universe using a sparse array? It seems as if you would need explicit representation of the temperature of each grid location, but imagine the amount of memory required if you did this. For example, if the universe has 10
18 cells you would need 10
18 bytes to represent the temperature uniquely for each grid location. Since this is 9 orders of magnitude larger than the amount of physical memory in most PCs, this wouldn't be possible. And it's probably more than 7 or 8 orders of magnitude larger than the amount of virtual memory in most PCs, so even if going virtual were acceptable it still wouldn't be possible.
So we have to use sparse arrays, but the temperature and other properties must be represented using some broad brush approach. For example, one could imagine a function where you pass it the address of the grid location and it returns the requested property value which it derives by some means, probably from an equation or function or approximation of some type.
Each grid location of the universe can also contain a single object. Most of the universe must be empty, though, else there would be too many objects to possibly represent in a PC simulation.
Cellscape Objects
Conceptually, an object is a six sided cube which completely fills a grid location of the universe.
I've only identified a few objects so far:
- Cell membrane object
Cell membrane objects form the cell containment structure. Cells are contained within a cell wall consisting of many cell membrane objects. The fewest number of these objects that could surround non-zero grid locations would be six, which could surround a single grid location.
- Metabolic element
Metabolic elements process food into energy and waste objects.
- Energy object
Energy objects can be absorbed by other objects to provide the energy required to carry out activities.
- Food object
Food objects are consumed by metabolic elements to process them into energy and waste objects.
- Waste object
Waste objects are produced when a metabolic element processes food into energy.
Every object has one or more algorithms associated with it that govern its behavior.
Cellscape Algorithms
Algorithms are attached to objects. Algorithms control everything that an object does. Every algorithm of an object is executed once per cycle (time slot), and this is how the universe changes over time.
While I have a pretty firm idea about what algorithms will do, I don't yet have a clear idea of how they will be represented. I'll probably stay away from PLA-style approaches because even though they're extremely easy to implement and execute, they're very difficult for humans to interpret, and we want people to be able to peek inside and understand what's going on. Hence I'm leaning toward a C-like language that would be interpreted at run-time, but with an efficient non-textual internal representation that the program would use, and which would be de-compiled when users request it.
For an example of an algorithm, consider a food object. Food objects drift aimlessly through the universe until they are consumed. The drift algorithm for a food object might be this (this is just C code to get the idea across, not necessarily an implementation proposal):
// ChooseRandom returns one it's arguments, chosen randomly
xpos += ChooseRandom(-1, 0, 1);
ypos += ChooseRandom(-1, 0, 1);
zpos += ChooseRandom(-1, 0, 1);
One can easily imagine more complex drift algorithms. In this one, the food floats upward if it is warmer than its surroundings, and sinks if it is colder:
int gridTemp = GetGridTemp(xpos, ypos, zpos);
if (myTemp > gridTemp) {
xpos += 1;
} else if (myTemp < gridTemp) {
xpos -= 1;
}
ypos += ChooseRandom(-1, 0, 1);
zpos += ChooseRandom(-1, 0, 1);
If there are currents, then these, too, could be taken into account:
int xCurrent = GetXCurrent(xpos, ypos, zpos);
int yCurrent = GetYCurrent(xpos, ypos, zpos);
int zCurrent = GetZCurrent(xpos, ypos, zpos);
int gridTemp = GetGridTemp(xpos, ypos, zpos);
if (myTemp > gridTemp) {
xpos += 1;
} else if (myTemp < gridTemp) {
xpos -= 1;
}
xpos += xCurrent;
ypos += ChooseRandom(-1, 0, 1) + yCurrent;
zpos += ChooseRandom(-1, 0, 1) + zCurrent;
Objects can sense their surroundings. For example, here's the algorithm for a metabolic element checking for food in the adjacent grid locations (there are 26, and since checking the adjacent grid locations will be an extremely common operation, functions are provided to make this very easy):
foreach adjacentLocation (AdjacentLocations(xpos, ypos, zpos)) {
if (ContainsFood(adjacentLocation) {
EatFood(adjacentLocation);
}
}
There's plenty more, but that's all I have time to type in for now.
--Percy
™ Version 4.2