Provided by: xbattle_5.4.1-12_i386 bug

NAME

       xbattle - a multi-user battle strategy game

SYNOPSIS

         xbattle [-<color> <display>...] [-<option> <argument>...]

DESCRIPTION

       Assign  a  team color and  display to  each  player,  and any number of
       options  with argument where required.  <color>   can  be a  monochrome
       tone,  -black  -white -dark  -light,  or a color,   -red -green -blue ;
       <display> is the name of the x display for each player.   Command  line
       arguments  can be supplied in any order.   For a quick introduction, go
       straight to  the  EXAMPLES   section below.  Also, see   the  tutorials
       supplied  with the  game, which are  "csh" shell scripts that  start up
       example games.

OPTIONS

       USAGE: xbattle <args>
          -<c1>          <str>    color to display name <str>
          -<c1>_<c2>     <str>    colors to display name <str>
          -area                   troops proportional to area
          -attack                 allow use of attack key
          -armies        <int>    number of ordered armies
          -basemap                use map scheme, bases visible
          -bases         <int>    number of ordered bases
          -board         <int>    size of board (in cells, x=y)
          -boardx        <int>    width of board (in cells)
          -boardy        <int>    height of board (in cells)
          -border        <int>    border around board
          -bound                  allow drag-bounded vector sets
          -build         <int>    build cities with <int> segments
          -build_cost    <int>    cost to build city segment
          -build_limit   <int>    limit cities each side can build
          -color         <spec>   set RGB values for color <str>
          -color_inverse <spec>   set color <s1> inverse to <s2>
          -decay         <int>    make troops slowly die off
          -diamond                use diamond tiling
          -dig           [int]    [int] step terrain lowering
          -dig_cost      <int>    cost of each dig step
          -digin         <int>    provide entrenchment
          -disrupt                attacks break supply lines
          -draw          <int>    specify a troop drawing method
          -dump          <file>   dump configuration to <file>
          -edit          [file]   interactively edit xbattle board
          -erode                  make unused paths erode
          -erode_thresh  <int>    threshold for erosion
          -farms         <int>    troops slowly grow
          -fight         <int>    intensity of fighting
          -fill          [int]    [int] step terrain raising
          -fill_cost     <int>    cost of each fill step
          -forest        <int>    density of forest
          -forest_color  <spec>   RGB values for forest level
          -forest_tones  <int>    number of forest levels
          -grid                   show grid
          -guns          <int>    range of artillery
          -guns_cost     <int>    cost of each artillery shell
          -guns_damage   <int>    damage done by artillery shell
          -help                   print argument list
          -hex                    use hexagonal tiling
          -hidden                 invisible enemy vectors
          -hills         <int>    slope of hills
          -hill_color    <spec>   RGB values for hill level <int>
          -hill_tones    <int>    number of allowable hill levels
          -horizon       [int]    can’t see enemy past [int] cells
          -load          [file]   load board from [file]
          -localmap               mapping with invisible terrain
          -manage                 managed control of commands
          -manpos                 manual positioning of board
          -map                    use basic map scheme
          -march         <int>    number of delays between marches
          -maxval        <int>    maximum cell troop capacity
          -militia       <int>    randomly distributed troops
          -move          <int>    speed of troop flow
          -nospigot      [int]    cease attack if outnumbered
          -octagon                use octagonal/square tiling
          -options       <file>   read xbattle options from <file>
          -opt_file.xbo           shorthand -options opt_file.xbo
          -overwrite              just use terrain from load file
          -para          <int>    range of paratroopers
          -para_cost     <int>    cost of each paratrooper
          -para_damage   <int>    invading strength of paratrooper
          -peaks         <int>    number of terrain peaks
          -peak_bias     <float>  peak distribution bias (0.0-2.0)
          -rbases        <int>    number of distributed bases
          -rbase_range   <int>    distance of rbase from enemy
          -repeat                 repeat of last mouse command
          -replay        [file]   replay stored game from [file]
          -reserve                allow reserve of troops
          -scuttle       [int]    enable city scuttling
          -scuttle_cost  <int>    cost of scuttle
          -sea           <int>    pervasiveness (+ levels) of sea
          -sea_block              use block-fills, not hue-fills
          -sea_color     <spec>   RGB values for sea level <int>
          -sea_tones     <int>    number of allowable sea levels
          -sea_value     <float>  darkness of seas for b/w games
          -seed          <int>    random number generator seed
          -speed         <int>    speed of updates
          -square        <int>    side length of cell
          -stipple       <spec>   set stipple (b/w) pattern
          -store         [file]   store game for later replay
          -towns         <int>    density of distributed towns
          -triangle               use triangular tiling
          -trough_bias   <float>  trough setting bias (0.0-2.0)
          -xpos          <int>    x position of board on display
          -ypos          <int>    y position of board on display
          -wrap                   wrapping around edges of board

RUN-TIME COMMAND SUMMARY

COMMANDS IN GAMEBOARD

        LFT MOUSE:       toggle command vector
        MID MOUSE:       clear and set new command vector
        RGT MOUSE:       repeat previous command (-repeat)
        SHIFT-LFT MOUSE: march (-march) fork move (else)
        SHIFT-MID MOUSE: force march (-march) fork move (else)
        SHIFT-RGT MOUSE: paratroops (-para)
        CTRL-RGT MOUSE:  artillery (-guns)
        CRTL-’s’:        pause game
        CRTL-’q’:        resume game
        CRTL-’p’:        save game state to map file
        ’a’:             attack enemy square (-attack)
        ’b’:             build base (-build)
        ’B’:             build full base (-build & -manage)
        ’s’:             scuttle base (-scuttle)
        ’f’:             fill terrain (-fill)
        ’F’:             fill full terrain (-fill & -manage)
        ’d’:             dig terrain (-dig)
        ’D’:             dig full terrain (-dig & -manage)
        ’p’:             paratroops (-para)
        ’P’:             paratroops - on (-para & -manage)
        ’g’:             artillery (-guns)
        ’G’:             artillery - on (-guns & -manage)
        ’z’:             cancel all movement
        ’c’:             cancel managed operation (-manage)
        ’0’-’9’:         reserve (-reserve)

COMMANDS IN TEXT AREA

        CONTROL-c:       quit the game
        CONTROL-w:       quit game but watch others play on
        CONTROL-g:       ring bell on all game displays
        CONTROL-p:       dump the current game state
        OTHER CHARACTER: append to message string

DESCRIPTION

       xbattle  is a   concurrent  multi-player battle  strategy   game   that
       captures  the dynamics  of a  wide  range of military  situations.  The
       game board is a matrix of game cells (such as squares or  hexes)  which
       can  be   occupied by troops  of various colors  or shades.  The number
       of troops in a cell is indicated by the size of a colored troop  circle
       (or  square)   within  that cell.  The troops are commanded by clicking
       the mouse near the edge of the cell in the direction that the  movement
       is  to  take place.  The command will be acknowledged by the appearance
       of a movement vector, and thereafter, in each  update cycle, a  certain
       proportion   of   the  troops  will  move from the source  cell  to the
       destination  cell until   the   source  cell  is  exhausted.   Movement
       vectors  can  be set in several directions at  once, in which case  the
       movement is   divided evenly between  the vector  directions,  and  the
       command  remains  active until  canceled.  Thus a  trail of circles can
       be  set up as  a supply   line that  will deliver  troops  steadily  at
       its  endpoint.   The movement vector remains active even if the  number
       of troops  in that cell is zero, although the movement vector will then
       be displayed at half length.  The game is concurrent, so that  commands
       are given continuously  by  all players without waiting for  turns.

TEAM SIDES AND PLAYERS

           -<color>, -color, -color_inverse, -stipple

       The game is started from one display, and each player must play from  a
       separate  display,  players  being  assigned to  a color   team  by the
       command line   option  "-<color>  <display>".   The  parameter  <color>
       determines  the color of the troops of that team, which can be either a
       monochrome tone like black,  white, dark,  light, or a true color  like
       red,  green, blue, although the true colors will appear on a monochrome
       monitor as either black or white with an identifying character in  each
       troop  marker  which  is  the  first  letter  of the  color  name.  For
       instance, the team color  "-red" would appear on a  monochrome  monitor
       as  black with a letter  "R" in the middle of  each troop marker.   The
       legal team color names can be  selected from any  color defined in  the
       file    /usr/lib/X11/rgb.txt   which includes  such  bizarre entries as
       "LavenderBlush", "MistyRose", "PapayaWhip"  as  well as  the   standard
       "red",   "green",  "blue" and  "black" and "white" etc.  Alternatively,
       colors   can  be   defined  individually     in    the   default   file
       (.xbattle),  an  option  file  (see  OPTIONS section  below), or in the
       command line itself using the "-color <str> <r> <g> <b>" option.   With
       this  option,  the  color is given by <str>, and the red green and blue
       components by <r>, <g>, and <b> respectively, in the range  (0-255).  A
       black  and  white  pattern  can be assigned to correspond to color name
       <str> via the "-stipple <str> 8  x  <hex>"  option,  where  the  binary
       breakdown  of each of eight hex numbers (in form like "0xa4") specifies
       one of the eight rows of the pattern.

       By default, xbattle  supports  the  colors  "dark",  "light",  "gator",
       "brick",  which  appear  as  bitmap  textures  on  monochrome monitors,
       allowing monochrome players to have six  distinguishable  team  colors.
       A  number    of  people   can   be  assigned   to  the  same   team  by
       repeating  the   color  for  different  displays,  for  example   "-red
       display1  -red display2",  and each member of the  team will be able to
       command any troops  of that  team.   The <display>  argument designates
       the   name  of  the  display    on  which  the  team  of that  color is
       playing, so each player must  be given a color and a  display.  Display
       names   can  be   found  with  the  unix command "who", which will list
       display names for users in  the  last  column  like  (cnsxk:0.0).   The
       system  console is  always  designated unix:0.0.  The display  name can
       be   modified for remote    games,  for  example the terminal cnsxk:0.0
       on   park.bu.edu  (email  address  of  machine  "park")  is  designated
       cnsxk.bu.edu:0.0 .  XBattle recognizes  :0.0  as  the  default  (screen
       zero  on  the display),  so the  :0.0 may be  omitted from  the display
       name.  XBattle also  recognizes a special  display  name   "me",  which
       means   the  display   from   which   the   program  is  started.  When
       playing between   color and  monochrome  displays  the colors   can  be
       specified  more exactly by concatenating a color name with a monochrome
       name, for example "-red_white" (color first), which would display  that
       team  as red on color monitors  and white on  monochrome monitors.  All
       command line flags  and arguments for  the game can  be  given  in  any
       order   as  long as the argument  directly follows its   flag, and most
       arguments are scaled to range from 1  to 10, with  5 being the  default
       value.   It is also possible  to set different game parameters  for the
       different  displays, so that the game  can be biased  to favor a   less
       experienced player (see BIASED GAMES below).

OPTIONS

           -options

       A  large  number  of  command  line options are available to define the
       parameters of the game.  In essence, xbattle  is   many   thousands  of
       games  rolled into one.  The options can be presented in any order, and
       may be typed in with  the command line, or they  can be stored   in  an
       options  file (default filename = default.xbo),  or some can be  stored
       and others added to the command line.  The format for the options  file
       is exactly the same as the format  for the command  line except that in
       the  file each option (plus argument, where applicable) is placed  on a
       separate line.  So, for example, the game...

          xbattle -black me -white cnsxk:0.0 -armies 4 -farms 5
                   -attack

       could also be played with the command...

          xbattle -black me -white cnsxk:0.0 -options myoptions.xbo

       or alternatively with the shorthand version...

          xbattle -black me -white cnsxk:0.0 -myoptions.xbo

       where the file myoptions.xbo consists of the lines...

          -armies 4
          -farms 5
          -attack

       If the specified options file cannot be found in the current directory,
       xbattle will search the default xbo  directory  DEFAULT_XBO_DIR,  which
       can be specified at compile time in the makefile.

       XBattle checks for the   presence of the  default file  ~/.xbattle,  in
       which options can  be set in advance, saving  the  trouble  of   having
       to  set them at run time or include an options files. The  default file
       is typically used to set up commands which are  used  in  nearly  every
       game  at  a particular site.  Thus a typical default file might contain
       color (and black and white) definitions, cell size,  artillery  damage,
       and  the  like.  Option files, on the other hand, are typically used to
       define specific scenarios involving unique combinations of command line
       arguments.   Conflicting  commands  in the default and options file are
       resolved in favor of the options file.

TROOPS

           -bases, -rbases, -rbase_range, -armies, -militia

       Initial troop allocation  is controlled  by several  command   options,
       including  -bases  <n>, -rbases  <n>,  -armies  <n> and   -militia <n>.
       Armies and  militia are  troops on the  gameboard, whereas bases  which
       are  indicated by circles on the gameboard,  provide a steady supply of
       troops.  The   -bases option  allocates   <n>  bases  to each     team,
       symmetrically  arranged on the game board, whereas -rbases <n> arranges
       them  randomly   (which works  well  with  the  -horizon option).   The
       minimum  distance  between enemy bases (in cells) can optionally be set
       using the -rbase_range <n> command.  Note that large values of <n>  may
       not  allow  any valid rbase allocation, in which case xbattle will exit
       with an error message.  The -armies option allocates <n>  armies  (full
       troop  cells)  symmetrically  arrayed,  whereas  -militia  <n> scatters
       militia of random strengths to random locations, with  a  probabilistic
       density   of   <n>.  At least one of these four options is required  to
       provide initial troops  for the game, and they may be used in arbitrary
       combinations.

RESUPPLY

           -towns, -farms, -decay, -erode, -erode_thresh

       The  bases  created by the -bases or -rbases produce a steady supply of
       fresh troops.  The bases can be occupied by an opposing team, with  the
       troops  produced  by such bases are always  the  color of the occupying
       force.  The capture of all bases thus  becomes the strategic  objective
       of  the  game.  This arrangement  simulates desert warfare, as long and
       tenuous  supply lines  develop between the  base and the battle  areas.
       Another   form of resupply  is provided by  the  command option "-towns
       <n>".  This  produces a  number of smaller  unoccupied  supply  sources
       scattered  randomly over the game board at  a density determined by the
       argument <n>, and with random  rates of troop production, indicated  by
       the  radius of the circle on the game board.  Towns must be occupied by
       a team to begin producing troops.  This option  simulates yet a  larger
       scale  of operation as the  combatants battle to occupy  the towns.   A
       more distributed  form  of resupply  is evoked  by the command   option
       "-farms  <n>"  whereby   every   cell of the   game  board will produce
       troops   as soon as   it is occupied,   at a rate  proportional to  the
       argument   <n>,  and the strategic  objective becomes the occupation of
       the largest areas  of the  gameboard.  This  option  simulates  a   yet
       larger  scale of operation and requires complex management of resources
       to concentrate  the distributed  resources  and deliver  them   to  the
       battle  front.  In  large  scale  scenarios additional  realism may  be
       added by  using the "-decay <n>" option whereby the  troop  strength in
       all  troop  cells   decays constantly  in proportion  to  the value  of
       the decay argument.  This reflects  the  fact  that  armies  constantly
       consume  resources  even   while they are  idle, and  an   army without
       constant resupply  will wither  away.  With the  decay option,   a  set
       of  bases,  towns or farms can only support armies of limited size, and
       the armies will  dynamically grow or shrink  until    they  reach  that
       size.   Since  this  number   includes  the  troops   that make  up the
       supply  line, the fighting power  of  an   army  diminishes   with  the
       length of the supply line.  The default  decay value is zero, i.e.   no
       decay.  All the resupply options can be used in any  combination.   The
       "-erode <n>" command doesn’t affect resuply, per se, but it does effect
       the movement vectors through which troops flow by causing them to erode
       away  as they grow older.  All movement vectors in a cell will be unset
       at a  random  time  not  to  be  less  than  <n>  update  cycles,  with
       probability  of  erosion  for  each  subsequent cycle determined by the
       "-erode_thresh <m>" argument, where <m> is  the  percentage  chance  of
       erosion.

ENHANCED MOVEMENT COMMANDS

           -repeat, -bound, -attack, -march, -reserve

       With  the option "-repeat"  you can repeat  the last command  using the
       right mouse.   If for example your  last command to a cell consisted of
       a  "move  up" command  by  clicking near the top  edge of the cell, you
       can now command other cells to also move up by clicking in those  cells
       with  the  right  mouse.  That way you no longer have to aim your click
       exactly at  the  top side  of  those cells, but can   click  the  right
       mouse   anywhere  in  that   cell,  which  saves time.  This command is
       supported in biased games - i.e.  it can be set for one  team  but  not
       another.   Commands  can  be made to apply to  more than one  cell with
       the option "-bound". This is achieved by defining a bounding  rectangle
       within  which the command is valid.  For  instance,  to command a block
       of cells to  all move up  simultaneously,  you place  your  mouse  near
       the   top  edge  of a  cell (may be  unoccupied, or enemy occupied) and
       press the button (setting the command "go up", then you drag the  mouse
       to  another  game  cell  where  you release  the button.  The start and
       end cells  of  the mouse  drag  define  the opposite    corners   of  a
       rectangle  within  which   all the game  cells occupied  by your troops
       receive the  command  "go  up".   The  "-attack"  option  makes  quick,
       multiple front attacks possible.  By issuing an "a" command in an enemy
       cell, all adjacent  friendly  troops  will  automatically  alter  their
       movement  vectors  so  as to attack the enemy cell, and only that cell.
       The "-reserve" option allows a player to define a level   of   reserves
       to remain  in  the cell  despite any movement vectors.  For  instance a
       reserve level  of 5 would ensure   that   the  cell  will   maintain  a
       reserve   of  50%  capacity, and movement  out of that  cell  will only
       occur with  troops  in  excess of the reserve level.  This is extremely
       useful  when  a supply line must pass through a strategically important
       part of the board.  The reserve level is  set  in a  particular    game
       cell   by  pointing  to that cell with the mouse and striking  a number
       key, "1" for 10% reserves, "2"for 20% reserves, and so forth up to  "9"
       for 90% reserves.

       With  the  option "-march <n>", troops may be  commanded to  march in a
       particular direction and  to continue in that direction without further
       commands.   March  commands  are  activated  with  shift left  or shift
       middle mouse button.  For example,  if you click near the  top edge  of
       a   cell  with  "shift left mouse",  the troops will begin to march up,
       and on arrival  in the next cell they will transfer the  march  command
       to   that  cell  so  that they  will continue  marching upwards  to the
       next   cell,  and so forth. If a marching  column  encounters   hostile
       forces   the   march command  is canceled and  the   column stops.   To
       prevent marching  columns from traveling  much  faster  than   manually
       commanded  troops,   the  march argument <n> defines the number of game
       update  cycles that the troops  must  wait  in  each  new  cell  before
       marching  on to the next cell, so that "-march 1" will result in a fast
       march, whereas "-march 10" will be  slow.    The   "march  command"  is
       indicated  on the  game board  by a double command  vector (looks  like
       an "="  sign)  in the appropriate direction, and  the march command  is
       always  passed on  to the head of the  column.  March   commands may be
       set  in   cells that  are  NOT occupied by your  troops,  and  will  be
       activated   when  a  marching column arrives in that cell.  This allows
       you  to define turns  in the path  of  the  marching  column  to  avoid
       obstacles.   A  "stop  march"  command  may  also be set to program the
       marching column  to stop  in  that cell.  This is achieved by  clicking
       "shift  left  mouse" in the center of that cell, and will be  displayed
       as an  empty box in  that cell.  When set  with  the left   mouse,  the
       march   vector    is   overwritten  on  to  existing  command   vectors
       encountered in the march  path, whereas when  set   with   the   middle
       mouse    the  march   vector   removes  and  replaces  existing command
       vectors.  March commands are canceled by clicking on the  cell  without
       the  shift   key.    March   commands   may  be   set in cells that are
       beyond the visible  horizon in the  normal way , and will appear  as  a
       double  vector in  that cell so long  as that cell is not a "sea" cell.
       If the target  cell contains invisible enemy troops,   then  the  march
       command  vectors  will  appear  initially,  but disappear again as soon
       as the enemy  is approached close enough to be visible.  March commands
       are specific to the team that sets  them, and different march  commands
       may be  set by different   teams in the same  game  cell.   The  double
       command vectors are visible  only to the team that sets  them.

GAME PLAY

           -fight, -speed, -move, -seed,
           -digin, -nospigot, -disrupt, -maxval

       Whenever   troops   of  different colors occupy  the  same game cell, a
       battle ensues, indicated by concentric markers of  the two colors,  and
       a   "crossed swords" (X) symbol.  During  battle, one or both sides can
       incur  losses   according  to     a random nonlinear     function  that
       disproportionately  favors the  more numerous troops.  The steepness of
       the nonlinearity, i.e. the advantage given to the more  numerous  side,
       is  controlled by  the  -fight parameter.  A  small  value will produce
       lengthy drawn out battles which favor a  defensive strategy, whereas  a
       large   value produces quick decisive battles  where the random element
       is more  significant,  favoring an  offensive   strategy  even  against
       superior  odds. In the absence of the -fight option,  the default value
       of 5 is used.  The -fight parameter is also automatically modulated  by
       the  game  speed  parameter (-speed) in  order to slow down  battles in
       fast games and vice versa.  Since only 1/3 of the  troops can  enter  a
       cell  in  each  update cycle (with the default -move 5), attackers of a
       full  cell are  always outnumbered  initially,   unless  a  coordinated
       attack   is launched  from  three  sides   simultaneously.   The  -move
       argument thus  has   a significant influence on   the efficacy   of  an
       attack.   The  -disrupt  option dictates  that when a game  cell  comes
       under  attack,  all its command   vectors  are  immediately   canceled,
       breaking  supply lines which must be repaired by hand after the attack.
       In other  words, there can be no  movement under fire, and even   small
       forces  can  be used to provide covering  fire to  "pin down"  a larger
       force,  at least until they  are counter-attacked  and eliminated.    A
       side  effect  of  this  option  is that  when   an attacking  cell   is
       counterattacked, both cells attempt to  cancel each  other’s  movement,
       i.e.   to  interrupt  the attack.  The cell that  is  updated next will
       prevail, canceling the command vector of the  other  cell.   Since  the
       game  cells   are  updated in a  random sequence, there  is  no telling
       which cell will prevail, and the commander must  click   repeatedly  to
       renew    the command vector in  order  to  press  home the attack under
       opposition.  This  simulates the tactical  situation where a  commander
       must  personally intervene to ensure  the  maximal effort is applied at
       the most critical  points of  the   battle.   The  "-seed  <n>"  option
       simply  sets  the  seed of the random number generator to <n>, which is
       useful  for  recreating  scenarios.   By  default  the  random   number
       generator  is  seeded with a combination of the system time and process
       ID number --- a more-or-less random number.

       In each update cycle some fraction of the troops in a game cell move to
       adjacent  cells   indicated  by  the  command   vectors.    The default
       fraction   is 1/3,  so   that  in each successive  cycle,   1/3 of  the
       remaining   troops   move  out of the   cell until it is   empty.  That
       fraction is adjusted with the -move argument, 1 for less movement,  and
       10  for  more movement.  The   option -digin  <n>  simulates  the  time
       and effort required  for troops  to dig in   and build  fortifications.
       This  is achieved by reducing the  rate of flow  of troops into  a cell
       as it fills up  to capacity, so that to  achieve a really   full  troop
       cell  the  men   must  dig  in and settle  down to accommodate the last
       arrivals.  The argument <n> modulates the strength of this effect, from
       1  to  10  for  small to large.  The maximum number of troops which can
       occupy a single cell is set via -maxval <n>.  Note that  for  octagonal
       tiling  only,  the  some  cells  (the  square ones) will have different
       maxvals.

       The -nospigot [n] option causes troops to automatically  cease  attacks
       when  they  are highly outnumbered, preventing the "spigoting" (perhaps
       "siphoning" would be more appropriate) which  can  empty  whole  supply
       lines  into  needless slaughter.  Neighboring supply lines are shut off
       whenever the troops in a cell are outnumbered by a ratio given  by  the
       argument to the nospigot command.

BOARD CONFIGURATION

           -cell, -board, -boardx, -boardy, -border, -manpos,
           -xpos, -ypos, -area, -wrap, -grid

       The  dimensions  of  the game board can be tailored via the -boardx <n>
       and -boardy <n> options which set the  horizontal  and  vertical  board
       dimensions,  in terms of cells.  The -board <n> option creates a square
       board.  The dimension of each cell, in pixels, is set by the -cell  <n>
       option.   The  xbattle window border can be set with -border <n>, while
       the initial x and y position of the game board can be  set  with  -xpos
       <n>  and -ypos <n> respectively.  The -manpos option allows each player
       to position his or her window interactively (does  not  work  with  all
       window  managers).   A  grid  indicating  the  borders  of each cell is
       established via the -grid command (the default), and can be  eliminated
       via the negative command -no_grid.  Game play wraps around the edged of
       the board if the -wrap  option  is  invoked,  although  certain  tiling
       schemes  require even or odd board dimensions for wrap to work properly
       in both the horizontal and  vertical  directions.   Troop  markers  are
       scaled  by  area (proportional to number), rather than diameter, if the
       -area option is used.

TILING METHODS

           -diamond, -square, -hex, -octagon, -triangle

       A number of different tiling methods are available in xbattle, each  of
       which   employs  cells  of  a  different  shape.   Square  cells  in  a
       rectangular grid  are  used  for  the  -square  option  (the  default).
       Hexagonal  cells  are  used  with the -hex option.  The -diamond option
       results in a square tiling, tilted by 45 degrees.  A tiling  consisting
       of  two  orientations  of  equilateral  triangles  is  invoked with the
       -triangle option.  The -octagon option results in a  tiling  consisting
       of  a  combination  of  regular  octagons  and  small  squares.   Since
       different cell shapes have different neighborhoods, troop  movement  in
       the different tilings can have a very different feel, and may take some
       getting used to.

DRAWING METHODS

           -draw

       The method of drawing and erasing troops and terrain is defined via the
       -draw  <n>  option,  where  the argument indicates one of five distinct
       techniques, of varying  speed and flicker.  They are: Method  0:  Erase
       the  cell by drawing a circle the color of the terrain, then redraw the
       cell contents.   This is the method employed in xbattle versions before
       5.3.   Although  simple  and  fast,  the onscreen erasing and redrawing
       often results in annoying flicker.  METHOD 1: Erase and redraw cells as
       for  method 0, but do the whole process on a backing store pixmap, then
       copy the cell to the window.  The copy from the pixmap  to  the  window
       adds  some  overhead,  but flicker is completely eliminated.  METHOD 2:
       Copy a blank cell from pixmap storage to a  working  pixmap,  draw  the
       cell contents, then copy the cell to the window.  This method exchanges
       the cell erase of method 1 for a  pixmap-to-pixmap  copy  operation  to
       also  provide  flicker-free  game animation.  Unfortunately this method
       only works for square tilings, since  only  rectangular  cells  can  be
       perfectly  extracted  during  X-Window copy operations.  METHOD 3: Copy
       the cell from the window to a pixmap (along with a little surround  for
       non-square  cells),  erase with a circle, redraw the contents, and then
       copy the cell back to the window.  Like method 0, but  with  two  extra
       copy  operations  and  no  flicker.   METHOD 4:  Copy the cell from the
       window to a pixmap, erase the contents (including terrain) via  an  AND
       operation,  draw  the  terrain  via  an  OR  operation,  draw  the cell
       contents, and copy back to  the  window.   This  method  is  fabulously
       complex,  but  has  the advantage of being the only of the above method
       which redraws the entire cell contents, including terrain.  Method 0 is
       still  the  default.  With any reasonably fast-drawing machine, methods
       1, 2, and 3 should provide quick enough animation.  Method 4 is  a  bit
       cumbersome.   Which  of  the methods is the fastest depends on how fast
       the source machine is at drawing circles  and  at  copying  rectangles.
       Due  to  the  buffering  of  X  Window  drawing commands, even method 0
       provides reasonably good results since  the  cell  erases  often  never
       appear on the screen before the cell redraw.

GUNS AND PARATROOPS

           -guns, -guns_damage, -guns_cost,
           -para, -para_damage, -para_cost,
           -manage

       The  command option -guns <n> enables the key ’g’ to be used to control
       artillery, which can be shot from any  occupied game cell.   The  range
       and  direction of the shot are determined by the position of the cursor
       in the game cell relative to the center of the cell --- near center for
       short  range  and   near  the edge for long range, as  modulated by the
       argument <n>.  Every shell costs a number of  troops  from  the  source
       cell equal to the argument of -guns_cost <n> (default: 2), and destroys
       a number of troops at the destination cell equal  to  the  argument  of
       -guns_damage  <n> (default: 1).  The fall of  shot is indicated by  the
       brief appearance of a little  dot of the attacker’s  color.   With  the
       -horizon  option  the  fall of shot may   not be visible for long range
       shots, although invisible enemy  troops will  be  destroyed  where  the
       shell  falls.  Artillery can damage both friend and foe, so it  must be
       used with caution.   Paratroops are enabled by the option   -para  <n>,
       and are launched   similarly to artillery using the of -para_damage <n>
       (default: 1) at the  destination cell  is  equal  to  the  argument  of
       -para_cost  <n> (default: 3).  The drop zone is indicated by the  brief
       appearance  of a  parachute  symbol.   When   used  with   the  -manage
       option, artillery and paratroops can be  deployed continuously with the
       ’G’ and ’P’ keys instead of the ’g’ and  ’p’ keys.  This will  initiate
       a   continuous   barrage that  will  only stop when the  source cell is
       exhausted, but will recommence when it is   resupplied.    The  managed
       command  is   indicated by the letters "GUN"   or "PAR"  in  the source
       cell, and  can be canceled with  either the ’c’  key,  or by giving the
       source cell a movement command.

TERRAIN

           -hills, -hill_tones, -hill_color,
           -peaks, -peak_bias, -trough_bias,
           -forest, -forest_tones, -forest_color,
           -sea, -sea_block, -sea_tones, -sea_color, -sea_value

       The  command option -hills <n> initializes  random hills which restrict
       movement when going from low to high  elevation,  and enhance  movement
       from  high to  low, but do   not affect  movement  on  the  level.  The
       elevation is indicated by the shade of gray,  light  for high and  dark
       for  low on monochrome,  and brownish for  high and greenish for low on
       color displays.  The argument controls the amount of energy gained  and
       lost  on hills, i.e. the steepness.  Hills provide a tactical advantage
       when  attacking downhill.  With very steep  hills  (-hills 9)  movement
       from   very low   to  very   high  elevation  (a  cliff) is   virtually
       impossible.  The number of discrete elevation levels  is  set  via  the
       -hill_tones  <n>  option.   On  color  monitors,  the  hill hues can be
       tailored via the  -hill_color  <n>  <red>  <green>  <blue>,  where  <n>
       specifies the elevation index (from 0 to hill_tones-1) to be changed to
       the RGB triplet.   The  color  of  unspecified  elevation  indices  are
       linearly interpolated based on specified indices.

       The  command  option  -forest  <n>  initializes  random  forests  which
       restrict movement within the forest, but do  not affect  movement  from
       thin  to   thick forest.  On both color and monochrome  displays, thick
       forest  is  dark, and thin is   light.   Forest  may  not  be  used  in
       conjunction with hills.  When  transitioning from one forest  thickness
       to another, the  movement is determined by the  destination  cell,  not
       the  source cell, so  that troops deployed  within  a forest but at the
       boundary have a  tactical advantage over those   deployed  outside  the
       boundary.   As  for  hills,  the number of distinct forest densities is
       specified via the -forest_tones <n> option, with colors being specified
       by the -forest_color <n> <red> <green> <blue> option.

       The  command option -sea <n>  generates randomly distributed bodies  of
       water, whose  prevalence is  determined  by  the  argument <n>.    Such
       bodies  of water cannot be crossed by infantry.   A small value creates
       scattered ponds and lakes, which influences the tactical deployment  of
       troops,  whereas a large value creates a maze-like pattern of fjords or
       rivers which  isolate blocks of land  into islands which can   only  be
       taken   by    paratroops.  On monochrome   monitors  water appears dark
       mottled grey,  and  on color  monitors it appears as various shades  of
       blue.  Like hills, seas have elevation (depths), the number of which is
       controlled via the -sea_tones <n> option, with colors determined by the
       -sea_color  <n> <red> <green> <blue> option.  Besides looking nice, sea
       depths are useful when playing with the -dig and -fill options (see the
       TERRAIN  MODIFICATIONS  section).   On  monochrome monitors, the option
       -sea_value <float> determines the  blackness  of  the  shallowest  sea,
       expressed  as  a fraction.  For backwards compatibility, sea depths can
       also be indicated by the size of  the  sea  marker  if  the  -sea_block
       option is invoked.

       Hills (and forest and seas) are created by a complex terrain generation
       algorithm which bases elevations (or densities, in the case of forests)
       on  a  number  of  fixed points, as specified by the -peaks <n> option.
       Based on  these  <n>  points  with  randomly  determined  position  and
       elevation,  the  elevation  of the rest of the game cells is determined
       via a non-linear interpolation process.  The -peak_bias <float>  option
       determines how hill elevations and forest densities will be distributed
       ---  0.0  yields  generally  low-elevation  terrain,  with   spire-like
       mountains, while 2.0 yields generally high-elevation terrain, with deep
       ravines.  The default value of  1.0  results  in  pleasantly  contoured
       terrain.   Similarly,  the  -trough_bias  <float>  option  controls the
       distribution of sea depths.

TERRAIN MODIFICATION

           -dig, -dig_cost,
           -fill, -fill_cost,
           -build, -build_cost, -build_limit,
           -scuttle, -scuttle_cost,
           -manage

       The command options -dig [n] and -fill [n] allow run time  modification
       of  the  terrain  by  digging hills and seas down to lower elevation or
       filling them up to higher  elevation.   This allows  the   construction
       and   breaching  of  defensive   fortifications.   The  cost  of  these
       operations  (in  troops)  is  determined  by  the  -dig_cost  <n>   and
       -fill_cost <n> options.  The operations are accomplished by positioning
       the mouse  on the friendly cell and striking the "d" key (for  dig)  or
       the  "f"  key  (for fill).  With the -sea   option, -dig <n> and  -fill
       <n>  can   be supplied with an argument which specifies the  number  of
       sea depths (see also -sea_tones).  Since it is impossible to  occupy  a
       sea cell  to  fill  it, filling seas is  accomplished  by  setting  the
       command  vector  as  if  to  move into the sea, and then  pressing "f".
       Likewise for digging a  sea  deeper.   For  all  other  fill   and  dig
       operations the troop cell may not have any command vectors set.

       The  -build  <n>  and  -scuttle  [n]  options  allow  the building  and
       destruction  of  bases (or towns).  The costs of these  operations  (in
       troops)  are determined by -build_cost <n> and -scuttle_cost <n>.  When
       the  mouse is positioned  on  a  friendly  cell  and  the  "b"  key  is
       pressed,  the  troops   are  exchanged  for a 1/<n> fraction of a base,
       displayed as an arc  segment.  Thus <n> building commands are  required
       to  produce a functional base.  When the capture of a base by the enemy
       seems inevitable, it is  often  advisable  to  scuttle  the    base  to
       prevent    it   falling into  enemy hands.   Scuttling  is performed by
       positioning the mouse on the  base and  pressing the "s" key.   If  the
       build  option  is  not  enabled,  this reduces the size (and production
       capacity) of that base by one scuttle unit  for  each  scuttle_cost  of
       troops expended, where a scuttle unit is defined by the argument of the
       scuttle option (default: 5).  Usually, several  keystrokes are required
       to   complete   the  destruction.   When  used  in conjunction with the
       -build  option, instead of reducing  the size   of   the  base,    each
       scuttle  operation   removes  a section (arc segment) of the base, at a
       troop cost indicated by the -scuttle_cost <n>  option.   A  base   will
       not  produce  troops  if  even a single segment is missing, although of
       course it is less  expensive to repair (with  "b" build) a  base   with
       fewer segments missing.

       As  with  -guns and -para, the -dig, -fill, and -build options (but not
       the -scuttle option) can be "managed" with the  -manage  option,  which
       allows  a  player  to  issue a single command to initiate a sequence of
       repeated dig, fill,  or build operations using the keys ’D’,  ’F’,  and
       ’B’  respectively.  The  managed operation will continue until the task
       is done, as  long as the cell is  resupplied.   The  managed  operation
       will be indicated by the letters "DIG", "FIL" or "BLD"  respectively in
       the managed cell.    Managed operation can be  canceled  with  the  ’c’
       key, or by issuing  a  movement command  to the cell.

VISIBILITY

           -horizon, -hidden, -map, -basemap, -localmap

       The  command option  -horizon [n]   restricts the view  of enemy  troop
       deployment to within <n> cells of any  friendly troops.  Horizon can be
       called  with  no  argument,  in which case the default <n> = 2 is used.
       Intelligence of  more remote   regions can be   gathered by     use  of
       paratroops.    The command option   -hidden  (no  arguments)  makes the
       command vectors of  the enemy  invisible  at any  range.  The   command
       option  -map is similar to -horizon except that  it restricts your view
       of geographical objects  as  well  as  enemy troops, although  it  will
       "remember"  any terrain that you  have seen once, as if  you had mapped
       that information.  The -basemap option maps bases and towns as it  does
       the   terrain  ---  once  you see them, they’re remembered.  The option
       -localmap  maps  only the local area around your  troops, and  features
       disappear  as you move   away  again.

STORE AND REPLAY

           -store, -replay

       The  -store   <file>  option   allows you to  store  enough information
       about the visual progress of the game  to  reconstruct  it  later  with
       -replay  <file>  option.    When  -replay  is  used, all  other command
       options are ignored except the -<color> <display> options, which can be
       used   to  send the replay to other displays.  When  doing so, only the
       <display> portion of the option is used, the <color> is  ignored.   So,
       if  you  play  a game with   many command line  parameters and  several
       displays   with the argument -store <file>,  after  the  game  you  can
       repeat the same command line but just change -store to -replay, and the
       game  will  be  replayed  on   the  displays   of   all   the  original
       combatants.    When  xbattle  is called with the -replay option  alone,
       the default display   will  be "me".  If store  or  replay  are  called
       without  a file name,  the default name "xbattle.xba" will be used.  In
       the  replay,  the  view  restrictions  of   the  -horizon  option   are
       deactivated,  i.e.    all enemy troops are visible.   The replay action
       can be  paused or resumed  by typing any key, and  can  be  interrupted
       with either control-c or control-q.

GAME STATE SAVING, LOADING, AND EDITING

           -load, -dump, -overwrite, -edit

       The  game state  can  be saved  at any point during  the game with  the
       control-p key.  This creates a file called  "xbattle.xbt", or the  name
       given  with the  argument  -dump <filename>, which represents the state
       of the game board at the time of  saving.  Future games can be  started
       from  the saved game state with the command option "-load <file>" where
       <file> is  optional  if  the  file  name   is  "xbattle.xbt".   If  the
       specified  load  file cannot be found in the current directory, xbattle
       will search the default xbt directory  DEFAULT_XBT_DIR,  which  can  be
       specified  at  compile  time  in  the  makefile.   Note  that most game
       parameters ARE NOT STORED.  Only terrain features (forest, hills, seas,
       towns  etc.)   and  troop  deployment.   This   means  that if you were
       playing with -farms, -decay, and -guns then you will have to type  them
       in  if you want  them for the  new game.  The  terrain and boardsize of
       the saved  map file will override all  terrain and boardsize  arguments
       when  loaded.  Troop and town/base producing options (such as -militia,
       -towns, and -rbases) will add new features on top of  the  loaded  game
       state.  If the -overwrite option is issued, only the terrain and cities
       from the loaded game will be used --- no troops will appear.   This  is
       useful  for  repeating  games  with interesting terrains with different
       troop configurations.

       Game boards can  be  created  or  modified  with  the  -edit  function,
       which  is called with the command option "-edit <file>" where <file> is
       optional  if  the  file name is  "xbattle.xbt".   With this option,  no
       game  is played, but  instead, the mouse  and  key commands control the
       features  of the  map to be  edited.  To edit  an  existing  file,  use
       "-edit  <file>" and type "l" when the editor  comes up.  This will load
       the file named in  the  edit argument.  To  save that  file,  type  "d"
       and  the file  will  be saved  to  the same   file  name.  No provision
       is made for saving to a different  file  name.   When  using  the  edit
       mode,  the  command  line arguments  must  reflect the number and color
       of players to  be used, and the sea,  forest or hills options  if  they
       will   be   required.   For    example,   to   create  a    map  called
       "mymap.xbt"  with three color teams and  seas,  could  use the  command
       "xbattle  -edit mymap.xbt -sea 7 -white me -black you -dark you".  Note
       the use of  the special display "you",  which is a  dummy display  name
       used  as a place holder for the black and dark colors.  The interactive
       commands are as follows:

          left button:    lower terrain by one notch (sea lowest)
          middle button:  raise terrain by one notch
          right button:   toggle between lowest and mid terrain

          c:    create city (growth = 100)
          t:    create town (growth = 80)
          v:    create village (growth = 60)
          k:    increase size of city by 5 percent
          j:    decrease size of city by 5 percent
          s:    scuttle city - remove 36 degrees of arc
          b:    build city - add 36 degrees of arc

          0-9:  create troop marker with troops of current color
          [:    decrease troops by 1
          ]:    increase troops by 1
          r:    increment current color
          f:    change color of existent troop marker
          d:    dump board with name <filename>
          l:    load board with name <filename>
          q:    quit

       With the -edit option, the -overwrite option has a  slightly  different
       function.   Rather than suppress the display of troops, as it does when
       combined with  -load  option,  the  -overwrite  option  causes  default
       terrain  to  be  generated  for editing.  Note that boards created with
       during the edit process are stored in reduced  format,  whereas  boards
       saved  during  game  play are stored in standard format, which includes
       more information about each cell, at the cost of about  15  times  more
       storage space.  Standard format files can also be edited.

INTERACTIVE COMMANDS (MOUSE AND KEYBOARD)

       Movement   commands are  performed with    the left and middle    mouse
       buttons, to direct the  command vector.  A  click in the center of  the
       game  cell  clears  all command vectors; a  click near an edge sets the
       vector in  that direction, and  a  click near a  corner  sets the   two
       adjacent   vectors.   The left mouse toggles  command vectors while the
       middle   mouse clears existing  vectors  and   sets a  new vector   (An
       alternative  command   system  is  available,  see  COMPILATION OPTIONS
       below).  The right mouse is used to repeat the last used command  (with
       -repeat  option).  The keyboard is interpreted differently depending on
       whether the mouse is positioned on  the gameboard or  on the text  area
       below.   On the gameboard,  the the keys control-s and  control-q pause
       and  resume the game respectively.  The  ’z’ key  cancels  all  command
       vectors to the cell containing the  cursor (like a  click in the center
       of the cell).   The key control-p  saves the current  game  to   a  map
       file  (see Saving Game State commands below).  There are also a variety
       of   keyboard commands available  with   different options, to  control
       special  functions on the gameboard.  These keystrokes are described in
       detail with the description of  the  appropriate  options (see   -guns,
       -para,  -build, -scuttle,  -fill, -dig, -reserve).   In the  text  area
       below the keyboard,   the keys control-c and  control-q  both exit  the
       player  from the game, although the game continues among  the remaining
       players until they  also quit, and  the key  control-w also exits   the
       player,  but  allows  him  or  her  to  continue watching  as the other
       players  play  on.   The   rest  of   the  keyboard   is     used   for
       communication   between  participants   through  text   lines.  This is
       especially useful   when playing between remote sites-  each  team  has
       its own text line, and the color of  the text matches the color  of the
       team.  The control-g key rings the bell on all displays, which  can  be
       used  to draw attention to a new message.  All keyboard commands can be
       reconfigured by changing  the  pairings  in  the  keyboard.h  file  and
       recompiling.

BIASED GAMES

       The  game can be biased to favor a less experienced  player, or for any
       other reason, in the following way.  In the normal syntax, the  command
       line  argument "-<color>"  is immediately followed  by  the "<display>"
       argument, for example "-black  me".  It is  possible to define  command
       line   options that are  specific to only  one  display with the syntax
       "-<color> { <options> } <display>" where <options> refers to a list  of
       command  line options as before,  but is included  in  a set of  braces
       between the team color and the display (note the spaces on either  side
       of the braces).  For example,

          xbattle -black { -fight 10 } me -white { -fight 5 } cnsxk

       where  black (on display "me") has the  advantage  of greater firepower
       than white  (on  display "cnsxk").    Not all options can  be   biased,
       specifically  options  that  control  the global behavior of  the game,
       such as -speed, -hex, and -board.  Note also  that  if  you  are  using
       player  specific and global options, the global  options MUST be listed
       first, otherwise they will overwrite the play  specific  options.   For
       example,

          xbattle -black { -fight 10 } me -white cnsxk -fight 5

       will  result in  a fight  5 for both  players.  In order to achieve the
       desired result, the command line must be...

         xbattle  -fight 5 -black { -fight 10 } me -white cnsxk

       where the local option overwrites only the black team’s fight value.

EXTENSIONS

       A great deal of effort  has been made  in the design  of this  game  to
       make   it  as     simple   and   modular as  possible.  Please send any
       interesting variations or extensions to lesher@cns.bu.edu.

EXAMPLES

       Here are some example games to give an idea of  the variability of  the
       parameters.   The  first example is a  simple symmetrical  game between
       "me" in black on my own display, and  a  white opponent on the  display
       "cnsxk:0.0".     The troops will  be   rapidly  exhausted in this small
       skirmish.

          xbattle -black me -white cnsxk:0.0 -armies 4

       The  next example  adds bases,  which  will  produce a much   prolonged
       conflict  involving long supply lines between the front and  the bases,
       much like  desert warfare.  One conflict in  this  battle represents  a
       skirmish    like the entire  game  of  the  previous  example.  In this
       example black is playing on the display cnsxk:0.0, and white is on  the
       system console.  Note that the extension ":0.0" can be omitted.

          xbattle -black cnsxk -white unix -armies 4 -bases 2

       The   next example  is a game  with militia scattered around initially,
       that  have  to race  to  occupy  the  towns  and  link up with    their
       compatriots  before they can eliminate  the enemy.   This is a  dynamic
       scenario requiring tactical and strategic skill and fast reflexes.   In
       this  example black is playing on  cnsxk:0.0  while white is playing on
       the system console of the remote machine thalamus.bu.edu.

          xbattle -black cnsxk -white thalamus.bu.edu -towns 2
                  -militia 2 -hills 7

       Here is a favorite around B.U.   where the land  is broken up  by  many
       bodies   of water creating isolated islands,  and view  of the enemy is
       restricted  to   nearby   cells, resulting   in    lots  of  surprises.
       Paratroops can be   used  for reconnaissance by  launching  them   into
       unknown  sectors, and they  must  be  used  in conjunction with   heavy
       artillery barrages for airborne assaults from one landmass to the next.
       In this example the color display will show cyan and  red teams,  while
       the  monochrome monitor will  show white and black  teams respectively.
       The decay  option prevents huge armies from  building up at the end  of
       the  game, and the -store option is used to store this game to the file
       "xbattle.xba".

          xbattle -cyan_white thalamus:0.0 -red_black cnsxk
                  -rbases 5 -sea 8 -guns 4 -para 4 -horizon 2
                  -decay 3 -store xbattle.xba

       Now, the previous stored game  is  replayed to the original displays by
       repeating  the original command line  except that -store  is changed to
       -replay.   This  is convenient  if  you   have command   line   editing
       facilities.

          xbattle -cyan_white thalamus:0.0 -red_black cnsxk
                  -rbases 5 -sea 8 -guns 4 -para 4 -horizon
                  -replay xbattle.xba

       With  -replay, all arguments are actually  ignored except the displays,
       so you could achieve exactly the same result with the simpler command

          xbattle -black thalamus:0.0 -black cnsxk -replay

       where the   -black   argument  flags  the subsequent  argument    as  a
       displayname,   but  is otherwise  ignored, i.e.  any  color  name would
       suffice.  The filename  for -replay  is omitted,  so that the   default
       file name "xbattle.xba" is used.

       The   next   example   illustrates   the  use  of  the  options   file,
       xbos/tribal.xbo, to set  up a  game  including,   decay,  seas,  farms,
       militia, and many other options.

          xbattle -black me -white thalamus -options xbos/tribal.xbo

       Options  files can also be read in individually for the two players, as
       in the following example...

          xbattle -options game.xbo -black me
                  -white { -options xbos/weak.xbo } thalamus

       This results in a biased game where  both black and white  receive  the
       options   defined   in game.xbo,   and  white   receives  some specific
       handicaps defined in  weak.xbo.   For example, weak.xbo could define  2
       rbases  instead of 5, horizon of 1 instead of 2, and lower movement and
       fighting values.  Since these  options  overwrite existing options   in
       game.xbo,  the command line  arguments   may NOT be typed in  arbitrary
       order.  Global options must  be defined  before they  are   overwritten
       by  the specific options to the white team.

SAMPLE .XBO AND .XBT FILES

       To provide some idea of the range of gameplay available with xbattle, a
       number of option files (.xbo extension) and dump files (.xbt extension)
       are  provided  with  the xbattle 5.4.1 release in the "xbos" and "xbts"
       subdirectories, respectively.  These are listed below, along with  very
       brief descriptions.

          tribal.xbo       mad scramble, every man for himself
          skirmish.xbo         intrigue, espionage, plotting
          demo.xbo         demo which includes ALL options

          atlas.xbo        standard atlas terrain/color scheme
          desert.xbo       mountainous desert terrain/color scheme
          io.xbo           Io-like terrain/color scheme
          space.xbo        space-like terrain/color scheme
          tropical.xbo     tropical islands terrain/color scheme
          tundra.xbo       tundra-like terrain/color scheme

          castle.xbt       moated fortress with villages
          natural.xbt      natural streams, lakes, and hills

PLAYING TIPS

       The  first thing you must learn is to  click quickly and  accurately on
       the game cells.  Do  not focus  your attention  on  one region  of  the
       board,  but scan the whole board frequently.  Look  at the big picture-
       capture the towns that will  support each other,   especially  a   well
       positioned  cluster of big towns.  Eliminate all enemy troops from your
       rear,  and  advance outwards, preferably  from  a corner,  with a  well
       supplied  front.   Travel in convoy  for speed  and  efficiency in safe
       regions, especially if you are playing  with -decay,  but fan out  near
       the  enemy to  provide alternate routes to  a broad front (click on the
       corner to  open  two command  vectors  simultaneously).  Avoid  head-on
       assaults   on the enemy, but rather  dig in and wait  for him to attack
       while you try to turn his flank and cut off his supplies to the  front,
       or  concentrate  at his weakest points.  When advancing, try  to attack
       weak cells with strong ones  to  gain maximum advantage,  and be  alert
       for losing battles of your weak cells pouring into a strong enemy cell,
       which will  drain your resources until  you   cancel   the  attack  and
       build   up  reserves.     If  however   you  are   fighting  a delaying
       action,    or retreating under fire then you should attack strong enemy
       cells with your  weak ones   on a  broad  front to  conserve resources.
       This  is particularly effective with the -disrupt option.   Always  try
       to  attack  a cell  from two or  more sides, and  build  up  sufficient
       strength before launching  an   attack  on   a   strong  cell.   Always
       consider   the  "manufacturing   capacity"  of  the  enemy,  i.e.   the
       number and size of  bases  and  towns,   as  the  one  with   the  most
       capacity   will  eventually  win.     Watch  out  for   single    enemy
       commandos  near your unprotected bases, especially  when  playing  with
       paratroops,   and   use  such  commandos  to  good  effect  against  an
       inattentive opponent.   You  can keep a base fortified  while   sending
       troops  to   the  front   by   use   of recurrent connections, going in
       loops or in both directions,   or  by  establishing  dead-end  branches
       along  the  supply  line   to  accumulate  local  reserves.  You should
       always   have a few strong  reserves  near  your base when playing with
       -horizon  or -para, to ensure  against surprise  attacks.  When playing
       with horizon and paratroops  use the paratroops  to gather intelligence
       from  beyond  the  horizon.  When playing with paratroops or artillery,
       you  can create a network of recurrent   connections   near  the  bases
       that   will   provide protection by  automatically sending troops  into
       parts of  the net that are knocked out.

COMPILATION OPTIONS

       Certain other game options or alternatives are allowed at compile  time
       by  editing the file "constant.h"  and setting certain  global flags to
       FIXED_TRUE or FIXED_FALSE, before compiling  the  program.   The   flag
       FIXED_UNIX  should  be  set to FIXED_FALSE if you will  be running on a
       non-unix platform.  On unix systems the select() function  is  used  to
       enhance efficiency and reduce computer load.  The FIXED_INVERT flag may
       be set to FIXED_FALSE if you do not like the appearance of the inverted
       command  vector  within  the troop cell.  The FIXED_VARMOUSE option may
       be  set  to FIXED_TRUE if  you would like the mouse operations  to   be
       redefined   so   that  the   left  mouse adds  command vectors, and the
       middle mouse subtracts such  vectors.  The flag FIXED_PAUSE may be  set
       to   FIXED_FALSE  to disable the  ability to pause and  resume the game
       with control-s and  control-q.  The FIXED_SHOWFLOW   flag  in  extern.h
       may be set to FIXED_FALSE  to make the displayed command vectors remain
       at full length even  when  the  troop  strength  is  zero.    The  flag
       FIXED_NEWCOLORMAP  can   be set to FIXED_TRUE to create a private color
       map for the game, useful when the default color map is full.  The  flag
       FIXED_MULTITEXT  can  be  set to FIXED_FALSE, whereby instead of having
       a single text line  for  each player,  two  text lines  are  shared  by
       all the  players.  The flag FIXED_MULTIFLUSH  can be set to FIXED_TRUE,
       whereby command vectors appear immediately after the command is  given,
       although performance  is noticeably impaired.  If a   player repeatedly
       "nukes" the   whole     game when he    is  losing,     you  can    set
       FIXED_FATAL_RECOVER  to FIXED_TRUE in constant.h to enable this option.
       User   may  choose between  FIXED_USE_LONGJMP  and  FIXED_USE_PROCEDURE
       methods   if FIXED_FATAL_RECOVER is  set true.   The former uses  the c
       commands setjmp() and longjmp().  The  latter  uses a normal  procedure
       call  to recover.  Recommended use of  LONGJMP.  After 20  fatal errors
       program kicks out, as  a failsafe.  WARNING players  use  FATAL_RECOVER
       at  their  own risk.  If the flag FIXED_TIMER is set set to FIXED_TRUE,
       the elapsed time from game startup will be displayed in the lower  left
       hand  corner of the screen, within the text pane.  If FIXED_UNIX is set
       to FIXED_FALSE, the timer will not work.

BUGS

       When the  system is slow, there  is a noticeable  time lag  between the
       mouse  positioning and the  keystroke registration, so that a keystroke
       for a cell pointed to by the mouse might be actually  recorded  in  the
       next  cell  the  mouse moves to.  Similarly,  a shifted mouse click (as
       for paratroops) might be delayed so that  by the  time it is  processed
       the  shift key is no longer being depressed, and it  is recorded  as an
       unshifted mouse  click (as  for artillery).  Under such  circumstances,
       avoid   issuing   rapid  command  sequences.   Remote play is extremely
       difficult.  When  a  {player  specific   option}  is    followed  by  a
       universal  option,  the former is overwritten  by  the latter,  so  the
       { player specific option } should always follow the  universal  option.

AUTHORS

       Greg Lesher (lesher@cns.bu.edu), Steve  Lehar (slehar@park.bu.edu), and
       some   sections  of code  from  Mark  Lauer (elric@basser.cs.su.oz.au).
       Helpful  suggestions,  bug  reports, and ideas were gratefully received
       from numerous contributors from all over the world.