Go Back    


Debian 7.7 - man page for xbattle (debian section 6)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


XBATTLE(6)									       XBATTLE(6)

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 argu-
       ment 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 dynam-
       ics   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 des-
       tination  cell until  the  source cell is exhausted.  Movement vectors can be set in  sev-
       eral  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 end-
       point.	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",  "Misty-
       Rose",  "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  distin-
       guishable  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  omit-
       ted 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  com-
       mand 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 parame-
       ters  for the different	displays, so that the game  can be biased  to favor a  less expe-
       rienced 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 val-
       ues  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)	symmetri-
       cally  arrayed,	whereas -militia <n> scatters militia of random strengths to random loca-
       tions, 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 com-
       binations.

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  combat-
       ants 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 con-
       stantly	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  deter-
       mined 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 click-
       ing 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  simul-
       taneously,  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% capac-
       ity, 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 strategi-
       cally 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  direc-
       tion  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 exist-
       ing  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,  indi-
       cated  by concentric markers of	the two colors, and a  "crossed swords" (X) symbol.  Dur-
       ing  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 ran-
       dom  element  is more  significant,  favoring an  offensive   strategy  even against supe-
       rior 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 sup-
       ply 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   situa-
       tion 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 max-
       vals.

       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> respec-
       tively.	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 annoy-
       ing  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 fab-
       ulously 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  anima-
       tion.   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 deter-
       mined 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 destina-
       tion 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  resup-
       plied.	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  -for-
       est_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 tac-
       tical 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    para-
       troops.	On monochrome	monitors  water appears dark mottled grey,  and  on color   moni-
       tors  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 shal-
       lowest 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 ele-
       vations 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  pro-
       duce  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  let-
       ters  "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  "xbat-
       tle.xbt".   With this option,  no game is played, but  instead, the mouse  and	key  com-
       mands  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 play-
       ers 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 mid-
       dle   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  differ-
       ently  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  appro-
       priate  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  commu-
       nication   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 immedi-
       ately  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    sim-
       ple   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  con-
       flict  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  fre-
       quently.   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  play-
       ing   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 direc-
       tions,  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 com-
       piling 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.

5.4.1					  December 1995 			       XBATTLE(6)
Unix & Linux Commands & Man Pages : ©2000 - 2017 Unix and Linux Forums


All times are GMT -4. The time now is 09:08 AM.