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!

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!