


Xlife(6)						 Xlife(6)


NAME
       Xlife - the Game of Life and other cellular automata for X

SYNTAX
       xlife [-display disp] [-geometry geom] [-bw width] [-?]
	     [-rv] [-grid n] [file]

       lifeconv [-ACDIMPRSv] [-p patternfile] [-g n] file

DESCRIPTION
       xlife  brings up an X program in which the user may experiment interac-
       tively with cellular automata.  In its default mode, the program	 helps
       the user experiment 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 cells on a side).

       The -geometry option sets the Xlife window size	and  position  as  per
       usual for X applications.

       If  an  initial	pattern	 is  specified,	 it will be loaded and started
       evolving on startup, before Xlife accepts commands.

       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 `-v' option enables verbose progress
       messages to stanard error.  The -p option allows you to specify a  pat-
       tern list file for name matching.


OPTIONS
       -display	      Set  the	display to use; overrides the DISPLAY environ-
		      ment variable.

       -geometry      Set xlife's window geometry as in the Xt toolkit option.
		      If either window size value is negative, it will be sub-
		      tracted from the value computed by the grabFraction, and
		      the result used as a size.

       -rv	      Reverse the Life board to black on white.	 Equivalent to
		      setting the reverseBoard resource to true.

       -bw	      Set the border width used for window-size	 calculations.
		      This is normally zero; you may want to set it under win-
		      dow managers that don't create frame windows themselves.
		      Overrides the borderWidth resource.

       -grid	      Set  the	grid  interval for the `L' command mesh; over-
		      rides the gridInterval resource. A  positive  value  for



								1





Xlife(6)						 Xlife(6)


		      this option turns the grid on by default; a negative one
		      does not, but sets the interval to its absolute value.

       -?	      Emit a usage message and quit.


COMMANDS
   Help and Bailing Out
       ?	 Help for Xlife.

       C	 If there is a tentative pattern, clear it.   Otherwise	 clear
		 the universe and reset the generation number to 0.

       Q	 Quit (leave Xlife).


   Motion and Viewport Control
       r	 Redraw the screen.

       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 average position of the live cells.

       0	 Center the median position of the live cells.

       J	 Jump  to (x,y) location (make it the current mouse position).

       .	 Center the universe view on the cursor.

       ( [ {	 Set a marker at current  mouse	 position.   There  are	 three
		 markers, one for esch of these characters.

       ) ] }	 Jump  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.

       O	 Set  current  mouse  position	to  be the origin of displayed
		 coordinates.


   Scale
       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 -3 to 7; at
       scales -1, -2 and -3 a single pixel represents  the  logical  or	 of  a
       square sample of 4, 16, and 64 pixels respectively.

       =,+	 Zoom  the  view in, magnifying the area around the mouse cur-
		 sor.



								2





Xlife(6)						 Xlife(6)


       -	 Zoom the view out.


   Editing in Normal Mode
       These are the normal button bindings.

       Button-1	 Activate a cell, 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.

       Button-2	 If  a	pattern is selected, Button 2 merges the contents back
		 into the active pattern. If you drag the cursor with button 2
		 held  down,  then release it, the rectangle between the press
		 and release points is selected.  Any points in	 it  are  made
		 tentative  (as though the region had just been loaded and not
		 yet incorporated).

       Button-3	 Delete a cell at the cursor (force it to state 0).


   Manipulating tentative patterns
       These are the button bindings when there is a tentative pattern.	  This
       may happen as the result of a load command or because you have selected
       a nonempty part of the on-screen pattern.  When the  tentative  pattern
       is  incorporated into the active pattern, the button bindings revert to
       normal.

       Button-1	 Translate pattern pivot to current position.

       Button-2	 Flip pattern about its x-axis.

       Button-3	 Rotate pattern clockwise about its origin.

       Sometimes it may be useful to select an empty region, for use with  `C'
       or `%' or similar commands.


   Evolution
       n	 Set  the maximum number of generations to perform for follow-
		 ing `g' commands.  A zero value (the default) is  interpreted
		 as "never stop".

       g	 Evolve.    Incorporate	 any  tentative	 pattern.   Then  step
		 through generations until something exceptional happens, like
		 an `n' timer running out or still life or stability or possi-
		 ble oscillation detection (the last only if a `p'  period  is
		 set).

       o	 Incorporate any tentative pattern, then step forward one gen-
		 eration.

       f	 Set evolution speed for `g' to high (no delay between	evolu-
		 tions), the default.



								3





Xlife(6)						 Xlife(6)


       m	 Set evolution speed for `g' to medium (250 msec delay).

       s	 Set evolution speed for `g' to slow speed (500 msec delay).

       <	 Slow down evolution; increase delay  by 50 msec.

       >	 Speed up evolution; decrease delay by 50 msec.


   Reports and Decorations
       p	 Set  an  oscillation  check  period.  You will be prompted to
		 enter a number.  Thereafter, until you set the	 check	period
		 to zero with another `p' command, `g' command evolution stops
		 whenever it detects a cycle of the  required  period  in  the
		 population counts.

       M	 Toggle display of a grid mesh overlaying the board.

       B	 Display the xmin/xmax and ymin/ymax values of the live cells.

       c	 Toggle showing of box counts in per-generation status line.

       &	 Toggle running display of mouse  position  in	per-generation
		 status line.

       $	 Toggle	 running  display of changed-cell count in per-genera-
		 tion status line.

       h	 Hide evolution.  Incorporate  any  tentative  pattern.	  Stop
		 displaying the board state after each generation.

       *	 Toggle	 pseudocolor  mode.  When this is on and the automaton
		 is 2-state, newborn cells are shown  in  state	 2  color  and
		 dying	ones  in  state	 3  color.   Has  no effect on N-state
		 automata.

       ~	 Change display mode (the new mode is displayed).  In  display
		 mode  0  (the default) all live cells are displayed normally.
		 In display mode 1, only cells changed from the previous  gen-
		 eration are shown (whether alive or dead).  Your display mode
		 is reset to zero by the `l' command or by selecting a	tenta-
		 tive battern.

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


   Making Soup
       %	 Place	random cells on the area of the universe on the screen



								4





Xlife(6)						 Xlife(6)


		 (or in the select box if there is one).  You will be prompted
		 for a percentage density.

       ^	 Set seed for random number generator.


   Unstructured Pattern Saving
       These commands operate on the current pattern (the tentative pattern if
       there is one, otherwise the active pattern).

       S	 Save the current pattern to a file adding extension .l, along
		 with  any  comments created via 'A'.  Clear the internal com-
		 ment area.

       i	 Set the save format for the S	command.   Normally  the  save
		 command  tries to use `I' format.  The command `i' allows you
		 to specify one of A D I M P R S; simply typing Enter restores
		 the  default  mode.   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.

       N	 Change the internal name associated with the current pattern.


   Load-script commands
       As  you	perform	 pattern-load  (`l'),  tentative-pattern movements and
       rotations with the mouse, and  tentative-pattern-evolution  ('G')  com-
       mands,  the  program  journals these changes.  They are appended onto a
       `load script' whenever you do an incorporate `I'.   (This  load	script
       does not include cell-state changes made manually with the mouse.)

       The  load  script  remains available even after you have run `g' on the
       resulting pattern, so you can save it or revert to it  if  the  results
       are interesting.

       l	 Load a tentative pattern from a file with extension .l.  This
		 lets you overlay multiple  saved  states  to  make  for  some
		 interesting  effects.	 The loaded pattern may be manipulated
		 in various ways before incorporating it  into	main  pattern.
		 (To indicate this, it's drawn in a special way, either with a
		 bounding box or  as  open  rather  than  filled  rectangles.)
		 Clear	the  universe  if  you	want  to  start	 from scratch.
		 Attempting to `load' a directory gives you a listing  of  the
		 directory.

       L	 Immediately reload, at the cursor, a copy of the last pattern
		 loaded.

       G	 Evolve tentative loaded pattern for one or  more  steps.  (If
		 there is no tentative pattern, evolve the active pattern.)

       U	 Undo load of tentative pattern.




								5





Xlife(6)						 Xlife(6)


       u	 Undo manipulations of the tentative pattern, but not the load
		 (tentative pattern is restored to the original	 position  and
		 indentation).

       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 `.l' extension. The origin of the written pattern
		 will be the mouse position when the internal comment area.

       D	 Discard the current load script, including any tentative pat-
		 tern,	but  leave  the	 cell population intact.  (Helpful for
		 using an old pattern  as  a  template	to  construct  a  load
		 script).


   Pattern comments
       There is a comment buffer area within Xlife that you can use to associ-
       ate comments with the current pattern (active or tentative).  When  you
       do  an `S' or `W' these comments will be written to the output file and
       the buffer area cleared.	 Thus, you can set up a	 pattern,  evolve  it,
       note  interesting behavior, evolve it more, add more comments, and save
       the construction and comments.

       A	 Add comments to the current pattern.

       K	 Discard comments associates with current pattern.

       V	 View comments associated with the current pattern.


   Rules Editing
       R	 Change the (2-state) rules in "stays alive on"/"born on" for-
		 mat.  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  sec-
		 tion.

       F	 Load n-state rules from a given file (see the N-STATE SUPPORT
		 section below).  A `.r' extension is supplied to the filename
		 if  it doesn't have one. It is searched for first in the cur-
		 rent directory, next all immediate subdirectories of the cur-
		 rent  directory.   Then  it  is  searched for in the same way
		 under the compiled-in global pattern directory (see  ENVIRON-
		 MENT).

       a	 Add  transition to N-state table.  You will be prompted for a
		 transition tuple, 6 cell-state digits (one old state, one for
		 each  orthogonal neighborhood cell, and one new state).  Each
		 specification you enter actually  defines  four  transitions,
		 one  for each possible rotation of the neighborhood.  The new
		 rule will be logged to the file new.transitions and the  four



								6





Xlife(6)						 Xlife(6)


		 transitions added to the evolution function's internal table.

       t	 Test transition.  You will be prompted	 for  a	 string	 of  5
		 state	digits (old state followed by neighborhood cells). You
		 will be shown tye result state	 or  an	 indication  that  the
		 transition is undefined.


   Miscellaneous
       !	 Execute a shell command which needs no input.

       @	 Run a benchmark for a fixed number of generations.


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 comments and ignored.  Files normally begin with a  com-
       ment identifying the version they were saved under.

       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.	 This format is deprecated. and should
       not be used for new patterns.  The -A option of lifeconv emits it.


   D -- Relative to the previous coordinate pair.
       Each following line is interpreted as a (x,y) coordinate pair  relative
       to the previous one, for a cell to be put in state 1. The first is rel-
       ative to the current mouse postion.  The -D option  of  lifeconv	 emits
       it.


   R [xoff[yoff]] -- Relative with optional offsets.
       Each  following line is interpreted as a (x,y) coordinate pair relative
       to the current mouse position.  These relative image sections are  nor-
       mally  drawn with 0,0 on the current mouse position (coordinates may be
       negative). This may be changed by including a pair of  whitespace-sepa-
       rated  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. The -R option of lifeconv
       emits this format.


   M [xsize, ysize] -- run-length encoding with optional sizes
       If the size pair is present it should indicate the size of the  picture
       bounding box.  Each non-section line in the section is interpreted as a



								7





Xlife(6)						 Xlife(6)


       scan line of a relative image which  is	run-length-encoded.  Only  the
       characters  o,  b,  $,  ! and the digits 0 until 9 should appear except
       whitechars which are ignored.  A o character  turns  the	 corresponding
       cell on and a b character turns the corresponding cell off. A $ charac-
       ter skips to the begin of the next image cell  line  which  is  aligned
       just  as	 the  first image cell line that starts as the mouse position.
       The ! terminates all these data. Each of the three characters  ob$  can
       be led ahead by a positive integer, not staring with a 0, which then is
       interpretated as the repetation of that character. Any illegal  charac-
       ter  will be interpretated as ! and terminates the scan.	 The -M option
       of lifeconv emits this format.


   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 digits, with '*' corresponding to 1.	 The -P option
       of lifeconv emits this format.


   I name [xoff[yoff[rotate[flip[delay]]]]] -- Include pattern.
       A #I line should have whitespace-separated fields after the #I consist-
       ing  of a pattern name and five optional integer parameters. 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

       xoff and yoff are integers representing horizontal  and	vertical  off-
       sets;  rotate is an integer that specifies the number of times the pat-
       tern is rotated 90 degrees clockwise  around  the  origin.   Any	 value
       (positive  or  negative) is acceptable, as all are taken modulo 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.  Flips are done before rotations.
       delay is an integer specifying the number  of  generations  to  perform
       before loading the pattern (negative values have same effect as 0).
       The  named  include pattern is loaded as if it had been included in the
       image at this point with the  current  transformation  applied.	 Thus,
       loading sets of included patterns works as one would expect.

       The  include facility is useful for assembling `sampler' collections of
       interesting patterns, as well as maintaining structured representations
       of  complex  patterns.  The -I and -C options of lifeconv may be useful
       for collecting inclusions from multiple files into a  single  self-con-
       tained file.

       When  you  save a pattern in 'I' mode, the program automatically does a
       pattern analysis to detect `blobs'  (completely	connected  regions  of



								8





Xlife(6)						 Xlife(6)


       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  or #S format.  Otherwise the output is a list of blobs followed
       by #I lines that will recreate the saved pattern.  This has two	advan-
       tages:  duplicate  blobs are only written once, and common pattern ele-
       ments are recognized and named (so the save file	 is  also  a  census).
       See the description of the namedPatterns resource for more.


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

       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@machine date (name)', for example.

       #O jb7m@andrew.cmu.edu (Jon C. R. Bennett) 1990-02-12 18:25:54 EST

       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 a format version ID (on the first line of the  file)	 of  Life5  or
       greater.


   C -- Comment
       Lines  begining	with "C" are comments that the user may have automati-
       cally written to the save file, and which may  be  viewed  from	within
       Xlife.


   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,



								9





Xlife(6)						 Xlife(6)


       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


   U filename -- Use ruleset
       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.


   L [text] -- Set label.
       Writes the string text above the upper left hand corner of the bounding
       box  of	the current pattern or pattern block.  If there are several of
       these they are stacked vertically in order; an empty  #L	 line  may  be
       used  as a vertical spacer in sampler displays.	Labels vanish when the
       tentative pattern is flipped, rotated, or incorporated, but will	 reap-
       pear if it is returned to its original position.

       More section formats may be added in the future.


N-STATE SUPPORT
       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
       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 cur-
       rent ruleset.




							       10





Xlife(6)						 Xlife(6)


       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.


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:







							       11





Xlife(6)						 Xlife(6)


			  +----------+--------------------+
			  |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>

       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.

       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 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 origi-
       nal ruleset using a text editor.






							       12





Xlife(6)						 Xlife(6)


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



							       13





Xlife(6)						 Xlife(6)


       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.

       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.



							       14





Xlife(6)						 Xlife(6)


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




							       15





Xlife(6)						 Xlife(6)


       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



							       16





Xlife(6)						 Xlife(6)


       standard output that contains an equivalent version of the pattern in a
       different format. Usage is:

		     lifeconv pattern [-ACDIMPRS] >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.


ENVIRONMENT
       The program has a compiled-in default for its global pattern directory,
       normally /usr/share/xlife.

       If  the	variable LIFEPATH is set to a colon-separated list of directo-
       ries, these directories (and their first-level subdirectories) will  be
       searched	 for  pattern-file  names  and	rulesets.   The	 default  list
       includes "." and the global  directory;	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 Recre-
			   ations, p. 146).

       misc		   contains patterns for miscellaneous other automata,
			   including  a sample Prisoner's Dilemma game and the
			   HighLife replicator.

			   These  will	be  copied  to	the   global   pattern



							       17





Xlife(6)						 Xlife(6)


			   directory by a normal installation.

EXPLORATION
       Here are some 2-state rules to experiment with:

       23/3		   The default, Conway's "Game Of Life" rules.

       23/36		   HighLife,  a	 variant with a simple replicator (see
			   misc/highlife.l).

       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.


RESOURCES
       Xlife  interprets  the  following  preferences  from  the  X   resource
       database:

       grabPercent	   What	 percent  of  your display to grab at startup.
			   Overridden  by  the	geometry  resource,  if	  any.
			   Defaults to 80%.

       autoPlace	   Normally,  when  your first pattern load to a clear
			   universe is of a  pattern  too  large  to  fit  on-
			   screen, Xlife automatically changes scale and tries
			   to center the pattern (second and subsequent loads,
			   or	loads  into  a	non-empty  universe,  are  not
			   affected).  Set this resource to false to  suppress
			   this behavior.

       borderWidth	   Set	the  border  width for Xlife's windows (may be
			   visually useful when running without a window  man-
			   ager).   May	 be overridden by the -bw command-line
			   option.

       stateColor0	   X color to use for displaying state	0.   There  is
			   also	 a stateColor1 and so forth, up to stateColorN
			   where N is the maximum supported number  of	states
			   (normally 8).

       selectBoxColor	   X  color  to	 use  for  the selection box boundary.
			   Defaults to "orange".

       tentativeColor	   X color to use for the tentative  pattern  box  (or
			   cells  in wireframe mode) and pivot X.  Defaults to



							       18





Xlife(6)						 Xlife(6)


			   "cyan".

       transitionBoxColor  X color to use  for	the  selection	box  boundary.
			   Defaults to "magenta".

       meshGridColor	   X  color  to use for the mesh grid lines.  Defaults
			   to "dark gray".

       refGridColor	   X color  to	use  for  the  reference  grid	lines.
			   Defaults to "light gray".

       reverseBoard	   Reverse  the	 Life  board  to black-on-white.  When
			   this option is enabled and "Black" and "White"  are
			   in the stateColor list, they are swapped.  Enabling
			   this is equivalent to the -rv command-line  option.

       falseColorMode	   If the value of this resource is "true", XLife when
			   simulating a	 2-state  automaton  defaults  to  the
			   false-color	display	 mode  toggled by the `*' com-
			   mand.  Default is "false".

       wireframeMode	   If the value of  this  resource  is	"true",	 XLife
			   defaults  to	 the wireframe mode toggled by the `#'
			   command.  Default is "false".

       ruleFile		   If this resource exists, XLife will try  to	inter-
			   pret	 it as the filename of a rule set to be loaded
			   at startup (as though by an F command).

       soupDensity	   Density for primordial soups generated by  the  `%'
			   command.   Defaults to 30%.

       gridInterval	   Set	the  grid  interval  for the `L' command mesh;
			   overriden by the -grid command-line option. A posi-
			   tive	 value	for  this  option turns the grid on by
			   default; a negative one  does  not,	but  sets  the
			   interval to its absolute value.

       saveFormat	   Preferred  image  format;  one of ADIMPRS.  If pre-
			   sent, sets the format to be used  for  saving  pat-
			   terns.  Defaults to saving to the most compact for-
			   mat (P format for  single-piece  patterns,  #I  for
			   multiple-piece patterns.

       namedPatterns	   The	default	 value of this resource is "named-pat-
			   terns".  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 distinguishes an absolute pathname; otherwise
			   the relative	 name  is  searched  for  beneath  the
			   FILEPATH 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 refer-
			   ence (as for the `l' command) and a	cycle  length.



							       19





Xlife(6)						 Xlife(6)


			   When	 the  cycle  length is 0, only one recognition
			   template is generated from each entry; when	it  is
			   nonzero,  one  is  generated	 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:glider2

			   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.  Comments (led by #)	and  blank  lines  are
			   ignored.


BUGS
       When  expose events occur and text is displayed in the life window, the
       window will not be refreshed.

       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.

       The I save format does not yet detect duplicate	blobs  when  they  are
       rotated or reflected.

       The `u' command does not undo generate steps.

       Any  rule  which should produce an active cell from a neighborhood with
       all neighbour cells off will not be processed correctly.	 It will yield
       no  evolution  outside the 8-cell-on-a-side boxes allocated to hold the
       active pattern -- this horizon will increase one step  each  generation
       into the vacancy.


AUTHORS
       Fast 2-state evolution algorithm and file format enhancements: Jon Ben-
       nett <jcrb@fore.com>.

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

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

       Auto-sizing, load format enhancements, N-state support, all of the non-
       Life automata, still-life detection, false-color mode, the select  box,
       #S  and #I save formats, massive code reorganization and optimizations:
       Eric S. Raymond <esr@snark.thyrsus.com>.

       Many new commands, subpixel resolution,	M  format:  Achim  Flammenkamp
       <achim@mathematik.uni-bielefeld.de>.




							       20





Xlife(6)						 Xlife(6)


SEE ALSO
       lifesearch(1), lifeconv(1).























































							       21


