XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
NAME
xbattle - a multi-user battle strategy game
SYNOPSIS
xbattle [-<color> <display>...] [-<option> <argument>...]
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
- 1 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
-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
- 2 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
-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
- 3 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 4 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 5 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 6 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 7 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 8 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 9 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 10 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
-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
- 11 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
artillery, which can be shot from any occupied game cell. The range
and direction of the shot are determined by the position of the cursor
in the game cell relative to the center of the cell --- near center
for short range and near the edge for long range, as modulated by
the argument <n>. Every shell costs a number of troops from the
source cell equal to the argument of -guns_cost <n> (default: 2), and
destroys a number of troops at the destination cell equal to the
argument of -guns_damage <n> (default: 1). The fall of shot is
indicated by the brief appearance of a little dot of the attacker's
color. With the -horizon option the fall of shot may not be
visible for long range shots, although invisible enemy troops will be
destroyed where the shell falls. Artillery can damage both friend and
foe, so it must be used with caution. Paratroops are enabled by the
option -para <n>, and are launched similarly to artillery using the
of -para_damage <n> (default: 1) at the destination cell is equal to
the argument of -para_cost <n> (default: 3). The drop zone is
indicated by the brief appearance of a parachute symbol. When
used with the -manage option, artillery and paratroops can be
deployed continuously with the 'G' and 'P' keys instead of the 'g' and
'p' keys. This will initiate a continuous barrage that will only
stop when the source cell is exhausted, but will recommence when it
is resupplied. The managed command is indicated by the letters
"GUN" or "PAR" in the source cell, and can be canceled with
either the 'c' key, or by giving the source cell a movement command.
TERRAIN
-hills, -hill_tones, -hill_color,
-peaks, -peak_bias, -trough_bias,
-forest, -forest_tones, -forest_color,
-sea, -sea_block, -sea_tones, -sea_color, -sea_value
The command option -hills <n> initializes random hills which restrict
movement when going from low to high elevation, and enhance movement
from high to low, but do not affect movement on the level. The
elevation is indicated by the shade of gray, light for high and dark
for low on monochrome, and brownish for high and greenish for low on
color displays. The argument controls the amount of energy gained and
lost on hills, i.e. the steepness. Hills provide a tactical advantage
when attacking downhill. With very steep hills (-hills 9) movement
from very low to very high elevation (a cliff) is virtually
impossible. The number of discrete elevation levels is set via the
-hill_tones <n> option. On color monitors, the hill hues can be
tailored via the -hill_color <n> <red> <green> <blue>, where <n>
specifies the elevation index (from 0 to hill_tones-1) to be changed
to the RGB triplet. The color of unspecified elevation indices are
linearly interpolated based on specified indices.
The command option -forest <n> initializes random forests which
restrict movement within the forest, but do not affect movement from
thin to thick forest. On both color and monochrome displays, thick
- 12 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 13 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 14 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 15 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 16 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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,
- 17 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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.
- 18 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 19 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 20 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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
- 21 - Formatted: October 18, 2024
XBATTLE(5.4.1) XBATTLE(5.4.1)
December 1995
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.
- 22 - Formatted: October 18, 2024
