File EGALIFE.ZIP from The Programmer’s Corner in
Category Science and Education
EGA version of the simulation LIFE. Very nice graphics.
File Name File Size Zip Size Zip Type
CHAIN.LIF 88 29 deflated
HITRUN.LIF 307 95 deflated
INST.DOC 8339 3553 deflated
LIFE.EXE 44144 23754 deflated
PATTERN.LIF 184 35 deflated

Contents of the INST.DOC file

LIFE Documentation Page 1 08/07/1989

LIFE is provided free of charge. You may copy and distribute the program
as long as this file is included and remains unaltered. For a copy of the
TURBO PASCAL 5.0 source code, send \$10 and a 3.5" or 5.25" disk, or \$12 alone
to:

Andrew Kirmse
9303 Arabian Avenue
Vienna, VA 22182

Please specify whether you want a 5.25" disk, 3.5" disk, or hard-copy.

* * *

Life was first described by Martin Gardner in Scientific American, and
first implemented by John Conway at Cambridge. The game operates on a two
dimensional matrix by applying the following set of rules:
1. Every live (or "on") cell that is touching two or three adjacent live
cells survives to the next generation.
2. Every live cell with zero or one neighbor dies from isolation.
3. Cells with more than three neighbors die from overcrowding.
4. A dead ("off") cell with exactly three neighbors becomes a live cell
in the next generation.

Each cell has eight adjacent squares, the four compass directions and the four
diagonals. The program finds the number of neighbors of each square in a given
generation and then decides its fate in the next generation. Ideally, the game
would be played on an infinite plane, but I was unable to locate a sufficiently
powerful computer. This simulation can handle about 120000 cells or so if your
computer has 640K, otherwise you'll have to find the largest size your system
will support. I don't recommend using such enormous matrices (they're slow).

There are three possible dead-ends in the evolution of a Life
configuration. The entire screen could die out, the system could degenerate
into a group of special shapes that I call "stables", or in rare cases things
can oscillate forever. Let me explain.

A two by two square is stable. If you look at its shape:

**
**

you see that every cell is touching three others, thus they all survive. In
addition, no cell adjacent to the square has three living neighbors. Thus, a
lone square in Life just sits there, uninterrupted, forever. These patterns
are also stable:

* * ** * *
* * * * * * * * *
* ** * * * * * *
** * *

LIFE Documentation Page 2 08/07/1989

Whereas those patterns do nothing, this one oscillates with a period of two
generations: *
*
*
The center square stays alive while the outer two flip from horizontal to
vertical. There are a few other oscillators, even one with a three generation
period! (Try CHAIN.LIF)

Here's an infamous character, Life's rogue:

* *
**
*

This pattern "moves" to the lower right, leaving nothing in its path.
Some call it a mover, but I like the term "killer" better because of what this
critter does when it hits a square. If the phase is right, they mutually self-
destruct. (Try HITRUN.LIF) A favorite pastime is setting up armies of killers
and sending them at each other. The last one left unmutated wins.

That might take a bit of explaining. If you play Life enough, you'll see
certain patterns over and over. Nearly all of these will be symmetrical. On
the other hand, there are shapeless, non-symmetrical blobs of life that
eventually (after maybe 100 generations or so) settle down (or die off) into a
pattern of stables. Similarly, two familiar patterns such as killers can form
mutant blobs when they collide. Chaos from order, what's the world coming to?

So much for the game of Life itself. You may want to practice with pencil
and paper for a while to convince yourself that the rules really do make
killers move and oscillators turn. Now on to the program itself.

You might first notice when you run LIFE that there's a version number
under the title. Version what? 1.0? Is that all? Yes, this is my first
attempt, and there are undoubtedly bugs and "undocumented features." If you
have comments, suggestions, frustrations or insults, direct them to Chris
Kirmse on a BBS, or write to me directly. If there's enough interest, you may
eventually see a version 1.1, or--perish the thought--2.0!

At the main menu, you can choose either to fill a matrix randomly or
manually. The first option asks you for the size of the matrix. As I
mentioned, the maximum size will vary with your computer's memory, but 200 by
200 is more than you could possibly want. I suggest 50 by 50 as a working
standard, but if you decide to test the limits of your RAM, runtime error
number 203 is a heap overflow.

Next is the density, a real number from zero to one. This represents the
fraction of the matrix to be filled with live (or "on") cells. Then you enter
the display frequency, usually 1 for small sizes, and away you go. I suggest
viewing large matrices only every 10 generations (or more) because of the huge
time it takes to display those monsters. Speaking of display, this program
requires an EGA graphics adapter. If you don't have one, sorry for making you

LIFE Documentation Page 3 08/07/1989

The display is color coded depending upon the age of the cell. A cell
that has been "on" for the last 4 generations running will be shown in red,
while a newborn cell is dark blue. Anything over 14 generations (usually a
cell in a stable pattern) is white.

Hit escape during the run to go to the editor. You may have to wait a
while for the program to detect it, redisplay the screen, and call the editor.
When in the editor, use the arrow keys to move (diagonals included), insert
(number pad 0) to flip a cell from dead to living and vice versa, and space to
age a cell. Make sure Num Lock is off. I usually use the space bar to create
life anyway because it's more convenient.

Pressing escape again gets you to the editor menu. If you save your file,
it's best to leave off the extension; the program will automatically add a
'.LIF' extender to mark it as a Life file. The same goes for loading a file,
which is found by pressing 2 at the main menu.

One more note about how the program simulates the game of Life. Simply
put, the game is played on a torus (a doughnut for those non-mathematicians
among you). In other words, the right side wraps around to the left and the
top to the bottom. If you visualize the board being rolled up first vertically
and then horizontally, you should be able to see that the four corners of the
screen are actually adjacent. Keep this in mind when you create screens.

I mentioned earlier that in some cases the screen keeps evolving forever.
Well, not exactly, but to see what I mean, try running a randomly filled (.5
density) 6 by 300 matrix. You should see a strange pattern of lines
developing, and in about 400 generations they will most likely take over the
world. However, they never stop shifting up and down. This situation is
technically an oscillation, since the simulation is deterministic and you'll
eventually repeat a pattern, but it's odd nonetheless.

I've included a few interesting starting pattern files that you might want
to run. You might notice that the save format I use is extremely simple, so
you should feel free to write your own editor if mine seems too shabby. You
could also report any interesting finds you make by uploading screen files to
various BBS's.

Thanks for plodding through this rather long documentation; I hope it
gives you a good idea of how Life the game and LIFE the program work. Enjoy
the program, and feel free to report any suggestions you have for improving it
in future versions.

---Andrew Kirmse

December 25, 2017