Xlife(6)Xlife(6)NAME
Xlife - Conway's Game of Life and other cellular automata, for X
SYNTAXxlife [-display disp] [-geometry string] [-l pattern-lib] [patternfile]
lifeconv -ACDIMPRSpv? [-l pattern-lib] [-g n] file
DESCRIPTION
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). Exactly the universe
is a big torus.
If an initial pattern is specified, it will be loaded on startup,
before Xlife accepts commands.
The -geometry option sets the Xlife window size and position as per
usual for X applications. The -display option sets the display to use;
overrides the DISPLAY environment variable. The -l option allows you
to specify a pattern list library-file for name matching (default is
`named-patterns').
lifeconv is a format-conversion utility that translates between several
different file formats for saving patterns. It takes a pattern file
argument and writes the conversion to standard output. Conversion
options are described in the LOAD FILE FORMAT section below. The -g
option permits you to evolve a loaded pattern for a given number of
generations before saving. The -l option is the same as above. The -?
option shows the usage summary. The -v option outputs version informa‐
tion and exits.
A utility table2r may convert table-format file with rules to r-format.
This utility is written in awk.
COMMANDS
Tab Change state 1 cells of tentative pattern to active state.
It is useful for the creation of multirules pattern.
! Place random cells on the area of the universe on the screen.
# Change tentative-display mode. By default the tentative-pat‐
tern cells are displayed in normal state colors but with a
bounding box. In the alternate (`wireframe') mode, tenta‐
tive-pattern cells are displayed as open rectangles in the
load-box color, but with no bounding box. Wireframe mode is
useful when you are trying to match a loadscript to a tem‐
plate active pattern. It is also useful to compare two pat‐
terns.
$ Toggle running display of changed-cell count in per-genera‐
tion status line. This count makes evolution slightly
slower.
% Set a percentage density for a randomly filled area. Default
is 90%.
( [ { Set a marker at current mouse position. There are three
markers, one for each of these characters.
) ] } Go to a marker (make it the current mouse position). The
marker jumped to by each closing bracket is that set by the
corresponding open-bracket command.
*,= Toggle showing of speed in the number of generations per sec‐
ond.
+,= Zoom the view in, magnifying the area around the mouse cur‐
sor. At zoom scale N, cells are two to the power N pixels
wide; the default cell size is scale 4, 16 pixels on a side.
Scale range is -10 to 6; at scales -1, -2 and -3 a single
pixel represents the logical or of a square sample of 4, 16,
and 64 pixels respectively. The same effect has the movement
of mouse wheel up.
< Slow down evolution; increase delay by 10 msec.
> Speed up evolution; decrease delay by 10 msec.
- Zoom the view out. The same effect has the movement of mouse
wheel down.
. Center the universe view on the cursor (also Button 3 in nor‐
mal mode).
/ Show quantity of cells of different kinds (colors).
0 Center the median position of the live boxes.
1,End Move your view of the universe diagonally down and left.
2,Down Move your view of the universe down.
3,PageDown
Move your view of the universe diagonally down and right.
4,Left Move your view of the universe left.
5 Center the universe on the screen (based on average position
of the cells).
6,Right Move your view of the universe right.
7,Home Move your view of the universe diagonally up and left.
8,Up Move your view of the universe up.
9,PageUp Move your view of the universe diagonally up and right.
? Help for xlife. This help may be used as a menu.
@ Toggle 2-state automata history. The history provided by
addition of 5 new states: the new cell state 2 means that
this cell is dead but was alive earlier, the new states 3 and
4 mean marked ON and OFF respectively (they may be changed to
each other so they will always remain marked), the new state
5 means `start ON' (becomes normal marked OFF cell, the state
3, when it dies), the new state 6 means `boundary OFF' (can
never turn ON). The history may be also activated by addi‐
tion of `+' suffix to the string determinating rules.
A Add comments.
B Benchmark. Enter number of generations and get time. This
is also the fastest mode of the evolution.
C Clear the universe and discard current load script. If there
is a boxed pattern, clear that instead.
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).
E Rotate pseudocolor display modes for 2-state automaton. In
display mode 0 (the default) all live cells are displayed
normally. In display mode 1, new cells are shown in state 2
color. In display mode 2, new cells are shown in state 2
color and dying ones in state 3 color. In display mode 3,
dying cells are shown in state 3 color. In display mode 3,
only cells changed from the previous generation are shown
(whether alive or dead). Has no effect on N-state automata
or a tentative pattern. It has also no effect when scale is
below 8:1.
F Load n-state rules from a given file (see the N-STATE SUPPORT
section below). The file with rules may be given by absolute
path or just by name of the rules. In the latter case all
subdirectories of the default directories will be searched.
G Generate tentative loaded or active pattern for one or more
steps.
H Toggle history record mode. It is fast mode for any type of
automaton. Use `h', These colors maybe changed by `X' com‐
mand.
I Force tentative pattern to be incorporated into main pattern
(automatic with g, h, o, l, and W commands).
J Jump to (x,y) location - make it the current mouse position.
K Discard comments associates with current pattern. It also
clears #K line.
L Immediately reload, at the cursor, a copy of the last pat‐
tern loaded.
M Toggle display of a grid mesh overlaying the board.
N Change the file's internal name.
O Set current mouse position to be the origin of displayed
coordinates.
P Toggle the oscillation check mode. The `g' command evolution
stops whenever it detects an oscilator in this mode. This
command compares the starting pattern with the next patterns.
So it just checks whether a given pattern is an oscillator.
Q Quit
R Change the (2-state) rules in "stays alive on"/"born on" or
B0..8/S0..8 format. The standard rules are 23/3 (alive on
two or three neighbors, birth on three neighbors for an empty
cell) or B3/S23 or S23/B3. Its possible to use third compo‐
nent which must be number between 3 and 256. This number
sets age limit for the cells. So /2/3 establishes Brian's
Brain rules and 345/2/4 - Star Wars'. Alternatively, enable
a payoff matrix with the syntax <float>$<float> as described
in the PRISONER'S DILEMMA section. It is possible to use
named rules. The words "life", "seeds", "wireworld", "life‐
history", "life+", and "brian" (for "brian's brain") are rec‐
ognized.
S Save the universe to a file adding extension `.l', along with
any comments created via `A'. If there is currently a boxed
pattern, only the boxed pattern is saved. It is possible to
select a format for the saved pattern. See section MAIN LOAD
FILE FORMAT for the details.
T Set up the topology. It is possible to select the rectangu‐
lar area with connected edges (anchor ring, tore) or the rec‐
tangular plain. The letter `Q' (quasiplain) means very big
torus - this is the default mode. The letter `T' means lim‐
ited torus and the letter `P' means limited plain. You
should enter rectangle's width and height in the latter
cases. The sizes of the rectangle will be rounded up to the
multiples of 8. The size 0 means pseudoinfinity. The
bounded area center is the initial origin of coordinates.
For example, `T16,0', `T8x8', `P0,64', `T4096,4096',
`T8X512', `P400*400', `Q' may be used to set up the topology.
It is possible to use previous setup. If `T512,512' topology
is used then the set `64x' will set `T64*512'. You may set
bordered plain with any form for the 2-state automata in the
history mode - you should draw borders with 6th color.
U Undo load of tentative pattern.
V View comments.
W Write (and flush from memory) script of loaded patterns into
a file with `.l' extension. When loaded, this script corre‐
sponds the earliest ancestor of current pattern that can be
reconstructed from loaded patterns (it does not include
changes made with mouse: flips, rotates, and moves).
X Load palette from a file with extension .colors (default).
This file consists of lines of text. Any blank lines or
lines starting with `#' are ignored. The specification of
the RGB colors for one or more states should use the lines
like these:
color=1 0 0 255 #0000ff
color=2 255 0 0
color=4 255 255 0 cyan
color=5 255 0 255
Y Yank out active pattern. If tentative one exists then move
tentative pattern to the universe.
Z Restore default palette.
^ Set seed for random number generator.
a Add n-state transition - 6 digits (one old state, one for
each orthogonal neighborhood cell, and one new state) or
filled S(N*C)R form. The new rule will be logged to the file
new.transitions (this requires write permission for the
directory with last loaded pattern).
b Display the xmin/xmax and ymin/ymax values of the live cells.
c Toggle showing of cell count. Active cell count makes evolu‐
tion a bit slower.
d Duplicate tentative pattern. Allows to create multiple
copies of the same object interactively. Just press `d' and
then mouse button 1.
f Set evolution speed for `g' to high (no delay between evolu‐
tions), the default.
g Toggle running the game. Evolve/Stop. Incorporate any ten‐
tative pattern. Then step through generations until some‐
thing exceptional happens, like still life or stability or a
key pressed or possible oscillation detection (the last only
if a `P' period check is set) or like an `i' timer running
out.
h (Hide) stop displaying after each generation, does not
iconify. This mode maybe up to several times faster than
established by g-command. However j-command with proper step
gives faster speed and more comfortable output.
i Set up timer. Set the maximum number of generations to per‐
form for following `g' or other evolution commands. A zero
value (the default) is interpreted as "never stop". This
command is very similar to 'G'.
j Set jump length (step) for the command `g'. The value 0 or 1
means no jump. The greater value means faster speed.
k Pick up color from the pattern's cell.
l Load (actually add) pattern to the universe from a file with
extension `.l' (default), `.life', `.rle', `.mcl', `.lif', or
`.cells'. This lets you overlay multiple saved states to
make for some interesting effects. Loaded pattern is
(default) initially considered tentative, and may be manipu‐
lated in various ways before incorporating it into main pat‐
tern. (To indicate this, it's surrounded by a bounding box.)
Clear the universe if you want to start from scratch. It is
possible either to select pattern at the widget list directly
or to enter pattern name - this will start the search for the
requested pattern at current and library directories. There
are two modes to load patterns. The first mode is direct.
It directly place pattern to the active pattern space.
Directly loaded pattern isn't added to the save script. The
second mode is tentative. It allows pattern manipulations
before its addition to the pattern space.
m Set evolution speed for `g' to medium (250 msec delay).
n Goto next object. This command allows to find far ships,
etc.
o Incorporate any tentative pattern, then forward one genera‐
tion.
p Toggle running display of mouse position. Position is only
for reference during a session, and does not effect coordi‐
nates of saved points.
r Redraw the screen.
s Set evolution speed for `g' to slow speed (500 msec delay).
t Test n-state transition. Enter 5 digits (start state and 4
neighbors states), get result state.
u Undo manipulations of the tentative pattern, but not the load
(tentative pattern is restored to the original position and
indentation).
v View internal variable values and other information.
x Change pivot position of the tentative points to the current
position of the mouse.
COMMANDS IN SHIFT MODE
PageUp, PageDown, Home, End, 1, 2, 3, 4, 6, 7, 8, 9 and cursor keys
move the universe faster.
COMMANDS FOR WIDGET
PageUp, PageDown, Home, and End keys scroll the list. Esc key makes
exit from the widget. Shift-PageUp key sets upper directory. Left and
Right cursor keys or Tab move the active position to the previous/next
widget item. Up and Down cursor keys move the active position within
the list. Printable symbols maybe used to type filename. Return key
is used to activate the widget item. Backspace and Delete keys remove
last inputted character.
MOUSE WHEEL
controls vertical scrolling of the universel. It also scrolls the list
with the widget.
BUTTON BINDINGS IN NORMAL MODE
1 Activate a cell at the cursor, giving it the currently
selected state. In a 2-state automaton cells are always
activated with state 1. In an N-state automaton, you pick
your current color as described in N-STATE SUPPORT below.
2 Delete a cell at the cursor (force it to state 0). To clear
a region select it by mouse and press C.
3 Erase any previous selection box. If you drag the cursor
with button 3 held down, then release it, the rectangle
between the press and release points is boxed and made tenta‐
tive (as though it had just been loaded and not yet incorpo‐
rated). The tentative pattern can then be moved, flipped,
and rotated before re-incorporating it. If you've just
clicked at a tile then this tile becomes the center of the
screen.
BUTTON BINDINGS WITH TENTATIVE PATTERN LOADED
1 Move pattern to current position.
2 Flip pattern about its x-axis.
3 Rotate pattern clockwise about its origin.
BUTTON BINDINGS WITH STATE WINDOW
1 Select state.
2 Set color for the state.
WIDGET OPTIONS
Load pattern and Load pattern part modes
The radio buttons choose direct or tentative mode. The direct mode
sets to load pattern directly into the active space. This removes pre‐
vious pattern. The tentative mode (default) sets to load pattern into
tentative space. This allows to tranform a pattern before the addition
to the active pattern.
Save pattern mode
The radio buttons allow to specify one of A D I M P R S. For details
on the A D I M P R formats, see the LOAD FILE FORMAT section below; `S'
format is a sequence of P blocks, one for each blob in the picture,
with appropriate offsets for each.
Save script mode
Two radio buttons are for collected or plain format. The plain format
is just a list of inclusions. The collected one resolves all inclu‐
sions in the saved file. See the PATTERN INCLUSION section below for
more details.
MAIN LOAD FILE FORMAT
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 as hidden comments and ignored.
Some format directives may use the offsets which are useful with direct
load mode and with I-format. These offsets are ignored in the tenta‐
tive load mode.
Each image section is interpreted according to the format letter fol‐
lowing its section line #. The format letters are:
A - Absolute
Each following line is interpreted as an absolute (x,y) coordinate pair
for a cell to be put in state 1 (default). This format is deprecated
and should not be used for new patterns. However it is default - it is
used in absence of any format directive. The -A option of lifeconv
emits it.
B name 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 (D, I, M, P, ...) are normally drawn with 0,0
at the center of the universe. 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 by
those offsets.
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.
C - Comment
Lines beginning with "C" are comments that the user may have automati‐
cally written to the save file, and which may be viewed from within
Xlife.
D [xoff [yoff]] - Relative to the previous coordinate pair
Each following line is interpreted as a (x,y) coordinate pair relative
to the previous one, for a non-empty cell. The first is relative to
the default (0,0) or if they are given to (xoff, yoff). The -D option
of lifeconv emits it.
I [xoff [yoff [rotate [flip [delay]]]]] - include
A #I line should have whitespace-separated fields after the #I consist‐
ing of a pattern name and five optional integer parameters (x, y off‐
sets, 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 off‐
sets, if present, displace the load point of the pattern relative to
the center of the pattern space. The include facility is useful for
assembling `sampler' collections of interesting patterns, as well as
maintaining structured representations of complex patterns. See also
PATTERN INCLUSION and STRUCTURED PATTERN EDITING sections.
K outcome string - special comment
This string should define the results of the evolution of the pattern.
M [xsize, ysize] [xoff [yoff]] - run-length encoding with
optional sizes and offsets. The sizes are ignored by the current ver‐
sion of xlife. Only the characters b, $, !, the letters from A to X
and from o to y, and the digits 0 until 9 should appear except
whitechars which are ignored. The data is ordered a row at a time from
top to bottom, and each row is ordered left to right. A $ represents
the end of each row and an optional ! represents the end of the pat‐
tern. For two-state rules, a b represents an off cell, and an o repre‐
sents an on cell. For rules with more than two states, a . represents
a zero state; states 1..24 are represented by A..X; states 25..48 by
pA..pX; states 49..72 by qA..qX; 241..255 by yA..yO. The pattern
reader is flexible and will permit b and . interchangeably and o and A
interchangeably. Any of state character can be led ahead by a positive
integer, which then is interpretated as the repettion of that charac‐
ter. Any illegal character will be interpretated as whitechar and
ignored. The -M option of lifeconv emits this format.
N - Name
This line contains the internal name of the pattern (which may differ
from the the 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.
#0 jb7m "Jon C. R. Bennett"@sushi.andrew.cmu.edu Fri Jan 12 18:25:54
1990
A 0 (zero) may be used instead of O (xlife generates it during S com‐
mand execution).
Note: This timestamp line has changed format at least three times since
Xlife 1.0. It is probably not wise to try and parse these unless you
see known format version ID (on the first line of the file).
P [xoff [yoff]] - Picture with optional offset coordinate pair.
Each line in the section is interpreted as a scan line of a relative
image. Each * character turns the corresponding cell on. All other
characters leave the corresponding cell off. For multi-state automata,
characters may be letters, @, ~, and digits, with '*' corresponding to
1. The -P option of lifeconv emits this format.
R [xoff [yoff]] - Relative with optional offsets
Each following line is interpreted as a (x,y) coordinate pair relative
to the center of the pattern space. These relative image sections are
normally drawn with 0,0 on the center of the pattern space. 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.
The -R option of lifeconv emits this format.
T survivedigits/borndigits - Set new transition rules
This line defines a new set of 2-state rules. survivedigits and
borndigits are each a sublist of digits out of the range 0 up to 8,
counting the number of neighbours when the central cell in the neigh‐
bourhood survives/is born to state ON. For example the default and
classical rules for Conway's Game of Life are: #T 23/3. You may use
also named rules like with `R' command: `wireworld', `seeds', `life',
`lifehistory' or `life+', `brian'. It is possible to add topology
after `:'. For example, `life+:T200,200' means Life with History rules
at the torus grid. You may also use rules definition in
`B0...8/S0...8' notation, where the digits after B specify the counts
of live neighbors necessary for a cell to be born in the next genera‐
tion, and the digits after S specify the counts of live neighbors nec‐
essary for a cell to survive to the next generation.
U filename - Use
Format is #U followed by a filename. 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. It is possible to add topology after
`:' like with `#T' directive.
X filename - palette for the piXels
It loads a palette-set file with given name.
More section formats may be added in the future.
PATTERN INCLUSION
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 nega‐
tive) 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.)
The -I and -C options of lifeconv may be useful for collecting inclu‐
sions from multiple files into a single self-contained file.
When you save a pattern in `I' mode, the program automatically does a
pattern analysis to detect `blobs' (completely connected regions of
live cells). Repeated blobs are recognized, even if they are rotated
or reflected. If there is only one blob, the save output is identical
to #P format. Otherwise the output is a list of blobs followed by #I
lines that will recreate the saved pattern. This has two advantages:
duplicate blobs are only written once, and common pattern elements are
recognized and named (so the save file is also a census).
The elements container for this recognition is the file "named-pat‐
terns" (or file selected by -l option at startup). It specifies the
name of a file containing the names of patterns to be recognized and
named when doing I-format (structured) saves. A leading slash distin‐
guishes an absolute pathname; otherwise the relative name is searched
for beneath the LIFEPATH or default directories (as for a pattern
file). Each line of this file contains up to three fields; a pattern
name, a pattern file or file:block reference (as for the `l' command)
and a cycle length. When the cycle length is 0, only one recognition
template is generated from each entry; when it is nonzero, one is gen‐
erated for each step in the cycle (with steps after 0 distinguished by
a number suffix on the name). Thus, for example, an entry that reads
glider ss:glider 2
Will generate two recognition templates, one named `glider' and another
named `glider2'. The cycle length is optional and defaults to 0; the
second field is optional and defaults to the value of the first. Com‐
ments (led by #) and blank lines are ignored. This name container is
only activated for the life rules.
The file "named-patterns" default content referes to the file "match.l"
which contains named patterns list in the #B/#E-format.
N-STATE SUPPORT
Xlife includes support for automata with up to 64 states using the
(von-Neumann-style) 4-cell rotationally symmetric neighborhood
(rotate4, default), rotate4reflect or absence of symmetry; to invoke
it, load a rule-set file using the `F' command. It is also possible to
use the (Moore-style) 8-cell rotationally symmetric neighborhood for
the special cases: WireWorld and 3-components (generations) rules with
up to 256 states. The Moore style maybe also used in the general case
but only up to 11 states. These two cases are established by `#T' form
in a pattern file or by direct manual input after the `R' command (use
recognized words or a form like 345/2/4). Many interesting automata
including the Wireworld-4 construct and the UCC described in E. F.
Codd's 1968 ACM monograph can be implemented by specifying appropriate
transition functions.
Don't rotate or flip pattern with non-symmetrical rules!
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 or
letters arranged as
<old-state><neighbor><neighbor><neighbor><neighbor><new-state>
For <old-state> or <neighbor> you may also specify a state set; digits
or letters enclosed in square brackets. This wild-cards the transition
in the obvious way. You should use letters instead numbers for states
above 9, so use A instead 10, B instead 11, and so on. The letter `a'
means 36, `b' - 37, etc. The sign `@' means 62, `~' - 63. 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‐
rent ruleset.
The directive
states <maxstates>
tells the code what the automaton's count of cell states is.
Rule tables usually don't specify every possible set of inputs. For
those not listed, the central cell remains unchanged if `passive' dec‐
laration is not used.
The presence of `passive' declaration will require manual input of
missed transition. So if, while evolving a pattern, the code finds a
cell and neighborhood in a state for which no transition has been spec‐
ified, the program queries the user for a new state, and the tuple
implied is added to the database. A line of the form
passive <maxstate>
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. The form
`passive 0' is a way to say to use manual input for every missed tran‐
sition.
The directive
nosymmetries
sets absence of symmetry in rules. It may be used with Langton Ants,
Perrier loops, etc.
The directive
rotate4reflect
sets this type of symmetry. It may be used with Bank I, II, III, IV,
etc.
The directive
Moore
sets this neighborhood. It may be used with Bank III, etc. The
default symmetry is `rotate8'. This directive should precede state or
symmetry declaration.
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-4 rules file. This doesn't
works with `nosymmetries' or with `Moore'.
Rules are checked in the order given in the file - the first rule that
matches is applied. If you want (`passive' should be set in this
case), you can write rules in the form of general cases and exceptions,
as long as the exceptions appear first in the 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. This feature can't be acti‐
vated because all transitions are defined.
PRISONER'S DILEMMA MODELS
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:
┌──────────┬────────────────────┐
│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:
R<b>$<a>
You may also use #T form in the pattern file.
For example, to set up Lloyd's simulation, do `R1.85$0'. In these sim‐
ulations, use the following mapping between states and strategies:
0
Quiescent.
1
Live, always cooperates.
2
Live, always defects.
3
A transition, from cooperator to defector. It behaves like defector.
4
A transition, from defector to cooperator. It behaves like cooperator.
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.
OTHER FEATURES OF RULE FILES AND EDITING
The directive
debug NUMBER
is ignored.
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.
STRUCTURED PATTERN EDITING
Almost all large Life patterns that exhibit well-defined behavior (such
as the breeder) are in fact composed of smaller patterns that combine
in a predictable way. Storing such patterns as assemblies of subpat‐
terns can greatly aid future experimentation as well as synthesis of
still more complex patterns. Here we'll explain the structured-editing
features, and give several examples of their use.
Overview of structured editing
Structured editing should cut down on the number of Life patterns
stored as atomic images (i.e. raw bitmaps or point sets). Once a
glider gun, for example, has been defined, there should be no need to
duplicate the pattern. It should instead be possible to refer to it by
name, as a known mechanism with well-established properties. In fact,
the glider gun itself exhibits some structure, as it is composed of two
period 30 shuttles that interact to produce gliders. Ultimately, the
"interesting" part of the period 30 shuttle does not seem to have any
structure, and hence must be represented a picture, such as the follow‐
ing:
..*...
.*.*..
*...**
*...**
*...**
.*.*..
..*...
Unfortunately, it is not enough to merely place such a pattern at the
correct coordinates. For example, we can rotate this pattern by multi‐
ples of 90 degrees without essentially changing its behavior. While
this particular pattern has mirror symmetry about its horizontal divid‐
ing line, other patterns may not, so we may additionally wish to take
the mirror image of a pattern. It would be undesirable to maintain
eight separate bitmaps for what is really the same pattern, so we would
like a facility to perform basic geometric transformations on patterns
to be included in more complex ones.
A more subtle issue is that of timing. When placed between appropriate
stabilizing objects (such as eaters or blocks) the above pattern will
oscillate with a period of 30. Hence, when defining a complex pattern,
we may need to insist (in addition to any geometric transformations)
that it be placed within the larger pattern at a particular phase in
its cycle.
By controlling position, rotation, flip, and phase shift, we may com‐
bine patterns in any desired manner. The #I extensions to Xlife makes
this possible, and the structured editing features make it (relatively)
convenient.
Ideally, the new editing features will make it possible to use the #I
format without ever looking at the description file. The advanced Life
experimenter may, however, wish to modify #I lines with a text editor
in order to achieve very specific effects (still more advanced CAD
tools would eliminate this need).
To attempt the following examples, you should be running Xlife. You
must have a copy of the file "ex.l", supplied with the release, in
either the directory in which you start up Xlife, or in the pattern
directory.
Before trying any of the examples, type `C' to clear the workspace, if
it is not already clear.
Experimenting with gun collisions.
Type `l' to load in a pattern. Backspace over the default directory,
if there is one (probably the pattern library) and type "ex:gun". This
will load the pattern "gun" from the file "ex.l" in either the pattern
library or current directory. The pattern consists of a glider gun
before it has produced any gliders.
Get a feel for the movement, flip, and rotation operations performed
with the mouse buttons. All operations are performed with respect to
the origin of the pattern, which is indicated by a single dot at the
smallest scales and becomes an X shape at the larger scales (zoom in on
it to see this).
In order to place patterns such as glider guns, it is especially impor‐
tant to know the direction of the outgoing glider stream. You may pre‐
view this by generating the loaded pattern with the `G' command (*not*
the `g' command). Initially, you will want to generate enough steps to
see the stream, so type 100 when prompted for the number of steps. It
is better to use `I' command before `G' with first pattern. The nega‐
tive phase shifts otherwise may be produced by `W' command. The nega‐
tive shifts should be edited manually.
Note that the mouse buttons continue to perform transformations on the
generated pattern. Place the pattern as desired. It will be incorpo‐
rated into the main universe when any of the commands g, h, o, l, or W
are typed. To incorporate it without doing anything else, use `I'.
Now, load another glider gun in the same manner. Place the two guns in
such a way that their outgoing gliders collide. Not all collisions are
well behaved, and you may wish to produce a specific collision, such as
a clean annihilation of gliders. The references mentioned at the top,
and some of the patterns supplied with Xlife, are a good source of
interesting collisions. Use `G' on the second glider gun to control
the phase difference between the colliding gliders.
Type `g' to let the pattern go and see what happens. If the collision
was chosen randomly, there is a good chance that it will merely break
down into chaos. Some collisions, however, produce interesting
effects.
Save your gun collision into a file using the `W' command. Now type
`C' and use `l' to load it back in. Note that the result is not what
you would expect from saving the current pattern. That is, even if the
pattern did break down into chaos, the pattern written by `W' corre‐
sponds to the collision as you set it up. If you type `g' then you
should witness the same sequence of events as before.
The file written by `W' is not a raw pattern image, but rather a "load
script." That is, it gives Xlife enough information to reconstruct
your placement of loaded patterns. It does not contain any changes
made by drawing or erasing cells with the mouse, but such changes devi‐
ate from the philosophy of pattern structuring and should be avoided
except when drawing atomic patterns. (In any case, the `S' command is
provided for saving the whole image in an unstructured way.)
Setting up a glider mirror.
It is possible to reflect a stream of gliders as if by a mirror, using
a period 30 shuttle with eaters at the ends. The mirror will not work
unless the stream (from a period 30 gun) and the mirror are perfectly
positioned and in phase. In general, this may involve some simple yet
tedious calculation or else a still more tedious process of trial and
error. In the following, however, we will see how to use the editing
features to produce the desired effect reasonably simply.
Load in ex:gun, as before, and let it generate (with `G') until the
outgoing stream contains 20 or so gliders. This is the stream we will
be reflecting.
Now load in ex:mircollision. This pattern consists of a glider poised
to be reflected from a mirror. Use rotates, flips, and `G' (one step
at a time) until the the mirror glider is an exact copy of the glider
furthest from the gun. Use the mouse to move the loaded pattern so
that these two gliders occupy exactly the same five cells. It may help
to zoom in on the pattern.
Now, simply type `g' and let the pattern go. It you performed the
above steps correctly, you should see a stream of gliders bouncing off
the mirror. Add more mirrors, if desired, and save the result into a
file using `W'
Details of the structured save format
Skip the following if you are not interested in familiarizing yourself
with the details of the #I format.
Take a look at the file generated by `W' in the above. It consists of
a sequence of #I lines, the first containing ex:gun, and the others
containing ex:mircollision. The latter lines each have a delay value
as their final parameter, and these parameters will most likely be in
the hundreds, as this is the number of steps it takes to make the
stream of gliders used as a reference.
Note that the mirror is a period 30 oscillator, so we may replace all
of these numbers by their values mod 30 without affecting the crucial
phase difference between the mirror(s) and the gun. Do this, and look
at the pattern in Xlife. Note that it takes less time to load, and
that the loaded pattern does not contain a long stream of gliders.
Type `g' to verify that the mirrors still work (if not, make sure you
computed mod correctly).
The resulting pattern will contain spurious gliders. These are the
gliders that came with the pattern ex:mircollision. Fortunately,
ex:mircollision contains ex:mirror with no moves, flips,or rotations
applied. Hence, by replacing all instances of ex:mircollision by
ex:mirror in your file, you will obtain the same pattern as before, but
without the spurious gliders.
This illustrates the notion of including extra parts in a pattern for
reference and eliminating them in the final edit. Use of this tech‐
nique can substantially reduce the need for explicit calculation when
constructing complex patterns.
Constructing a Structured Pattern from a Template.
Having familiarized yourself with the use of load scripts, you may wish
to construct structured versions of old patterns you made in the previ‐
ous version of Xlife. This can be done in a bottom-up fashion by load‐
ing in the raw image and building up subpatterns using the initial
image as a reference. You first need to identify the the atomic sub‐
patterns in the old pattern. For example, in the mirror of the previ‐
ous example, the atomic patterns are two eaters and the period 30
oscillator (shown earlier in this document).
The template pattern should not be written into the load script, and
this may be prevented by using the `D' command after this pattern has
been incorporated into the universe. The effects of having the tem‐
plate written to the load script are non-fatal, and may be corrected
with a text editor. However, it is best to get in the habit of typing
`I' (include pattern),
The mirror in "ex.l" is already given in a structured way, but it will
suffice to illustrate the technique. To place the template, load
ex:mirror, and type and the oscillator (ex:oscil) and place each pat‐
tern over the corresponding part of the old image. Use `W' to write
the load script.
If the original mirror had been stored as a bitmap then you would have
transformed a seemingly arbitrary set of points into a structured pat‐
tern. Patterns defined in this way can later be combined into more
complex patterns, and at any level, the pattern can be seen to be a
logical combination of well-understood components rather than an amor‐
phous conglomeration of Life cells.
Using the `lifeconv' utility.
One seeming disadvantage of structuring patterns with the `W' command
is that a pattern that used to reside in a single file may now be
spread over several files. There may be too many to easily keep track
of them. For the user who wishes only to use #I as a means of collect‐
ing a structured pattern into a single file, however, the -I and -C
options of `lifeconv' utility are provided.
The lifeconv utility takes a pattern name as an argument (with the same
default directories as in the `l' command). It writes a file to stan‐
dard output that contains an equivalent version of the pattern in a
different format. Usage is:
lifeconv pattern [-ACDIMPRSp] >destination
where destination is any valid file name (a .l extension is recom‐
mended). The option controls the format in which the destination file
is written. These formats are identical to those described under the
`S' (save) command, except for C.
Either -C or -I will suffice to convert a pattern with inclusions into
a single-file pattern with all the inclusions resolved. The difference
between them is that -I does an automatic scene analysis of the file
after merging all inclusions into one big picture, while -C just
resolves the inclusions textually. The one advantage of the latter
method is that it preserves any pattern name and structure information
present in the input file: -I renames all the pattern fragments.
Try these options on any of the files written by `W' in examples 1, 2,
and 3.
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.
This utility may also be used for conversion from other formats (MCL,
LIF, ...) to native XLife format.
ENVIRONMENT
The program has a compiled-in default for its global pattern directory,
LIFEDIR (normally /usr/share/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
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.
life-like
contains a library of interesting similar to Life patterns (seeds, life
without death, highlife replicator, brian's brain, starwars, ...).
codd
contains transition rules and several demos.
devore
variation of the Codd self-replicating computer.
HPP
is the earliest lattice gas model.
perrier
this loop is a self-reproducing calculator.
wireworld
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).
wireworld-4
contains transition rules and test patterns for the Wireworld-4 automa‐
ta. Wireworld-4 is a variant of classical Wireworld at the von-Neu‐
mann-style rotationally symmetric neighborhood.
byl, chou-reggia
contain small n-state replicators.
langton
contains famous loop and ant(s).
evoloop, sexyloop, SDSR
contain evolutionary replicators.
pd
contains patterns for Lloyd's variant of Prisoner's Dilemma games.
These will be copied under LIFEDIR by a normal installation. The dis‐
tribution may contain additional directories with more patterns.
EXPLORATION
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.
1357/1357 replicators world...
/2 seeds - most patterns expand indefinitely, some
interesting ones. Fast gliders.
012345678/3 life without death. Ladders.
AUTHORS
Algorithm, implementation and file format enhancements:
Jon Bennett
Original X code:
Chuck Silvers
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
Many new commands, subpixel resolution, M format:
Achim Flammenkamp
A lot of fixes, improvements, and a save/load widget:
Vladimir Lidovski
SEE ALSOlifeconv(6), xlife(6).
Xlife(6)
