Provided by: xlife_5.0-8_i386
Xlife - Conway’s Game of Life, for X
xlife [-geometry string] [initial pattern file]
brings up a single window in which the user may experiment interac‐
tively with cellular automata. In its default mode, the program helps
the user play with John Horton Conway’s ‘Life’ game.
By default Xlife will run in a window taking up 4/5ths of your screen;
you can use your window manager’s Zoom or Resize feature to make it
fill the whole screen. This window is a viewport on a universe which
is effectively unbounded (4.2 billion on a side).
The -geometry option sets the Xlife window size and position as per
usual for X applications.
8 Move your view of the universe up.
2 Move your view of the universe down.
6 Move your view of the universe right.
4 Move your view of the universe left.
5 Center the universe on the screen (based on average
position of the cells).
. Center the universe view on the cursor (also Button
2 in normal mode).
=,+ Zoom the view in, magnifying the area around the
- Zoom the view out.
g Toggle running the game.
o Step forward one generation.
S Save the universe to a file adding extension .l.
If there is currently a boxed pattern, only the
boxed pattern is saved.
l Load (actually add to) the universe from a file
with extension .l. This lets you overlay multiple
saved states to make for some interesting effects.
Loaded pattern is initially considered tentative,
and may be manipulated in various ways before
incorporating it into main pattern. (To indicate
this, it’s surrounded by a bounding box.) Clear
the universe if you want to start from scratch.
Load assumes pattern is in last directory accessed.
h (Hide) stop displaying after each generation, does
c Toggle showing of cell counts
? Help for xlife.
! Place random cells on the area of the universe on
r Redraw the screen.
R Change the (2-state) rules in "stays alive
on"/"born on" format. The standard rules are 23/3
(alive on two or three neighbors, birth on three
neighbors for an empty cell). Alternatively,
enable a payoff matrix with the syntax
<float>$<float> as described in the PRISONER’S
F Load n-state rules from a given file (see the N-
STATE SUPPORT section below).
N Change the file’s internal name.
A Add comments.
V View comments.
C Clear the universe. If there is a boxed pattern,
clear that instead.
f Run at a fast speed (no delay)
m Run at a medium speed
s Run at a slow speed
p Toggle running display of mouse position. Position
is only for reference during a session, and does
not effect coordinates of saved points.
O Set current mouse position to be the origin of dis‐
G Generate tentative loaded pattern for one or more
U Undo load of tentative pattern.
I Force tentative pattern to be incorporated into
main pattern (automatic with g, h, o, l, and W com‐
W Write (and flush from memory) script of loaded pat‐
terns into a file with ’.’ extension. When
loaded, this script corresponds the earliest ances‐
tor of current pattern that can be reconstructed
from loaded patterns (does not included changes
made with mouse). Origin of written pattern is
mouse position when ’W’ is typed.
D Discard current load script, including any tenta‐
tive pattern, but leave cell population intact.
(Helpful for using an old pattern as a template to
construct a load script).
1 Activate a cell at the cursor.
2 Erase any previous selection box. If you drag the
cursor with button 2 held down, then release it,
the rectangle between the press and release points
is boxed and made tentative (as though it had just
been loaded and not yet incorporated). The tenta‐
tive pattern can then be moved, flipped, and
rotated before re-incorporating it.
3 Delete a cell at the cursor.
1 Move pattern to current position.
2 Flip pattern about its x-axis.
3 Rotate pattern clockwise about its origin.
A .l image file is an ordinary text file consisting of lines terminated
by the newline character. It is interpreted as one or more image sec‐
tions separated by section lines beginning with ’#’. Lines led by ‘##’
are considered comments and ignored.
Each image section is interpreted according to the format letter fol‐
lowing its section line #. The format letters are:
A -- Absolute. Each line is interpreted as an absolute (x,y) coordi‐
R -- Relative. Each line is interpreted as a relative (x,y) coordinate
P -- Picture. Each line in the section is interpreted as a scan line
of a relative image. Each ’*’ character turns the corresponding bit
on. All other characters leave the corresponding bit off.
I -- Include. A #I line should have whitespace-separated fields after
the #I consisting of a pattern name and five optional integer parame‐
ters (x, y offsets, rotation, flip, and delay as defined in section on
inclusion, below). The named pattern is loaded as if it had been
included in the image at this point with the given transformation
applied. The offsets, if present, displace the load point of the pat‐
tern relative to the current mouse position. The include facility is
useful for assembling ‘sampler’ collections of interesting patterns, as
well as maintaining structured representations of complex patterns.
B and E -- Pattern blocks. Patterns enclosed by #B <name> and #E lines
are skipped when loading a whole file, but may be accessed by adding
:<name> to the file name. They are useful for bundling related pat‐
terns into the same file. Access is by sequentially skipping lines not
in the block, so excessive numbers of blocks in the same file may slow
down the loading process. Pattern blocks may not be nested.
Relative image sections are normally drawn with 0,0 on the current
mouse position (coordinates may be negative). This may be changed by
including a pair of whitespace-separated integers after the format
character. If this is done, these will be interpreted as a pair of x
and y offsets, and the image section will be drawn with its upper left
corner displaced from the cursor position by those offsets. This facil‐
ity can be used to write image files that will load patterns centered
on the cursor.
A leading image section with no header line is treated as though it had
a ‘#A’ header. Thus, version 1.00 image files will load properly.
N -- Name This line contains the internal name of the pattern (which
may differ from the XXX.l name of the file.
O -- Owner This line contains information on the person who wrote the
file, it is written in the form: id "name"@machine date, for example.
#O jb7m "Jon C. R. Bennett"@sushi.andrew.cmu.edu Fri Jan 12
C -- Comment Lines beginning with "C" are comments that the user may
have automatically written to the save file, and which may be viewed
from within Xlife.
U -- Use Format is #U followed by a filename. This directive is ignored
if Xlife is in 2-state mode. In N-state mode (see below), it loads a
rule-set file just as if the user had typed in the name. If the named
file is already loaded, it will not be reloaded.
More section formats may be added in the future.
The #I command, as described above, has the following format:
#I <pattern> <x> <y> <rotate> <flip> <delay>
Any prefix of fields that includes a pattern name is acceptable, with
the natural defaults (no delay, no flip, no rotate, no y or x offset).
In the above
is a pattern name (described below);
are integers representing horizontal and vertical offsets; and
is an integer that specifies the number of times the pattern is
rotated 90 degrees clockwise around the origin. Any rotation
value (positive or negative) is acceptable, as all are taken mod
4 (true mod, not "%").
is a multiplier (1 or -1) for the y coordinate that specifies a
flip about the x-axis. Other integers are accepted and silently
mapped to 1.
is an integer specifying the number of generations to perform
before loading the pattern (negative values have same effect as
Note that all of the transformations applied to an included pat‐
tern are taken relative to the pattern that includes it. Thus,
loading an assemblage of included patterns works as one would
A pattern name takes one of the following three forms:
<file> include whole file <file> (like old format)
<file>:<name> include pattern block <name> in <file>
:<name> include pattern block <name> in current file
(Note that <file>: is not allowed.)
A file may also include literal or pattern blocks. A pattern block is
a pattern given in any acceptable format between a line containing "#B
<name>" and another line containing "#E". Pattern blocks are skipped
when including a whole file.
(Note that pattern blocks cannot be nested.)
Xlife includes support for automata with up to 8 states using the (von-
Neumann-style) 4-cell rotationally symmetric neighborhood; to invoke
it, load a rule-set file using the ‘F’ command. Many interesting
automata including the Wireworld construct and the UCC described in E.
F. Codd’s 1968 ACM monograph can be implemented by specifying appropri‐
ate transition functions.
When Xlife is used in this mode, the program uses color to indicate
states. Pattern picture files may contain digits to specify the states
of picture cells; ‘*’ is interpreted as 1. Color-picker radio buttons
are set up at the right-hand side of the input window; by clicking your
cursor on a button, you set button 1 to paint with that color. You can
return to 2-state mode with the ‘R’ command.
Refer to the rule-set file ‘codd.r’ for an example of transition defi‐
nition syntax. Each line contains either a directive or 6 digits
For <old-state> or <neighbor> you may also specify a state set; digits
enclosed in square brackets. This wild-cards the transition in the
obvious way. Comments (begun with ‘#’) are permitted in the file.
You can arrange for rulesets to be loaded automatically by putting a
‘#U’ directive in a pattern file. When you save a pattern, a #U is
automatically generated into the save file giving the name of the cur‐
tells the code what the automaton’s count of cell states is. The
default is 8.
If, while evolving a pattern, the code finds a cell and neighborhood in
a state for which no transition has been specified, the program queries
the user for a new state, and the tuple implied is added to the
database. This behavior can be modified by including a line of the form
which instructs the code that all combinations of cell and neighbor
states up to and including <maxstate> for which there is no explicit
rule leave the cell status unchanged. A ‘passive’ declaration in a
rules file can be partially overridden by later, explicit transition
You can also specify rules depending on a neighbor count. A rule line
of the form
with S, N, C, and R being digits, is interpreted to mean that if a cell
has state S and exactly C neighbors of state N, the result state is R.
For an example of usage, see the Wireworld rules file.
When the evolution function encounters a neighborhood for which there
is no defined transition, it stops and boxes that neighborhood. You
are prompted for a result state. Once you’ve entered it, the evolution
function continues and the new transition rule is appended to a new-
transitions file in the current directory.
In the June 1995 Scientific American, the article "The Arithmetic of
Mutual" Help" (by Martin A. Nowak, Robert M. May and Karl Sigmund)
describes an interesting class of cellular automata that model iterated
Prisoner’s Dilemma situations. These games can illustrate stable and
winning cooperate/defect strategies for situations in which each agent
repeatedly interacts with near neighbors. In the same issue, Alun L.
Lloyd’s "Mathematical Games" column goes into more detail about these
These are two-state automata. In Alun’s implementation one state
always cooperates, one always defects (higher states could model Tit-
for-Tat, Generous Tit-for-Tat, or Pavlov). There is a payoff matrix of
the following form:
|Payoff | Cooperate Defect |
|Cooperate | 1 a |
|Defect | b 0 |
To make the game interesting, b must be greater than 1. (Lloyd’s simu‐
lation only considers the case a = 0.) On each round, each cell first
plays the game with each of its neighbors in turn. Then, each cell
looks at the payoffs of its neighbors (and its own payoff) and switches
to the strategy with the highest payoff).
To set up such a game, use the ‘R’ command in the following form:
For example, to set up Lloyd’s simulation, do ‘R1.85$0’. In these sim‐
ulations, use the following mapping between states and strategies:
Live, always cooperates.
Live, always defects.
Interesting b values are in the range (1, 2]; Lloyd likes 1.85. Dif‐
ferent values produce wide ranges of different behaviors, including
stable end states, statistical equilibria and cycles with large swings.
Initial clustering of cooperators is also important; a single coopera‐
tor will always be snuffed by surrounding defectors, but a block of 4
or more may be able to defend themselves and earn a high enough rela‐
tive payoff to convert neighbors.
Lloyd included illustrations of a 1.85 game starting with one defector
in a sea of cooperators. The resulting patterns look like Persian car‐
pets or Koch snowflake curves.
will enable single-step debugging of pattern evolution (so you can
watch the transition function being applied). Diagnostic messages will
be sent to stderr.
Transition rules entered interactively are appended (commented with
user ID and timestamp) to the file new.transitions in the current
directory. This file can later be selectively merged with your origi‐
nal ruleset using a text editor.
The program has a compiled-in default for its global pattern directory,
LIFEDIR, which is normally /usr/local/lib/xlife.
If the the variable LIFEPATH is set to a colon-separated list of direc‐
tories, these directories (and their first-level subdirectories) will
be searched for pattern-file names and rulesets. The default list
includes "." and LIFEDIR; that is, pattern files are searched for, by
default, below the current directory and below the global pattern
The recommended way to organize your pattern directories is to have one
subdirectory per automaton. The distribution provides the following:
contains an extensive library of interesting Life patterns.
contains transition rules and components for the universal computer-
constructor described in E.F Codd’s Cellular Automata Academic Press
1968 (ACM Monograph #3).
contains transition rules and a test pattern for the Wireworld automa‐
ton as described in the January 1990 issue of Scientific American (Com‐
puter Recreations, p. 146).
contains patterns for miscellaneous other automata.
These will be copied under LIFEDIR by a normal installation.
Here are some 2-state rules to experiment with:
23/3 the default, of course; Conway’s "Life" rules.
1234/3 patterns "crystallize"
12345/45 patterns become contained
12345/4 same as above, but settles VERY quickly
5/12 floor tile patterns... Variations of this tend to
be interesting as well.
/2 most patterns expand indefinitely, some interesting
ones. Fast gliders.
Old files in #P format may not have same y coordinate when read by the
new release. For best results, use "lifeconv -p name ..." on old
Expose events don’t restore the tentative pattern.
Algorithm, implementation and file format enhancements: Jon
Original X code: Chuck Silvers <firstname.lastname@example.org>
Enhancements to #I format and user interface: Paul Callahan
Auto-sizing, load format enhancements, 8-state support, all of the non-
Life automata, still-life detection, boxing: Eric S. Raymond