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 interactively 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 mouse cursor.

-

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 not iconify.

c

Toggle showing of cell counts

?

Help for xlife.

!

Place random cells on the area of the universe on the screen.

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 DILEMMA section.

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.

Q

Quit

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 displayed coordinates.

G

Generate tentative loaded pattern for one or more steps.

U

Undo load of tentative pattern.

I

Force tentative pattern to be incorporated into main pattern (automatic with g, h, o, l, and W commands).

W

Write (and flush from memory) script of loaded patterns into a file with '.' extension. When loaded, this script corresponds the earliest ancestor 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 tentative 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 tentative 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 sections separated by section lines beginning with '#'. Lines led by `##' are considered comments and ignored.

Each image section is interpreted according to the format letter following its section line #. The format letters are:

A -- Absolute. Each line is interpreted as an absolute (x,y) coordinate pair.

R -- Relative. Each line is interpreted as a relative (x,y) coordinate pair.

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 parameters (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 pattern 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 patterns 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 facility 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 18:25:54 1990

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

"<pattern>

is a pattern name (described below);

"<x>,<y>

are integers representing horizontal and vertical offsets; and

"<rotate>

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 "%").

"<flip>

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.

"<delay>

is an integer specifying the number of generations to perform before loading the pattern (negative values have same effect as 0).

Note that all of the transformations applied to an included pattern are taken relative to the pattern that includes it. Thus, loading an assemblage of included patterns works as one would expect.

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 appropriate 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 definition syntax. Each line contains either a directive or 6 digits arranged as

<old-state><neighbor><neighbor><neighbor><neighbor><new-state>

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 current ruleset.

The directive

states <maxstates>

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

passive <maxstate>

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 rules.

You can also specify rules depending on a neighbor count. A rule line of the form

S(N*C)R

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 simulations.

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:

center box tab(;); l | c c. Payoff;Cooperate;Defect _ Cooperate;1;a; Defect;b;0

To make the game interesting, b must be greater than 1. (Lloyd's simulation 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:

R<b>$<a>

For example, to set up Lloyd's simulation, do `R1.85$0'. In these simulations, use the following mapping between states and strategies:

0

Quiescent.

1

Live, always cooperates.

2

Live, always defects.

Interesting b values are in the range (1, 2]; Lloyd likes 1.85. Different 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 cooperator 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 relative 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 carpets or Koch snowflake curves.

The directive

debug 1

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 original 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 directories, 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 directory.

The recommended way to organize your pattern directories is to have one subdirectory per automaton. The distribution provides the following:

life

contains an extensive library of interesting Life patterns.

codd

contains transition rules and components for the universal computer-constructor described in E.F Codd's Cellular Automata Academic Press 1968 (ACM Monograph #3).

wireworld

contains transition rules and a test pattern for the Wireworld automaton as described in the January 1990 issue of Scientific American (Computer Recreations, p. 146).

misc

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 files.

Expose events don't restore the tentative pattern.

Algorithm, implementation and file format enhancements: Jon Bennett <jcrb@cs.cmu.edu>

Original X code: Chuck Silvers <cs4n@andrew.cmu.edu>

Enhancements to #I format and user interface: Paul Callahan <callahan@cs.jhu.edu>

Auto-sizing, load format enhancements, 8-state support, all of the non-Life automata, still-life detection, boxing: Eric S. Raymond <esr@snark.thyrsus.com>

lifesearch(1), lifeconv(1).