Cellspace is a cellular automata based rule system that can be used to create games. I developed it some time ago. My goal for LD56 is to start on a graphical user interface for Cellspace. I tried to "gamify" it by defining some levels you can play around with by defining rules. There are no clear goals, though some levels suggest concrete goals.
I want to develop this into a full fledged graphical IDE in which you can make your own games. This would require at least a level editor and win/lose conditions. Note that it is already possible to control rules using the W,S,A,D keys, using the "playerdir" option.
Cellspace is based on the classical 3x3 cellular automata, but is more complicated, because the output of a cell rule is not just the center cell, but can be any of the cells in the 3x3 grid. This extra complexity makes it possible to specify various games, including a full implementation of Boulderdash. The system handles complex cases meaningfully, such as blocking rules that have output that overlaps with a rule that is already applied, handling competing rules, and randomizing rule execution order to avoid bias. Also, it tries to animate moving sprites smoothly.
>>>Play CellSpace here!<<<
Here are some examples of nice looking rule systems.
Example 1: different animated cells

At the bottom left are moving cell colonies (cyan) that propagate and die with random probability. This can be described with two rules:

rule5 indicates propagating the colony to a neighbouring spot with probability 0.33, while rule6 indicates dieoff with probability 0.2 when a colony already has a neighbouring cell. With the rot4 option, the rules are rotated in all directions, creating four competing rules that are randomly selected, resulting in random propagation in all directions.
At the bottom right are "pacman" (red) cells that move around and propagate randomly. This can be described with two rules:

rule_0 indicates that the "@" (pacman) should move right when there is an empty spot there. Again the rot4 option rotates the rule in all directions. Note there is also an outdir "R" defined, which sets the direction of the new "@" to the right. This means the sprite will face right.
rule_1 again indicates that the "@" should propagate with low probability, that is, create a new "@" in an empty spot without removing the old one.
At the top left are moving cells (blue) that leave trails behind (green). They prefer open space over already laid trails, so that they try to explore new areas. This can be described with 3 rules:

rule_2 indicates that an "o" (the blue circle) should move left when there's an empty space ("-"), and should leave a trail behind (":"). With the rot4 option, rule is rotated in all directions, resulting in four competing rules that are randomly selected, resulting in random movement.
rule_3 indicates the "o" moving across an already laid trail, but this rule has lower priority (1 instead of 2).
rule_4 indicates that the "o" should spawn (create a new "o" without removing the old one), when there is an empty spot, again with low (1 in 10) probability.
The self-generating maze (yellow Xes) in the middle can be specified with a single rule, given in the next example.
Example 2: Harvey Wallbangers in a self generating maze
Harvey Wallbanger is a robot that can find the exit of any labyrinth (= maze without loops) by just following the leftmost wall.

The Harveys (cyan) are controlled by the following rules:

Rule_3 generates the maze, the other rules govern the Harvey Wallbanger movements. Note it keeps track of the center cell direction via conddir, which specifies that the center cell should face in that direction.
Example 3: self eating maze

The following rules specify the self-eating walls:
