Provided by: xbattle_5.4.1-15_amd64 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 'p' key.  The cost
       of dropping a number of troops equal to the argument 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.