XBATTLE(5.4.1) XBATTLE(5.4.1)
NAMExbattle - a multi-user battle strategy game
SYNOPSISxbattle [-<color> <display>...] [-<option> <argument>...]
DESCRIPTION
Assign a team color and display to each player, and any number of
options with argument where required. <color> can be a monochrome
tone, -black-white -dark -light, or a color, -red -green -blue ;
<display> is the name of the x display for each player. Command line
arguments can be supplied in any order. For a quick introduction, go
straight to the EXAMPLES section below. Also, see the tutorials
supplied with the game, which are "csh" shell scripts that start up
example games.
OPTIONS
USAGE: xbattle <args>
-<c1> <str> color to display name <str>
-<c1>_<c2> <str> colors to display name <str>
-area troops proportional to area
-attack allow use of attack key
-armies <int> number of ordered armies
-basemap use map scheme, bases visible
-bases <int> number of ordered bases
-board <int> size of board (in cells, x=y)
-boardx <int> width of board (in cells)
-boardy <int> height of board (in cells)
-border <int> border around board
-bound allow drag-bounded vector sets
-build <int> build cities with <int> segments
-build_cost <int> cost to build city segment
-build_limit <int> limit cities each side can build
-color <spec> set RGB values for color <str>
-color_inverse <spec> set color <s1> inverse to <s2>
-decay <int> make troops slowly die off
-diamond use diamond tiling
-dig [int] [int] step terrain lowering
-dig_cost <int> cost of each dig step
-digin <int> provide entrenchment
-disrupt attacks break supply lines
-draw <int> specify a troop drawing method
-dump <file> dump configuration to <file>
-edit [file] interactively edit xbattle board
-erode make unused paths erode
-erode_thresh <int> threshold for erosion
-farms <int> troops slowly grow
-fight <int> intensity of fighting
-fill [int] [int] step terrain raising
-fill_cost <int> cost of each fill step
-forest <int> density of forest
-forest_color <spec> RGB values for forest level
-forest_tones <int> number of forest levels
-grid show grid
-guns <int> range of artillery
-guns_cost <int> cost of each artillery shell
-guns_damage <int> damage done by artillery shell
-help print argument list
-hex use hexagonal tiling
-hidden invisible enemy vectors
-hills <int> slope of hills
-hill_color <spec> RGB values for hill level <int>
-hill_tones <int> number of allowable hill levels
-horizon [int] can't see enemy past [int] cells
-load [file] load board from [file]
-localmap mapping with invisible terrain
-manage managed control of commands
-manpos manual positioning of board
-map use basic map scheme
-march <int> number of delays between marches
-maxval <int> maximum cell troop capacity
-militia <int> randomly distributed troops
-move <int> speed of troop flow
-nospigot [int] cease attack if outnumbered
-octagon use octagonal/square tiling
-options <file> read xbattle options from <file>
-opt_file.xbo shorthand -options opt_file.xbo
-overwrite just use terrain from load file
-para <int> range of paratroopers
-para_cost <int> cost of each paratrooper
-para_damage <int> invading strength of paratrooper
-peaks <int> number of terrain peaks
-peak_bias <float> peak distribution bias (0.0-2.0)
-rbases <int> number of distributed bases
-rbase_range <int> distance of rbase from enemy
-repeat repeat of last mouse command
-replay [file] replay stored game from [file]
-reserve allow reserve of troops
-scuttle [int] enable city scuttling
-scuttle_cost <int> cost of scuttle
-sea <int> pervasiveness (+ levels) of sea
-sea_block use block-fills, not hue-fills
-sea_color <spec> RGB values for sea level <int>
-sea_tones <int> number of allowable sea levels
-sea_value <float> darkness of seas for b/w games
-seed <int> random number generator seed
-speed <int> speed of updates
-square <int> side length of cell
-stipple <spec> set stipple (b/w) pattern
-store [file] store game for later replay
-towns <int> density of distributed towns
-triangle use triangular tiling
-trough_bias <float> trough setting bias (0.0-2.0)
-xpos <int> x position of board on display
-ypos <int> y position of board on display
-wrap wrapping around edges of board
RUN-TIME COMMAND SUMMARY
COMMANDS IN GAMEBOARD
LFT MOUSE: toggle command vector
MID MOUSE: clear and set new command vector
RGT MOUSE: repeat previous command (-repeat)
SHIFT-LFT MOUSE: march (-march) fork move (else)
SHIFT-MID MOUSE: force march (-march) fork move (else)
SHIFT-RGT MOUSE: paratroops (-para)
CTRL-RGT MOUSE: artillery (-guns)
CRTL-'s': pause game
CRTL-'q': resume game
CRTL-'p': save game state to map file
'a': attack enemy square (-attack)
'b': build base (-build)
'B': build full base (-build & -manage)
's': scuttle base (-scuttle)
'f': fill terrain (-fill)
'F': fill full terrain (-fill & -manage)
'd': dig terrain (-dig)
'D': dig full terrain (-dig & -manage)
'p': paratroops (-para)
'P': paratroops - on (-para & -manage)
'g': artillery (-guns)
'G': artillery - on (-guns & -manage)
'z': cancel all movement
'c': cancel managed operation (-manage)
'0'-'9': reserve (-reserve)
COMMANDS IN TEXT AREA
CONTROL-c: quit the game
CONTROL-w: quit game but watch others play on
CONTROL-g: ring bell on all game displays
CONTROL-p: dump the current game state
OTHER CHARACTER: append to message string
DESCRIPTIONxbattle is a concurrent multi-player battle strategy game that
captures the dynamics of a wide range of military situations. The
game board is a matrix of game cells (such as squares or hexes) which
can be occupied by troops of various colors or shades. The number
of troops in a cell is indicated by the size of a colored troop circle
(or square) within that cell. The troops are commanded by clicking
the mouse near the edge of the cell in the direction that the movement
is to take place. The command will be acknowledged by the appearance
of a movement vector, and thereafter, in each update cycle, a certain
proportion of the troops will move from the source cell to the des‐
tination 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 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", "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 (.xbat‐
tle), 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 compo‐
nents 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, allow‐
ing monochrome players to have six distinguishable team colors. A
number of people can be assigned to the same team by repeat‐
ing the color for different displays, for example "-red display1 -red
display2", and each member of the team will be able to command any
troops of that team. The <display> argument designates the name
of the display on which the team of that color is playing, so each
player must be given a color and a display. Display names can be
found with the unix command "who", which will list display names for
users in the last column like (cnsxk:0.0). The system console is
always designated unix:0.0. The display name can be modified for
remote games, for example the terminal cnsxk:0.0 on park.bu.edu
(email address of machine "park") is designated cnsxk.bu.edu:0.0 .
XBattle recognizes :0.0 as the default (screen zero on the display),
so the :0.0 may be omitted from the display name. XBattle also
recognizes a special display name "me", which means the display from
which the program is started. When playing between color and
monochrome displays the colors can be specified more exactly by
concatenating a color name with a monochrome name, for example
"-red_white" (color first), which would display that team as red on
color monitors and white on monochrome monitors. All command line
flags and arguments for the game can be given in any order as
long as the argument directly follows its flag, and most arguments
are scaled to range from 1 to 10, with 5 being the default value. It
is also possible to set different game parameters for the different
displays, so that the game can be biased to favor a less experienced
player (see BIASED GAMES below).
OPTIONS-options
A large number of command line options are available to define the
parameters of the game. In essence, xbattle is many thousands of
games rolled into one. The options can be presented in any order, and
may be typed in with the command line, or they can be stored in an
options file (default filename = default.xbo), or some can be stored
and others added to the command line. The format for the options file
is exactly the same as the format for the command line except that in
the file each option (plus argument, where applicable) is placed on a
separate line. So, for example, the game...
xbattle-black me -white cnsxk:0.0 -armies 4 -farms 5
-attack
could also be played with the command...
xbattle-black me -white cnsxk:0.0 -options myoptions.xbo
or alternatively with the shorthand version...
xbattle-black me -white cnsxk:0.0 -myoptions.xbo
where the file myoptions.xbo consists of the lines...
-armies 4
-farms 5
-attack
If the specified options file cannot be found in the current directory,
xbattle will search the default xbo directory DEFAULT_XBO_DIR, which
can be specified at compile time in the makefile.
XBattle checks for the presence of the default file ~/.xbattle, in
which options can be set in advance, saving the trouble of having
to set them at run time or include an options files. The default file
is typically used to set up commands which are used in nearly every
game at a particular site. Thus a typical default file might contain
color (and black and white) definitions, cell size, artillery damage,
and the like. Option files, on the other hand, are typically used to
define specific scenarios involving unique combinations of command line
arguments. Conflicting commands in the default and options file are
resolved in favor of the options file.
TROOPS-bases, -rbases, -rbase_range, -armies, -militia
Initial troop allocation is controlled by several command options,
including -bases <n>, -rbases <n>, -armies <n> and -militia <n>.
Armies and militia are troops on the gameboard, whereas bases which
are indicated by circles on the gameboard, provide a steady supply of
troops. The -bases option allocates <n> bases to each team,
symmetrically arranged on the game board, whereas -rbases <n> arranges
them randomly (which works well with the -horizon option). The
minimum distance between enemy bases (in cells) can optionally be set
using the -rbase_range <n> command. Note that large values of <n> may
not allow any valid rbase allocation, in which case xbattle will exit
with an error message. The -armies option allocates <n> armies (full
troop cells) symmetrically arrayed, whereas -militia <n> scatters mili‐
tia of random strengths to random locations, with a probabilistic den‐
sity of <n>. At least one of these four options is required to pro‐
vide initial troops for the game, and they may be used in arbitrary
combinations.
RESUPPLY-towns, -farms, -decay, -erode, -erode_thresh
The bases created by the -bases or -rbases produce a steady supply of
fresh troops. The bases can be occupied by an opposing team, with the
troops produced by such bases are always the color of the occupying
force. The capture of all bases thus becomes the strategic objective
of the game. This arrangement simulates desert warfare, as long and
tenuous supply lines develop between the base and the battle areas.
Another form of resupply is provided by the command option "-towns
<n>". This produces a number of smaller unoccupied supply sources
scattered randomly over the game board at a density determined by the
argument <n>, and with random rates of troop production, indicated by
the radius of the circle on the game board. Towns must be occupied by
a team to begin producing troops. This option simulates yet a larger
scale of operation as the combatants battle to occupy the towns. A
more distributed form of resupply is evoked by the command option
"-farms <n>" whereby every cell of the game board will produce
troops as soon as it is occupied, at a rate proportional to the
argument <n>, and the strategic objective becomes the occupation of
the largest areas of the gameboard. This option simulates a yet
larger scale of operation and requires complex management of resources
to concentrate the distributed resources and deliver them to the
battle front. In large scale scenarios additional realism may be
added by using the "-decay <n>" option whereby the troop strength in
all troop cells decays constantly in proportion to the value of
the decay argument. This reflects the fact that armies constantly con‐
sume resources even while they are idle, and an army without con‐
stant 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 probabil‐
ity 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 sup‐
ported in biased games - i.e. it can be set for one team but not
another. Commands can be made to apply to more than one cell with
the option "-bound". This is achieved by defining a bounding rectangle
within which the command is valid. For instance, to command a block
of cells to all move up simultaneously, you place your mouse near
the top edge of a cell (may be unoccupied, or enemy occupied) and
press the button (setting the command "go up", then you drag the mouse
to another game cell where you release the button. The start and
end cells of the mouse drag define the opposite corners of a
rectangle within which all the game cells occupied by your troops
receive the command "go up". The "-attack" option makes quick, multi‐
ple front attacks possible. By issuing an "a" command in an enemy
cell, all adjacent friendly troops will automatically alter their move‐
ment 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 march‐
ing 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 encoun‐
tered 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 visi‐
ble horizon in the normal way , and will appear as a double vector in
that cell so long as that cell is not a "sea" cell. If the target
cell contains invisible enemy troops, then the march command vectors
will appear initially, but disappear again as soon as the enemy is
approached close enough to be visible. March commands are specific to
the team that sets them, and different march commands may be set by
different teams in the same game cell. The double command vectors
are visible only to the team that sets them.
GAME PLAY-fight, -speed, -move, -seed,
-digin, -nospigot, -disrupt, -maxval
Whenever troops of different colors occupy the same game cell, a
battle ensues, indicated by concentric markers of the two colors, and
a "crossed swords" (X) symbol. During battle, one or both sides can
incur losses according to a random nonlinear function that
disproportionately favors the more numerous troops. The steepness of
the nonlinearity, i.e. the advantage given to the more numerous side,
is controlled by the -fight parameter. A small value will produce
lengthy drawn out battles which favor a defensive strategy, whereas a
large value produces quick decisive battles where the random element
is more significant, favoring an offensive strategy even against
superior odds. In the absence of the -fight option, the default value
of 5 is used. The -fight parameter is also automatically modulated by
the game speed parameter (-speed) in order to slow down battles in
fast games and vice versa. Since only 1/3 of the troops can enter a
cell in each update cycle (with the default -move 5), attackers of a
full cell are always outnumbered initially, unless a coordinated
attack is launched from three sides simultaneously. The -move
argument thus has a significant influence on the efficacy of an
attack. The -disrupt option dictates that when a game cell comes
under attack, all its command vectors are immediately canceled,
breaking supply lines which must be repaired by hand after the attack.
In other words, there can be no movement under fire, and even small
forces can be used to provide covering fire to "pin down" a larger
force, at least until they are counter-attacked and eliminated. A
side effect of this option is that when an attacking cell is
counterattacked, both cells attempt to cancel each other's movement,
i.e. to interrupt the attack. The cell that is updated next will
prevail, canceling the command vector of the other cell. Since the
game cells are updated in a random sequence, there is no telling
which cell will prevail, and the commander must click repeatedly to
renew the command vector in order to press home the attack under
opposition. This simulates the tactical situation where a commander
must personally intervene to ensure the maximal effort is applied at
the most critical points of the battle. The "-seed <n>" option sim‐
ply sets the seed of the random number generator to <n>, which is use‐
ful 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 frac‐
tion 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> 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 estab‐
lished 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 rectangu‐
lar 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 orien‐
tations of equilateral triangles is invoked with the -triangle option.
The -octagon option results in a tiling consisting of a combination of
regular octagons and small squares. Since different cell shapes have
different neighborhoods, troop movement in the different tilings can
have a very different feel, and may take some getting used to.
DRAWING METHODS-draw
The method of drawing and erasing troops and terrain is defined via the
-draw <n> option, where the argument indicates one of five distinct
techniques, of varying speed and flicker. They are: Method 0: Erase
the cell by drawing a circle the color of the terrain, then redraw the
cell contents. This is the method employed in xbattle versions before
5.3. Although simple and fast, the onscreen erasing and redrawing
often results in annoying flicker. METHOD 1: Erase and redraw cells as
for method 0, but do the whole process on a backing store pixmap, then
copy the cell to the window. The copy from the pixmap to the window
adds some overhead, but flicker is completely eliminated. METHOD 2:
Copy a blank cell from pixmap storage to a working pixmap, draw the
cell contents, then copy the cell to the window. This method exchanges
the cell erase of method 1 for a pixmap-to-pixmap copy operation to
also provide flicker-free game animation. Unfortunately this method
only works for square tilings, since only rectangular cells can be per‐
fectly 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 reason‐
ably good results since the cell erases often never appear on the
screen before the cell redraw.
GUNS AND PARATROOPS-guns, -guns_damage, -guns_cost,
-para, -para_damage, -para_cost,
-manage
The command option -guns <n> enables the key 'g' to be used to control
artillery, which can be shot from any occupied game cell. The range
and direction of the shot are determined by the position of the cursor
in the game cell relative to the center of the cell --- near center for
short range and near the edge for long range, as modulated by the
argument <n>. Every shell costs a number of troops from the source
cell equal to the argument of -guns_cost <n> (default: 2), and destroys
a number of troops at the destination cell equal to the argument of
-guns_damage <n> (default: 1). The fall of shot is indicated by the
brief appearance of a little dot of the attacker's color. With the
-horizon option the fall of shot may not be visible for long range
shots, although invisible enemy troops will be destroyed where the
shell falls. Artillery can damage both friend and foe, so it must be
used with caution. Paratroops are enabled by the option -para <n>,
and are launched similarly to artillery using the of -para_damage <n>
(default: 1) at the destination cell is equal to the argument of
-para_cost <n> (default: 3). The drop zone is indicated by the brief
appearance of a parachute symbol. When used with the -manage
option, artillery and paratroops can be deployed continuously with the
'G' and 'P' keys instead of the 'g' and 'p' keys. This will initiate
a continuous barrage that will only stop when the source cell is
exhausted, but will recommence when it is resupplied. The managed
command is indicated by the letters "GUN" or "PAR" in the source
cell, and can be canceled with either the 'c' key, or by giving the
source cell a movement command.
TERRAIN-hills, -hill_tones, -hill_color,
-peaks, -peak_bias, -trough_bias,
-forest, -forest_tones, -forest_color,
-sea, -sea_block, -sea_tones, -sea_color, -sea_value
The command option -hills <n> initializes random hills which restrict
movement when going from low to high elevation, and enhance movement
from high to low, but do not affect movement on the level. The
elevation is indicated by the shade of gray, light for high and dark
for low on monochrome, and brownish for high and greenish for low on
color displays. The argument controls the amount of energy gained and
lost on hills, i.e. the steepness. Hills provide a tactical advantage
when attacking downhill. With very steep hills (-hills 9) movement
from very low to very high elevation (a cliff) is virtually
impossible. The number of discrete elevation levels is set via the
-hill_tones <n> option. On color monitors, the hill hues can be tai‐
lored 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 con‐
junction 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 eleva‐
tion, the elevation of the rest of the game cells is determined via a
non-linear interpolation process. The -peak_bias <float> option deter‐
mines 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. Sim‐
ilarly, 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 opera‐
tions (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 vec‐
tor 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, dis‐
played 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 pre‐
vent it falling into enemy hands. Scuttling is performed by
positioning the mouse on the base and pressing the "s" key. If the
build option is not enabled, this reduces the size (and production
capacity) of that base by one scuttle unit for each scuttle_cost of
troops expended, where a scuttle unit is defined by the argument of the
scuttle option (default: 5). Usually, several keystrokes are required
to complete the destruction. When used in conjunction with the
-build option, instead of reducing the size of the base, each
scuttle operation removes a section (arc segment) of the base, at a
troop cost indicated by the -scuttle_cost <n> option. A base will
not produce troops if even a single segment is missing, although of
course it is less expensive to repair (with "b" build) a base with
fewer segments missing.
As with -guns and -para, the -dig, -fill, and -build options (but not
the -scuttle option) can be "managed" with the -manage option, which
allows a player to issue a single command to initiate a sequence of
repeated dig, fill, or build operations using the keys 'D', 'F', and
'B' respectively. The managed operation will continue until the task
is done, as long as the cell is resupplied. The managed operation
will be indicated by the letters "DIG", "FIL" or "BLD" respectively in
the managed cell. Managed operation can be canceled with the 'c'
key, or by issuing a movement command to the cell.
VISIBILITY-horizon, -hidden, -map, -basemap, -localmap
The command option -horizon [n] restricts the view of enemy troop
deployment to within <n> cells of any friendly troops. Horizon can be
called with no argument, in which case the default <n> = 2 is used.
Intelligence of more remote regions can be gathered by use of
paratroops. The command option -hidden (no arguments) makes the
command vectors of the enemy invisible at any range. The command
option -map is similar to -horizon except that it restricts your view
of geographical objects as well as enemy troops, although it will
"remember" any terrain that you have seen once, as if you had mapped
that information. The -basemap option maps bases and towns as it does
the terrain --- once you see them, they're remembered. The option
-localmap maps only the local area around your troops, and features
disappear as you move away again.
STORE AND REPLAY-store, -replay
The -store <file> option allows you to store enough information
about the visual progress of the game to reconstruct it later with
-replay <file> option. When -replay is used, all other command
options are ignored except the -<color> <display> options, which can be
used to send the replay to other displays. When doing so, only the
<display> portion of the option is used, the <color> is ignored. So,
if you play a game with many command line parameters and several
displays with the argument -store <file>, after the game you can
repeat the same command line but just change -store to -replay, and the
game will be replayed on the displays of all the original combat‐
ants. 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 speci‐
fied load file cannot be found in the current directory, xbattle will
search the default xbt directory DEFAULT_XBT_DIR, which can be speci‐
fied at compile time in the makefile. Note that most game parameters
ARE NOT STORED. Only terrain features (forest, hills, seas, towns
etc.) and troop deployment. This means that if you were playing with
-farms, -decay, and -guns then you will have to type them in if you
want them for the new game. The terrain and boardsize of the saved
map file will override all terrain and boardsize arguments when
loaded. Troop and town/base producing options (such as -militia,
-towns, and -rbases) will add new features on top of the loaded game
state. If the -overwrite option is issued, only the terrain and cities
from the loaded game will be used --- no troops will appear. This is
useful for repeating games with interesting terrains with different
troop configurations.
Game boards can be created or modified with the -edit function,
which is called with the command option "-edit <file>" where <file> is
optional if the file name is "xbattle.xbt". With this option, no
game is played, but instead, the mouse and key commands control the
features of the map to be edited. To edit an existing file, use
"-edit <file>" and type "l" when the editor comes up. This will load
the file named in the edit argument. To save that file, type "d"
and the file will be saved to the same file name. No provision
is made for saving to a different file name. When using the edit
mode, the command line arguments must reflect the number and color
of players to be used, and the sea, forest or hills options if they
will be required. For example, to create a map called
"mymap.xbt" with three color teams and seas, could use the command
"xbattle -edit mymap.xbt -sea 7 -white me -black you -dark you". Note
the use of the special display "you", which is a dummy display name
used as a place holder for the black and dark colors. The interactive
commands are as follows:
left button: lower terrain by one notch (sea lowest)
middle button: raise terrain by one notch
right button: toggle between lowest and mid terrain
c: create city (growth = 100)
t: create town (growth = 80)
v: create village (growth = 60)
k: increase size of city by 5 percent
j: decrease size of city by 5 percent
s: scuttle city - remove 36 degrees of arc
b: build city - add 36 degrees of arc
0-9: create troop marker with troops of current color
[: decrease troops by 1
]: increase troops by 1
r: increment current color
f: change color of existent troop marker
d: dump board with name <filename>
l: load board with name <filename>
q: quit
With the -edit option, the -overwrite option has a slightly different
function. Rather than suppress the display of troops, as it does when
combined with -load option, the -overwrite option causes default ter‐
rain to be generated for editing. Note that boards created with during
the edit process are stored in reduced format, whereas boards saved
during game play are stored in standard format, which includes more
information about each cell, at the cost of about 15 times more storage
space. Standard format files can also be edited.
INTERACTIVE COMMANDS (MOUSE AND KEYBOARD)
Movement commands are performed with the left and middle mouse
buttons, to direct the command vector. A click in the center of the
game cell clears all command vectors; a click near an edge sets the
vector in that direction, and a click near a corner sets the two
adjacent vectors. The left mouse toggles command vectors while the
middle mouse clears existing vectors and sets a new vector (An
alternative command system is available, see COMPILATION OPTIONS
below). The right mouse is used to repeat the last used command (with
-repeat option). The keyboard is interpreted differently depending on
whether the mouse is positioned on the gameboard or on the text area
below. On the gameboard, the the keys control-s and control-q pause
and resume the game respectively. The 'z' key cancels all command
vectors to the cell containing the cursor (like a click in the center
of the cell). The key control-p saves the current game to a map
file (see Saving Game State commands below). There are also a variety
of keyboard commands available with different options, to control
special functions on the gameboard. These keystrokes are described in
detail with the description of the appropriate options (see -guns,
-para, -build, -scuttle, -fill, -dig, -reserve). In the text area
below the keyboard, the keys control-c and control-q both exit the
player from the game, although the game continues among the remaining
players until they also quit, and the key control-w also exits the
player, but allows him or her to continue watching as the other play‐
ers 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 chang‐
ing the pairings in the keyboard.h file and recompiling.
BIASED GAMES
The game can be biased to favor a less experienced player, or for any
other reason, in the following way. In the normal syntax, the command
line argument "-<color>" is immediately followed by the "<display>"
argument, for example "-black me". It is possible to define command
line options that are specific to only one display with the syntax
"-<color> { <options> } <display>" where <options> refers to a list of
command line options as before, but is included in a set of braces
between the team color and the display (note the spaces on either side
of the braces). For example,
xbattle-black { -fight 10 } me -white { -fight 5 } cnsxk
where black (on display "me") has the advantage of greater firepower
than white (on display "cnsxk"). Not all options can be biased,
specifically options that control the global behavior of the game,
such as -speed, -hex, and -board. Note also that if you are using
player specific and global options, the global options MUST be listed
first, otherwise they will overwrite the play specific options. For
example,
xbattle-black { -fight 10 } me -white cnsxk -fight 5
will result in a fight 5 for both players. In order to achieve the
desired result, the command line must be...
xbattle-fight 5 -black { -fight 10 } me -white cnsxk
where the local option overwrites only the black team's fight value.
EXTENSIONS
A great deal of effort has been made in the design of this game to
make it as simple and modular as possible. Please send any
interesting variations or extensions to lesher@cns.bu.edu.
EXAMPLES
Here are some example games to give an idea of the variability of the
parameters. The first example is a simple symmetrical game between
"me" in black on my own display, and a white opponent on the display
"cnsxk:0.0". The troops will be rapidly exhausted in this small
skirmish.
xbattle-black me -white cnsxk:0.0 -armies 4
The next example adds bases, which will produce a much prolonged
conflict involving long supply lines between the front and the bases,
much like desert warfare. One conflict in this battle represents a
skirmish like the entire game of the previous example. In this
example black is playing on the display cnsxk:0.0, and white is on the
system console. Note that the extension ":0.0" can be omitted.
xbattle-black cnsxk -white unix -armies 4 -bases 2
The next example is a game with militia scattered around initially,
that have to race to occupy the towns and link up with their
compatriots before they can eliminate the enemy. This is a dynamic
scenario requiring tactical and strategic skill and fast reflexes. In
this example black is playing on cnsxk:0.0 while white is playing on
the system console of the remote machine thalamus.bu.edu.
xbattle-black cnsxk -white thalamus.bu.edu -towns 2
-militia 2 -hills 7
Here is a favorite around B.U. where the land is broken up by many
bodies of water creating isolated islands, and view of the enemy is
restricted to nearby cells, resulting in lots of surprises.
Paratroops can be used for reconnaissance by launching them into
unknown sectors, and they must be used in conjunction with heavy
artillery barrages for airborne assaults from one landmass to the next.
In this example the color display will show cyan and red teams, while
the monochrome monitor will show white and black teams respectively.
The decay option prevents huge armies from building up at the end of
the game, and the -store option is used to store this game to the file
"xbattle.xba".
xbattle-cyan_white thalamus:0.0 -red_black cnsxk
-rbases 5 -sea 8 -guns 4 -para 4 -horizon 2
-decay 3 -store xbattle.xba
Now, the previous stored game is replayed to the original displays by
repeating the original command line except that -store is changed to
-replay. This is convenient if you have command line editing
facilities.
xbattle-cyan_white thalamus:0.0 -red_black cnsxk
-rbases 5 -sea 8 -guns 4 -para 4 -horizon
-replay xbattle.xba
With -replay, all arguments are actually ignored except the displays,
so you could achieve exactly the same result with the simpler command
xbattle-black thalamus:0.0 -black cnsxk -replay
where the -black argument flags the subsequent argument as a
displayname, but is otherwise ignored, i.e. any color name would
suffice. The filename for -replay is omitted, so that the default
file name "xbattle.xba" is used.
The next example illustrates the use of the options file,
xbos/tribal.xbo, to set up a game including, decay, seas, farms,
militia, and many other options.
xbattle-black me -white thalamus -options xbos/tribal.xbo
Options files can also be read in individually for the two players, as
in the following example...
xbattle-options game.xbo -black me
-white { -options xbos/weak.xbo } thalamus
This results in a biased game where both black and white receive the
options defined in game.xbo, and white receives some specific
handicaps defined in weak.xbo. For example, weak.xbo could define 2
rbases instead of 5, horizon of 1 instead of 2, and lower movement and
fighting values. Since these options overwrite existing options in
game.xbo, the command line arguments may NOT be typed in arbitrary
order. Global options must be defined before they are overwritten
by the specific options to the white team.
SAMPLE .XBO AND .XBT FILES
To provide some idea of the range of gameplay available with xbattle, a
number of option files (.xbo extension) and dump files (.xbt extension)
are provided with the xbattle 5.4.1 release in the "xbos" and "xbts"
subdirectories, respectively. These are listed below, along with very
brief descriptions.
tribal.xbo mad scramble, every man for himself
skirmish.xbo intrigue, espionage, plotting
demo.xbo demo which includes ALL options
atlas.xbo standard atlas terrain/color scheme
desert.xbo mountainous desert terrain/color scheme
io.xbo Io-like terrain/color scheme
space.xbo space-like terrain/color scheme
tropical.xbo tropical islands terrain/color scheme
tundra.xbo tundra-like terrain/color scheme
castle.xbt moated fortress with villages
natural.xbt natural streams, lakes, and hills
PLAYING TIPS
The first thing you must learn is to click quickly and accurately on
the game cells. Do not focus your attention on one region of the
board, but scan the whole board frequently. Look at the big picture-
capture the towns that will support each other, especially a well
positioned cluster of big towns. Eliminate all enemy troops from your
rear, and advance outwards, preferably from a corner, with a well
supplied front. Travel in convoy for speed and efficiency in safe
regions, especially if you are playing with -decay, but fan out near
the enemy to provide alternate routes to a broad front (click on the
corner to open two command vectors simultaneously). Avoid head-on
assaults on the enemy, but rather dig in and wait for him to attack
while you try to turn his flank and cut off his supplies to the front,
or concentrate at his weakest points. When advancing, try to attack
weak cells with strong ones to gain maximum advantage, and be alert
for losing battles of your weak cells pouring into a strong enemy cell,
which will drain your resources until you cancel the attack and
build up reserves. If however you are fighting a delaying
action, or retreating under fire then you should attack strong enemy
cells with your weak ones on a broad front to conserve resources.
This is particularly effective with the -disrupt option. Always try
to attack a cell from two or more sides, and build up sufficient
strength before launching an attack on a strong cell. Always con‐
sider 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 sur‐
prise attacks. When playing with horizon and paratroops use the
paratroops to gather intelligence from beyond the horizon. When play‐
ing with paratroops or artillery, you can create a network of recur‐
rent connections near the bases that will provide protection by
automatically sending troops into parts of the net that are knocked
out.
COMPILATION OPTIONS
Certain other game options or alternatives are allowed at compile time
by editing the file "constant.h" and setting certain global flags to
FIXED_TRUE or FIXED_FALSE, before compiling the program. The flag
FIXED_UNIX should be set to FIXED_FALSE if you will be running on a
non-unix platform. On unix systems the select() function is used to
enhance efficiency and reduce computer load. The FIXED_INVERT flag may
be set to FIXED_FALSE if you do not like the appearance of the inverted
command vector within the troop cell. The FIXED_VARMOUSE option may
be set to FIXED_TRUE if you would like the mouse operations to be
redefined so that the left mouse adds command vectors, and the
middle mouse subtracts such vectors. The flag FIXED_PAUSE may be set
to FIXED_FALSE to disable the ability to pause and resume the game
with control-s and control-q. The FIXED_SHOWFLOW flag in extern.h
may be set to FIXED_FALSE to make the displayed command vectors remain
at full length even when the troop strength is zero. The flag
FIXED_NEWCOLORMAP can be set to FIXED_TRUE to create a private color
map for the game, useful when the default color map is full. The flag
FIXED_MULTITEXT can be set to FIXED_FALSE, whereby instead of having
a single text line for each player, two text lines are shared by
all the players. The flag FIXED_MULTIFLUSH can be set to FIXED_TRUE,
whereby command vectors appear immediately after the command is given,
although performance is noticeably impaired. If a player repeatedly
"nukes" the whole game when he is losing, you can set
FIXED_FATAL_RECOVER to FIXED_TRUE in constant.h to enable this option.
User may choose between FIXED_USE_LONGJMP and FIXED_USE_PROCEDURE
methods if FIXED_FATAL_RECOVER is set true. The former uses the c
commands setjmp() and longjmp(). The latter uses a normal procedure
call to recover. Recommended use of LONGJMP. After 20 fatal errors
program kicks out, as a failsafe. WARNING players use FATAL_RECOVER
at their own risk. If the flag FIXED_TIMER is set set to FIXED_TRUE,
the elapsed time from game startup will be displayed in the lower left
hand corner of the screen, within the text pane. If FIXED_UNIX is set
to FIXED_FALSE, the timer will not work.
BUGS
When the system is slow, there is a noticeable time lag between the
mouse positioning and the keystroke registration, so that a keystroke
for a cell pointed to by the mouse might be actually recorded in the
next cell the mouse moves to. Similarly, a shifted mouse click (as
for paratroops) might be delayed so that by the time it is processed
the shift key is no longer being depressed, and it is recorded as an
unshifted mouse click (as for artillery). Under such circumstances,
avoid issuing rapid command sequences. Remote play is extremely
difficult. When a {player specific option} is followed by a univer‐
sal 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.
December 1995 XBATTLE(5.4.1)
