Last edited 05may2008 by Nathan Baird
CellAuto: Cell Automation in the Cube
The game of life is a simulation of environmental situations. Cells live or die according to rules referred to as the cellular automation. In the cube, this will be a three-space representation. By being able to remove or add cells will, one can study population effects and other patterns.
Here is an example of a game of life.
The original game of life was made by John Conway in 1970. He spent a lot of time finding a rule set that had an optimal amount of live cells to avoid overcrowding or extinction. The rule set is as follows. For a cell to stay populated, it must have exactly two or three neighbors. For an empty cell to be populated, it must have exactly three neighbors. For ease of description, further life rules will be descibed in this form (lmin,lmax,bmin,bmax), representing the birth and life minimum and maximum neighbor requirements. Conway's life was a (2,3,3,3)rule set. His life originally appeared in Scientific American. Since then, cellular automation has become a substantial mathematical field. Many standard patterns now have names such as the block, beehive, boat, and many more.
There are also catergories of patterns that generate cells such as puffers, breeders, guns, and rakes. There are many variants of his system today as well. The makeup of the grid has been manipulated to hexagons or other configurations. There have also been many differnet proposed rule sets, some that can be run simultaneously with each other.
A Little Math and Brief Life Conclusions
Just as Conway had to struggle to find the optimal set of rules for his two dimensional life, my three dimensional life begged the same attention. As most of my time has been put into adding features into the program, I have not done anything near a comprobable job on studying possible rule sets.
The first issue I noticed is the way neighbors are counted. My CellAuto has the capability to count six neighbors, the ones that have faces touching the cell in question. This can quickly lead to areas of the environment that get deserted. If you make a plane cut (xy plane etc.) in the environment, there is only one cell that gets counted accross the border to birth a cell on the other side. Unless your rule set accommodates only one neighbor births, no life will grow outside of it's initial cutting plane. The means that this life can't have any generators similar to Conway's buffers and breeders. In little testing of such rule sets, either small areas became stable two-step oscilators or it blew up.
So instead, I dabbled in letting cells become populated if they have one neighbor and a cell stay populated if it had one neighbor(this is a (1,1,1,1) life). This effect overcame the expansion issue of the limited neighbor set. However, all patterns produced by this life either blow up, or stay very geometric. Starting with just one populated cell leads to an expanding shape in space that resembles a sierpinski octahedron. This shape oscilates in size by doubling in size when the number of generations double. Every power of two steps, the life goes back to an expanded state that resembles the initial state.
When wrapping was added to this environment, it effectively limited the space in which this life would grow. Based on the dimensions of the limited environment, the life would either blow up, go extinct, or reach a stable oscilation configuration that would repeat in a number of generations linearly related to the size of the environment. In short, this life seemed to have poperties of arithmetic and geometric series but represented in three space.
Horizon: Additional Features and Case Studies
There are two features that, if added, would add much to this program.
1. A good way to set initial configuartions. This could be done through reading files containing the initial data or having a way for the user to set them while running the program. THe later is much harder however due to the visual confusion of adding or subtracting populated cells in three space.
2. An option to change the neighbor set. How many neighbors that are counted greatly affect how the life behaves. Having an option to change the neighbor set to twenty six would be very beneficial.
3. A better way to dynamically change the rule set. Currently this has to be done by changing the SIZE variable and recompiling. This needs to be changable while the program is running, and possibly letting the environment not be a cube as well.
As for other nonsense, there are many rule sets that would need to be tested to attempt to discover interesting results. Three case studies that come to mind are as follows.
1. Max population. When a life blows up, what is the max supportable population based on a space? For the (1,1,1,1) life, it would fill roughly 28.9% of the space it was allowed. How does this change based on various rule sets and neighbor counting schemes.
2. More dimensions. Just as my life increased dimensions from two to three, the amount of dimensions could go even higher. This is a struggle to visualize but problems like the max population one above could still be analyzed.
3. Multiple rulesets in the same environment. This one is perhaps the hardest to analyze. However, if a successful way to take data could be found, this could represent more natural issues such as viruses.
In short, there is a lot of experimenting with this program that I was unable to do. I hope that someone, be it myself over the summer or others, will be able to discover some of the intricacies of cell automation in three dimensions. This project is certainly a decent start.
Berlekamp, Conway, and Guy: Winning Ways (for your Mathematical Plays), Volume 2, (c)1982.
Callahan, Paul. "What is the Game of Life".http://www.math.com/students/wonders/life/life.html