|
|
Cellz |
|
The aim of the game is to design or evolve a controller for a single-celled creature, such that creatures of your species will dominate the play area and eat as much food as possible within the allocated time.
The interface for a controller is very simple: you implement two methods - one for the force vector, and one for deciding when to split
public interface CellControl {
// return the force vector
public Vector2d getForce( CellModel me, Collection particles );
// decide whether or not to split
// will only be called when the mass is greater than
// some minimum threshold mass
public boolean split( CellModel me );
}
The game can be played for a solo-species, or in competitive mode where a species of cell tries to eat cells of all other species. Interesting dilemmas arise. Each cell chooses when to split. Splitting is good, because more cells means more parallel eating. Splitting is also bad, because smaller cells get eaten by larger cells!
View the current demo applet here (your web browser (e.g. Internet Explorer) may need the Java plugin to run this - needs JVM >= 1.2).
The image below from the Demo applet shows a single species in action based on simple greedy control logic. Hit the back button on your browser to stop / reset the simulation.
Play is on a rectangular grid. Walls can either stop, zap (kill) or rebound a cell (to be decided).
A cell has a certain amount of energy, E.
When a cell reaches maturity it divides into two cells - each taking half the energy
When a cell collides with another cell, one cell eats the other one. This can either be done deterministically with the more energetic cell eating the other one, or probabilistically in proportion to each cell's energy. In the latter case, for example, a 9e colliding with a 1e cell would have a 90% chance of eating it.
When a cell consumes another cell it takes all its energy.
Food pieces are static - once placed they do not move. Each food unit has a fixed energy which is given to the cell that eats it - cells eat food by colliding with it. Food is placed randomly on the grid at each time a piece gets eaten, with the number of pieces and the size (energy) of each piece being drawn from some probability distribution to be decided.
Cells have good sensors which tell them the location and nature of each piece of food and every other cell at each time step - these are the inputs to each cell. A future version might consider limiting this in some way, either by distance, or by using a 1-d wrap-around retina.
At each time step, the output of a cell is a force vector, which acts for the duration of a time-step, and uses an amount of energy proportional to the force applied. Hence the maximum force applied is limited by the amount of energy a cell has. The acceleration produces is proportional to the applied force, but the velocity is hard limited to VMAX. Friction acts on each cell to reduce its velocity by a constant factor each timestep (e.g. v(t+1) = v(t) * (1 - friction) - a suitable value for friction is probably 0.03.
Control: control of the cell (i.e. production of the force vector given the inputs) is performed by evaluating an expression digraph in a fixed order. Architectures that fit this model include GP-style expression trees and neural networks.
Cellz aims to be simpler than many other a-life simulations (see link below), while still offering an environment in which richly complex behaviour can emerge. When played with multiple species, it offers a very direct model of evolution. Species can mate and mutate, with strong selection pressure - the fitter offspring are less likely to be eaten!
There are many excellent a-life simulations and resources - these are a few...
SodaRace (design a super-fast spring-mass model!)
FramSticks (alife stick models)
XQuest (not a-life, just a great game - Cellz takes some inspiration from this)
MASON (fast multi-agent discrete-event simulation library)