Last updated 8 October 2006

The programs in this directory are
copyright © Risto Kauppila , 2002-2006.
You can use them under the terms of GPL licence.

If you have not previously heard of Game of Life, here is a good site to start. There are numerous other pages about Game of Life in the Web as you can find out by searching with for example "Conway's Life" as a key. I was first introduced to Life in 1973 by Martin Gardner in his Mathematical Games column of October 1970 issue of Scientific American. As an object of scientific research Life is related to two-state cellular automata, and you can sometimes find Life related topics in the newsgroup comp.theory.cell-automata.

Life is usually played on an infinite, two-dimensional grid where each cell can be in one of two possible states: alive or dead. Each cell has eight neighbours since the diagonal ones are also counted. And here are the rules for the game: The state of a cell in the next generation depends on the number of its living neighbours. A live cell stays alive if it has 2 or 3 live neighbours, in all other cases it dies. A dead cell becomes alive if and only if it has exactly three living neighbours. In cellular automata (CA for brief) terminology this is 23/3-rule, 2 and 3 for survival and 3 for birth.
An infinite grid has its advantages, no boundary means no boundary problems. Viewing can and must be done via finite viewports. But if cellular automata are considered as models for studying for example forms of biological life the possibility of finite universes should be equally sensible. Being an amateur lepidopterist who observes nature on a small island I'm well aware that there are species (especially among micros ) whose populations live often in very small habitats. The rules governing evolution of such small populations are still partly unknown. There is some evidence that cellular automata migth be used to study some aspects of insects populations.
The finiteness of the grid brings a serious problem, however, the game is sensitive to size and shape of the board it is played on. This means that results obtained in a finite board of a certain type are in general no more valid in a board of another type.
Another point Life is sometimes criticised for, is its two-dimensionality. Apparently no form of life can be treated as truly two-dimensional though Abbott's Flatlanders might disagree over that. Here we must remember a bit of history, too. It is told that when he invented Life in the late sixties John Conway used to play the game on a Go board and I for myself played it a short time in the early seventies with pen and paper. Running a 3D game at that time would have been in practice impossible. Today 3D generalisations exist but the problem with 3D is in that there obviously is no such a superior candidate for rules as 23/3 is for 2D.
An obvious way to construct a finite universe for Life is to arrange the cells as a rectangular grid or board of, say r rows and c columns, and set an extra layer of cells around the grid. The purpose of these extra cells is to hold values for the missing neighbours of the outer cells of the board. The extra values are determined by the current state of the board i.e. by functions of rxc variables. By varying these functions you can define various universe types according to your modelling needs. This way the universe can be easily implemented in most programming languages, the state of the universe can be represented as a 2-dimensional array of r+2 rows and c+2 columns.It should be stressed that the extra cells are not a part of the automaton (visible board), but they belong to the universe. In this model the automaton is (a visualized copy of) the central 2d array of r rows and c columns of the universe. This naive definition doesn't meet strict mathematical requirements but it will do at the present.
Note that the finiteness of the universe brings often peculiar boundary effects. For example, when "Life" is run in a "Mirror" universe, non-standard stable objects may appear in the boundary.
Torus is a compact surface whose topology allows us to implement Life quite easily in it using our finite universes. In xyz-space draw a circle S on xy-plane in such a way that S doesn't meet y-axis and let S then rotate around y-axis. The surface that S draws in xyz-space is torus. Alternatively we can define torus as a cartesian product of two circles. Let's now make a torus that is useful for our purposes. Take a rectangular paper sheet and draw a grid of r rows and c columns on it. Then roll the sheet and glue upper and lower edges together. Bend now the roll and glue the open ends together. Imagine for the moment that the sheet is made of rubber-like paper, strech and smoothen it and voilà, we have made a perfect torus with cells on it. The cells are not equally sized or shaped but since for two cells the property of being neighbours is clearly a topological one and not a geometric one, we don't let that bother us.

In order to study possibilities for implementing Life in other finite universes let's take a closer look at the paper sheet model above. To create torus we glued (or identified as topologists say) a side with its (unmirrored) opposite side. What if we try to glue a side with its mirrored (or flipped) opposite side? If just one pair of sides is identified this way the resulting surface is called the Klein bottle and if every side is identified with its flipped opposite side the surface is the (real) projective plane. Unfortunately both surfaces are nonorientable and so they cannot be embedded into our usual 3-dimensional space but the gluing must be done in 4-dimensional space. This is a consequence of a general theorem but a little experimenting might give you a hint that gluing without selfintersections is not possible in 3-dimensional space. Selfintersections are not allowed for embeddings.
How can we now define finite universes that would allow us to emulate "Life" in those three surfaces? Let's take a simple example of 5x5 cells and see which cells the outermost cells see as their neighbours in each case.
This is what we see in our screens and this also represents the rectangle to be mapped into higher dimensional spaces.

   1| 2| 3| 4| 5
   6| 7| 8| 9|10

Note that every inner cell has 8 well defined neighbours but the outermost cells have only 3 or 5 neighbours. In glued surfaces there is no boundary and every cell has 8 neighbours.

... 5| 1| 2| 3| 4| 5| 1...
...10| 6| 7| 8| 9|10| 6...
... 5| 1| 2| 3| 4| 5| 1...

Klein bottle:
... 5| 1| 2| 3| 4| 5| 1...
...10| 6| 7| 8| 9|10| 6...
... 1| 5| 4| 3| 2| 1| 5...

For this Klein bottle the bottom side is identified with the mirrored top side and the left side is identified with the (unmirrored) right side. The corner cells match perfectly and the identification is smooth.

... 1|25|24|23|22|21| 5...   
...25| 1| 2| 3| 4| 5|21...
...20| 6| 7| 8| 9|10|16...
...10|16|17|18|19|20| 6...
... 5|21|22|23|24|25| 1... 
...21| 5| 4| 3| 2| 1|25 ...

Here the identification cannot be done smoothly, and the choice for the extra cells near the corner is totally ad hoc. Though "Life" runs nicely in this universe except near the corners I renamed the corresponding universe "PPP", you may well think that the first P is for "Pseudo".
There is a topological reason why the real projective plane cannot be modelled correctly this way. While the so-called Euler's number is 0 for torus and Klein bottle, it is 1 for the projective plane.
Many thanks to Andrew D. Whang at the Holy Cross College, Worcester, Ma, for his valuable comments on this aspect.
I should have known this matter since it is clearly stated, in an analytic form, in one of my old math books (Problem 1.2.13 of Bishop's and Goldberg's Tensor Analysis on Manifolds, Dover, 1980). Note that I've NOT meant these three universes to be finite models for the corresponding compact surfaces. On the contrary, the surfaces with their flipping/gluing procedures have served as models for defining corresponding finite universes.
There are two new universe types in releases 0.8 of jlife and qlife, "Box" and "Mirror".


    b| b| b| b| b| b| b   
    b| 1| 2| 3| 4| 5| b
    b| 6| 7| 8| 9|10| b
    b|11|12|13|14|15| b
    b|16|17|18|19|20| b
    b|21|22|23|24|25| b 
    b| b| b| b| b| b| b

b (blank) means here dead.


    b| 1| 2| 3| 4| 5| b   
    1| 1| 2| 3| 4| 5| 5
    6| 6| 7| 8| 9|10|10 
    b|21|22|23|24|25| b

And here is firstlife, version 0.8 of my first Life applet. It has some new features so you had better take first a look at Instructions. This applet allows to run the Game of Life on a rectangular board of rxc cells where both r (number of rows) and c (number of columns) may vary from 16 to 400.
There seems to be problems with some browsers.
Linux and Mozilla/Netscpape: If the pushbuttons of the controlpanel don't respond try clicking once outside the applet.
Linux and Opera: If the applet is deformed try reloading it (even several times).
In Windows zooming should work now.
If your browser can't use a fast jit-compiler (4.x-Navigator) you should content yourself with the default board size of 80x80 cells. Within older IEs the applet runs nicely with board sizes up to 200x200 cells(check that jit-compiler is enabled). I've meant this applet to be a kind of a demo for "qlife" and "jlife", a Java Swing clone of "qlife". Compared to "firstlife", "qlife" has several extra features and besides it supports 'RLE' fileformat for saving and loading patterns. Serious "Life" enthusiasts should definitely try "qlife" or "jlife".
Firstlife is no more distributed as a separate package.

The release 0.9 of qlife is now ready. The biggest change is the rewritten "Sym" menu , see Changelog. Here is the tarball Download it and issue the command 'tar xzf qlife-0.9.tar.gz' It creates first a new qlife-0.9 directory under your working directory and puts all the extracted files there. To build the project you need Qt3 libraries and tools. I used several versions of Qt3 in my test environments. I've built the project in SuSE 9.1 with g++, version 3.3.3 and and in SuSE 10.1 with g++, version 4.1.0, and in Win2000 with Borland's bcc32, version 5.6.4 There should be no problems in building the project in FreeBSD, but in Solaris compiler and qt-version related problems may occur.

Qlife is now ported to qt4, here is the tarball for Unix and here the zip-archive for Windows. Both archives contain only the source.
I've built the project in my Windows 2000 only with MinGW. Note that the open source version of qt4 for Windows supports only MinGW.

Release 0.9 of jlife is now available."jlife" is essentially a rewrite of "qlife" in java but only the functionality of "qlife" is cloned, there are some differences between the control panels. I soon found that implementing qlife's multiline buttons is too hard and consequently the layouts of buttons differ which is very harmful, of course.
Please, don't draw any conclusions from these programs concerning the performance between java and qt technologies, speed has been of lesser importance so far. Besides, I've preferred portability to speed in "qlife". This Swing application utilizes java's new regular expressions and so java's version should be 1.4.1 or later.
Here is the jar-archive, containing source, compiled classes and docs. Download it and issue the command 'jar xf jlife-0.9.jar'. It creates first a new jlife-0.9 directory under your working directory and puts all the extracted files there. Further instructions can be found in the accompanying "README" file.

Don't hesitate to send me your comments and questions.
My email address is:
risto.kauppila at