@node Playing Xconq, , Xconq, Top

@chapter Playing Xconq

This chapter is about how to play @i{Xconq}.  Although @i{Xconq}
supports a wide variety of games, they all have much in common, and it
is these common features that will be described here.  This chapter,
along with any documentation for the game you're playing, should provide
all the information you need to play and enjoy @i{Xconq}.

The term @dfn{interface} refers to the particular graphical user
interface in use.  Examples include X11, curses, and Macintosh.
Interfaces can vary radically from each other, since each is designed to
be best suited for its environment.  In practice though, interfaces all
share the same commands, so that you don't have to learn a whole new set
when switching computers, and many of the displays are similar.

When reading this chapter, you should be aware that the term @dfn{game}
is more precisely @dfn{game design}, since it is the set of rules and
definitions of the game you want to play.  Since @i{Xconq} allows for
many different kinds of game designs, much of the information in this
chapter will be irrelevant to a particular game.  This will be indicated
in the text by phrases like ``some games'' or by saying that a game
``may'' implement some concept or behavior.  You should learn what the
game you're playing actually does in these cases.  The names of the
variables or tables to look at will often be mentioned in @code{computer
type}.

@menu
* Setting Up A Game::
* Starting Play::
* Getting Help::
* Worlds and Areas::
* Units::
* Materials::
* Sides::
* Moving the Units::
* Automation of Units and Sides::                
* Modes::
* Standard Keyboard Commands::
* Unit Info::
* Backdrop Weather::
* Backdrop Economy::
* Backdrop Random Events::
* Scoring::
* Playing in Realtime::
* Advanced Play::
* Playing Hints::
* Problems and Troubleshooting::
* The Game Library::
@end menu

@node Setting Up A Game, Starting Play, Playing Xconq, Playing Xconq

@section Setting Up A Game

To get started with @i{Xconq},
you have to select which game you want to play.
The possibilities may be
presented to you, or you may have to look in some sort of library
to see what's available and then supply that name on a command line.
If you don't do anything, then you will get a default game.

Some games require no additional setup; once loaded, you're ready to go.
Others will require additional decisions, such as the size and shape of
the playing area, whether exploration will be necessary, or whether the
game is realtime.  These choices are @dfn{variants} of the game.  The
exact set of variants is part of the game design, and the interface will
(usually) tell you about them.

In addition, most games also give you a choice of which player is to
play which side in a game, as well how many players can join in.  There
are two kinds of players: humans, who have displays, and @dfn{artificial
intelligence}s or @dfn{AI}s for short, which are run by the computer.
Some versions of @i{Xconq} may include more than one kind of AI; each
type has a distinct name.  The AI named @code{mplayer} is always
available.

An example might be a simulation of Europe @i{ca} 1900, named
@code{"la-belle-epoque"}, in which the sides might be ``England'',
``France'', ``Germany'', and ``Austria-Hungary'', and the players might
be Joe on a Sun-4 named @code{sun-lamp}, Natalie on an HP machine named
@code{jaguar}, and two of the @code{mplayer} AIs.  You can set Joe to
play England, Natalie to play France, and the two AIs to play Germany
and Austria-Hungary by using this command line:
@example
xconq -g la-belle-epoque -r Joe@@sun-lamp:0.0 Natalie@@jaguar:0.0 -e 2
@end example
Note that this is X11, so the @code{:0.0} is the usual server and
screen identification, while @code{-r} says not to open a display
on the machine that is actually running the program.

Some game designs provide a way to even things up if the players are of
vastly differing abilities.  In these designs, each player has an
@dfn{advantage} that affects how much he or she gets to start with.
Weaker players should get a higher advantage, so for instance a game
with two players, of advantages 1 and 4, might give the advantage=4
player 8 cities while the advantage=1 player gets only 2.  This affects
setup only; during the game all players are equal.  The variability of
advantage also depends on the game; some may allows differences of 10 to
1 or more, while others, especially historically accurate scenarios,
will have a fixed advantage that the designer has set for each side.

Once a trial player setup has been made, @i{Xconq} runs ``synthesis
methods''.  The game design specifies the methods to use, which generate
anything that was not explicitly spelled out; such as the initial
location of countries, terrain features, and so forth.  As a player, you
don't have to concern yourself much about synthesis methods, but you may
get warnings or errors if a synthesis method is having difficulties.  A
common case is where you ask for many players to be set up in a small
world, and the set of constraints is too ``tight'' for an initial setup;
you will get a warning that some players were given poor positions.
Synthesis methods may also take a long time to run; for large worlds and
lots of players, be prepared to wait.

When initialization and setup succeeds, @i{Xconq} will try to open up
displays for every player that wanted one.  Exactly how this happens
depends on the interface and networking capabilities of the version of
@i{Xconq} you're using.  See the system-specific sections at the end of
this chapter for more detail.  Once all the players are in, @i{Xconq}
will start the game for real.

You may also get a warning that ``images were not found''.  This happens
when the game design specifies the use of particular icons or patterns
(collectively call @dfn{images} here), but they cannot be found anywhere
by @i{Xconq}.  This is not fatal, because @i{Xconq} will use generic
default images instead, but the display may be hard to understand.
There are several possible reasons for images not to be found: 1) the
game designer might have specified the use of particular images, but
never defined them, 2) the library of images was not updated to include
the needed images, or 3) the image library is not located where Xconq is
looking.

@ref{Problems and Troubleshooting}
describes more of the errors and warnings that you may encounter,
and what to do about them.

@node Starting Play, Getting Help, Setting Up A Game, Playing Xconq

@section Starting Play

What you'll first see depends entirely on the interface you're using.
Typically there will be at least a map and a list of sides.  Help is
available by typing `@code{?}' or clicking on a button that says
``Help''.  You can also just try to find your way around by
experimentation.  (This is best done in a game by yourself, rather than
in one with a lot of other people.)

The game proceeds as a sequence of @dfn{turns}.  During each turn, you
and the other players get to move your @dfn{units}, which can be
anything from cities to submarines to insects, depending on the game.
In addition, there may be @dfn{backdrop activities}, such as changing
seasons and weather, that go on all by themselves.  These typically
happen at the beginning or end of a turn, not while players are moving
their units.

Your exact goal depends on the game's @dfn{scorekeepers}.  Most games
have at least one, some have several, and some have none.  There are
many kinds of scorekeepers, so be sure you know and understand what they
are before getting too far into a game!  If there are no scorekeepers at
all, you can do whatever you like; any AIs playing in such a game will
behave quite randomly.
 
A game may last anywhere from a few turns to many hundreds.  Again, this
may be limited by the game design, or perhaps by the nature of the game.
For instance, a game of oil empires might be forced to end when the
world's oil supplies are exhausted...

@node Getting Help, Worlds and Areas, Starting Play, Playing Xconq

@section Getting Help

@i{Xconq} includes extensive online help.  The keyboard command
`@code{?}'  is available in all interfaces; some may also include a
button or menu item that leads you to the help system.  Help information
consists of a list of @dfn{help nodes}, each of which describes an
aspect of the game or of @i{Xconq} in general.  There is usually a table
of topics that you can select from, or else you can go forwards and
backwards through the nodes.

@node Worlds and Areas, Units, Getting Help, Playing Xconq

@section Worlds and Areas

@quotation
Gallia est omnis divisa in partes tres [All Gaul is divided into three
parts] -- JULIUS CAESAR
@end quotation

The @i{Xconq} ``world'' is always a sphere.  However, you only play on a
piece of its surface, which is called an @dfn{area}.  Currently, there
can only be one world and one area in a game; this may change in a
future version of @i{Xconq}.

An area is divided into a grid pattern of @dfn{cells}.  Although squares
with four or eight neighbors could be used (and were, in the very first
version of @i{Xconq}), currently only a hexagon grid is available.  Each
cell is therefore adjacent to six others, in the directions NW, NE, W,
E, SW, and SE.  Areas have a @dfn{width} and @dfn{height} that are the
number of cells across and up/down.  Although you can ask for areas down
to 10x10 or less, or up to 1000x1000 or even more, the ideal default is
typically around 60x30.  Larger areas consume vast quantities of memory,
plus they're slow and unwieldy to play on; don't ask for them unless you
have a lot of time and patience!

If the area's width matches the circumference of the world, it is a
cylinder in shape.  The cylinder can be circumnavigated in an east-west
direction.  This is what an 8x6 cylinder area might look like (periods
are sea, @code{+} and @code{^} are land, @code{#} indicates edge cells):
@example
# # # # # # # #
 . . + + . . . .
. . . + ^ . . .
 . . . . . . . .
. . . . ^ . . .
 # # # # # # # #
@end example

Areas whose width is less than the world's circumference have a
hexagonal shape.  This is an 8x7 hexagon:
@example
   # # # # # 
  # . + + . #
 # . . + ^ . #
# . . + ^ . . #
 # . . . . . #
  # . . ^ . #
   # # # # # 
@end example

The top and bottom rows of the cylinder shape, and all the sides of the
hexagon shape, are called @dfn{edge} cells.  Your units may not enter
them, unless leaving the area entirely, which some games allow.

The types of terrain you'll find in the world depends on the game
design; typically there will be sea, land, mountains, swamp, and so
forth, but more exotic games have been known to feature junkheaps, lava,
and black holes as ``terrain''.

Terrain can cover an entire cell, be linear features passing through or
between cells, or be a coating overlaying other terrain.  @dfn{Cell
terrain} covers the entire cell uniformly, right out to its edges.

A @dfn{border} is the boundary between two adjacent cells; it has a
distinct terrain type, such as ``river'' or ``beach''.  A
@dfn{connection} is a narrow ribbon of terrain that reaches from the
middle of one cell to the middle of an adjacent cell.  Like borders,
connections are distinct types, for instance ``road'', ``railway'', or
``canal''.  Connections take precedence over borders and underlying cell
terrain; in other words, if cell or border terrain is impassable, but
there is a passable connection type, then the connection allows passage.
Thus a connection can be usable as a bridge.  You may also find more
than one type of connection or border, between two cells, such as both a
road and a rail line.  They will be assumed to be side-by-side, so that
units can use any connection that they like, and will be affected by all
borders when crossing them.

A @dfn{coating} is like snow; it is a type that co-exists with cell
terrain.  Coatings can change from turn to turn, varying in depth--and
resultant effect on units.

Note that any single terrain type can only play one of these roles.
This means you will never have river terrain that is both border and
connection, nor will snow be both a coating and a cell type.

In some games, each cell has an @dfn{elevation}, which is basically
elevation above sea level, but could be any range of values, as set by
the game design.  The game design also defines the effect of elevation
on movement, visibility, and weather.

A world can have @dfn{people} living in some or all of its cells.
People belonging to a side report everything they see in their cell to
their side.  Some types of units will cause the people's side to change
to match their own.

A world can have named @dfn{geographical features} or just
@dfn{features}, such as a bay, mountain, desert, or valley.
Geographical features never have any direct effect on your game, but
some interfaces may label features when drawing a map, or use them to
help describe locations verbally, in phrases like @code{"1 hex NW of
Broken Hill"}.

The coordinate system is ``oblique'', with the X-axis in the usual
horizontal, and the Y-axis vertical, but tilted to the right at a
60-degree angle.
@example
      Y
  \  /
   \/
---------X
  / \
 /   \
@end example
The additional left-leaning axis is the x = - y line.

@node Units, Materials, Worlds and Areas, Playing Xconq

@section Units

@dfn{Units} can be almost anything: adventurers, armies, balloons,
bicycles, dragons, triremes, spiders, battleships, bridges,
headquarters, cities.  Units move around, manufacture things, fight with
other units, and possibly die.  They are the playing pieces of
@i{Xconq}.

Units have a location, either out in the open terrain of a cell, or
inside some other unit.  In games that define connections, a unit may be
on the connection rather than on the predominant terrain of the cell.
(Think of a truck on a bridge.)  There may be more than one unit in the
open in a given cell, up to a game-defined limit.  The collection of
units sharing a cell is called a @dfn{stack}.  A unit inside another
unit will be called an @dfn{occupant} in a @dfn{transport}, even if the
``transport'' is a type that can never move.

A unit's location may also include an @dfn{altitude}, expressed as its
distance above the surface of the cell it is in.  Altitude affects
combat and viewing abilities.

A unit either belongs to a side, or else it is considered
@dfn{independent}.  Independent units do not do very much.  In more
complex games, the unit's side merely represents the current ownership,
and the unit may have a range of feelings towards each side, including
its current one.  In those games, it is possible for one of your units
to be a traitor!

Units can have a name, full name, a title, and a number, as appropriate
to the situation.  The name is an ordinary name like ``Joe Schmoe'' or
``Cincinnati'', while the full name might be something like ``Joseph
P. Schmoe''.  The title is a form of address such as ``Lord''.  The unit
number, if used, is an ordinal that is maintained for each side and each
unit type, so you can have both a ``1st national bank'' and a ``45th
infantry division'' on your side.  Names and numbers are always
optional, and can usually be changed at any time during the game.

Every unit starts out with a number of @dfn{hit points} or @dfn{hp}
representing how much damage it can sustain before dying.  Certain types
of units, such as armies and fleet of ships, have multiple @dfn{parts},
which means that damage to them reduces their effective size.
Multi-part units can merge with and detach from each other.  Damaged
units may recover their hp on their own, or else be repairable by
explicit action, either by themselves or by another units (ships in port
for example).

In addition to occupants, a unit can also carry @dfn{supplies} (food,
fuel, treasure, etc), which are type of ``materials'' (see the next
section).  Supplies are used up by movement, combat, and by just
existing, and are gotten either by producing them or by transferring
them from some other unit.  Some games start units out with lots of
supplies, while in others you have to acquire them on your own.

What a unit can do at any one time depends on the @dfn{action points} or
@dfn{acp} available to it.  Each sort of action - movement,
construction, repair, etc - uses up at least one action point, and
possibly more.  A unit with an acp of 0 can never do anything on its
own, although other units can still manipulate it.  Also, not every type
of unit can do every type of action; this is also defined by the game
design.  @ref{Types of Actions} lists all the types of actions that are
possible in @i{Xconq}.

Units that engage in combat may accumulate @dfn{combat experience} or
@dfn{cxp} for short.  Combat experience will increase with each fight,
irrespective of outcome, up to a game-defined maximum.  An experienced
unit will do better in combat, being both more effective in inflicting
damage on opponents and at avoiding damage to itself.

You can lose a unit in many different ways: in combat, by running out of
essential supplies, by being captured, by revolt, by garrisoning a
captured unit, by leaving the world, or in accidents.  If a unit dies
because of excessive damage (i.e. hp = 0), then in some games it will
change into its @dfn{wrecked type}.  Wrecks are just normal units.  For
instance, a city might be ``wrecked'' and become a town.  Occupants of
dead or wrecked units will attempt to leave.  If they can't, then they
will share the fate of their transport.  If an occupant can occupy a
wrecked transport with no problem, then nothing will happen to it.

@node Materials, Sides, Units, Playing Xconq

@section Materials

In @i{Xconq}, @dfn{materials} are basically bulk inanimate stuffs, like
food or fuel.  They are kept in units or in cells, up to limits defined
by the game.  Materials may be provided as part of the initial game
setup, or else produced by units and cells.  They are consumed by
construction, movement, or merely in order to survive.  You can also
move materials around from unit to unit.  Some games define laws of
supply and demand, which will move materials for you, though not
necessarily in the directions you would prefer!

In a few games, possession of a material type may figure into your score
(gold in a dungeon-type game, for instance).  In other games, there
are no types of materials at all.  Sometimes materials exist only to
constrain units' actions, such as fuel to prevent airplanes from
straying too far from airports, and so you may not need to do much with
the materials yourself.  The player notes and help info for the particular game
should explain this if so.

@node Sides, Moving the Units, Materials, Playing Xconq

@section Sides

Each player in @i{Xconq} runs a @dfn{side}.  The concept of ``side'' is
somewhat abstract in @i{Xconq}; units in a game belong to sides, but the
sides themselves are not attached to any particular unit.  Side often
represent countries, but not invariably; they may be factions,
governorships, or alliances, or just a convenient division of the game's
units.

It is important to be clear about sides and players.  A side is a part
of the simulated world, while a player is the actual real-world person
or program that is playing the side.  You yourself are always the
player, but in one game you may play the German side, and in another the
Klingon side.  During a game, there will always be a player for each
side, and vice versa.  The distinction is most important during setup
and restoration of saved games, since you can choose which players go
with which sides.

Each side can have a name and associated parts of speech, such as a noun
for individuals on the side and an adjective to describe anything
belonging to the side.
@c [example?]
A side may also have an @dfn{emblem} and one or more colors for displays
to use.  Some game designs preset all this, while others let you
personalize as desired.

@menu
* Interaction Between Sides::   
* Using Agreements::                  
* Tech Levels::                 
* Side Classes::                
* Self-Units::                  
@end menu

@node Interaction Between Sides, Using Agreements, , Sides

@subsection Interaction Between Sides

In games with two players, your interaction is usually pretty simple,
i.e. bash on each other.  In games with many players, some human, some
mechanical, it is possible to have a variety of relationships, ranging
from complete trust to complete hostility.

A side can @dfn{trust} another side.  This is
like a close ally - you can enter each other's transports, you share
view data, and so forth.  Trust is a two-way relationship; both you and
the other side each have to declare you want to trust the other.  You
can do this at any time.  You can also, unilaterally, withdraw your
trust in another side at any time.  There are no preconditions or caveats
for trust.

You can make your side be controlled by another side.
This is basically a surrender that lets you stay in the game, because
the controlling side can manipulate any of your units as if they were
its own.  The controlling side also has the option of allowing or
forbidding you to move your own units.  The relationship is strictly
one-sided, and only the controlling side can release the controlled
side.  (Note that this is a way to have several people play on a side;
have one player run the controlling side and be helped by several other
players running controlled sides, usually with agreed-upon
responsibilities.)

@node Using Agreements, Tech Levels, Interaction Between Sides, Sides

@subsection Using Agreements

@quotation
Diplomacy is to do and say //
The nastiest thing in the nicest way.
-- ISAAC GOLDBERG (1938)
@end quotation

If you don't want to declare a special relationship with another side,
but still want to make some sort of adhoc arrangement, you can create an
@dfn{agreement}.  An agreement is a sort of generalized treaty; it
consists of a number of @dfn{terms} agreed to by a number of
@dfn{signers}, which are sides.  Agreements may be public or secret, and
you can declare them to be enforced by @i{Xconq} if the terms are in a
form it understands. An agreement that just says ``help each other out''
cannot be evaluated by the computer!

[Agreements are not completely implemented.]

@c To make an agreement, you tell the interface to create one, fill in its
@c terms, possibly give it a name, make up a list of proposed signers,
@c then either propose it directly or else send to @dfn{drafters}, which
@c are the side you want to help with the composition of the agreement.
@c The draft also includes the list of sides that will know about the
@c agreement.
@c 
@c When the agreement is officially proposed, it will be displayed to
@c all sides that are to sign, and represented as coming from the
@c sides listed as @dfn{proposers}.
@c @i{Xconq} will then ask each proposed signer to sign;
@c if all do so, then the agreement goes into effect immediately.
@c All sides that are to know about the agreement
@c will be informed of its terms.
@c 
@c Some interfaces may allow players to copy and modify a proposed and
@c circulate it along with the original.  The proposing side may also
@c withdraw a proposal, but cannot modify it without having it signed again
@c by everybody involved.
@c 
@c Once in effect, an agreement cannot be modified, and it cannot be
@c removed unless it includes a term that provides for this.
@c 
@c An agreement can have any number of terms.
@c Each term can have one of several forms:
@c 
@c A text string.  This is not interpreted in any way
@c and could be a comment, preamble, or whatever.
@c 
@c A true/false expression.  This must always be true for the agreement
@c to be valid.
@c 
@c A statement of an action.  This action will be performed at the instant
@c that the agreement goes into effect.
@c 
@c An if-then statement.  If the condition is true
@c while the agreement is in effect, then the action will be performed.
@c 
@c [need some examples]
@c 
@c Note that the drafter/proposer/signer distinction has many uses;
@c for instance, you can draft an agreement to be proposed by a coalition
@c of sides, but the proposed signers are neutral sides that you want
@c to keep quiet.

@node Tech Levels, Side Classes, Using Agreements, Sides

@subsection Tech Levels

In some game designs, technology and research are important.  These
games give each side a set of @dfn{tech levels} (or just @dfn{tech} for
short), one for each type of unit.  The tech level represents the
technological knowledge needed to see, operate and build a type of unit.
Tech levels never decrease, at least in the @i{Xconq} universe, and they
can be increased by research and espionage.

There are several tech thresholds for a unit.  First there is
@code{tech-to-see}, below which you will not even be aware of the
existence of a unit (consider barbarians unable to see spy satellites
passing overhead).  Then there is @code{tech-to-use}, which you must
have in order to make the unit do any actions.  The
@code{tech-to-understand} and @code{tech-on-acquisition} are points at
which your side can increase its tech level just by owning a unit, and
finally the @code{tech-to-build} is what you must have to create new
units of the given type.

@node Side Classes, Self-Units, Tech Levels, Sides

@subsection Side Classes

In some games, several sides may be very similar to each other, while
being very different from other sides in the same game.  For instance,
the game might have several sides that are different tribes of
barbarians, but they are more like each other than, say, Romans.  These
similar sides can be given the same @dfn{side class}.  Units may then be
restricted to be usable only by the sides in a particular class.  (Note
that this is different from tech level, which allows units to be used by
any side that has managed to acquire a sufficient tech level.)

@node Self-Units, , Side Classes, Sides

@subsection Self-Units

A @dfn{self-unit} is one that represents your whole side in some way.
For instance, in a dungeon exploration game, your ``side'' might consist
of an adventurer (you), your possessions, your followers, and perhaps
more.  In such a case, if the adventurer dies or is captured, then the
game should be over, at least for you.

Usually the self-unit will be set up by the game design, and all you
have to do is to be aware that losing the self-unit permanently ends
your participation in the game.  Some games might have ``self-unit
resurrection'' (@code{self-resurrects}) which just means that if another
type of unit is available when the current self-unit dies, then that
another unit becomes your new self-unit.  For instance, admirals would
leave their sinking flagship and board another ship, thus ``transferring
the flag''.  (Admirals presumably being more valuable than captains, who
are supposed go down with their ships!)  Some games may also allow you
to change self-units manually (@code{self-changeable}).  In any, the
game will define which types may be self-units (@code{can-be-self}).

@node Moving the Units, Automation of Units and Sides, Sides, Playing Xconq

@section Moving the Units

Once the first turn begins, you can begin looking at the display and
moving your units.  Depending on the game design and startup options,
you may or may not be moving simultaneously with the other players.  If
not, then the players move one at a time, in the order that their sides
are listed in any display.  Usually, you can choose freely which units
to move next; you can move one a bit, switch to another, move it, then
come back to the first one later, and so forth.  Some game designs may
require that you move units in a specific order; perhaps all your
aircraft must finish all their movement before any ships can move.

@menu
* Turn Setup::
* Types of Actions::
* Movement::                    
* Combat::                      
* Research::                    
* Construction::                
* Repairing Units::             
* Disbanding Units::            
* Transferring Unit Parts::          
* Changing Unit Side::               
* Changing Unit Type::               
* Producing Materials::         
* Transferring Materials::      
* Changing the Terrain::        
@end menu

@node Turn Setup, Types of Actions, , Moving the Units

@subsection Turn Setup

First, @i{Xconq} computes the number of action points available to each
unit.  Each unit gets an increment of action points equal to its
@code{acp-per-turn}.

The range of action points for a unit is normally 0 up to the value of
@code{acp-per-turn}, but the parameters @code{acp-min} and
@code{acp-max} may allow for an extended range.  You use this range by
allowing a unit to accumulate extra action points by doing nothing for
several turns, or to recover from an activity that used many action
points all at once.  Think of this as a sort of temporary action
``debt''.  Units in debt at the beginning of a turn cannot act during
that turn, and will continue to be inactive until they start a turn with
an acp of 1 or more.

@node Types of Actions, Movement, Turn Setup, Moving the Units

@subsection Types of Actions

Actions are the most basic kinds of things your units can do.  During
play, the interface will usually give you capabilities that are easy to
use, such as the ability to point at a destination and have the unit
figure out which path to take to get there, but all such input
eventually breaks down into sequences of actions.  Also, the rules of a
game design are expressed in terms of allowed actions, their costs, and
their consequences.  You will therefore find it useful to understand all
the types of actions available.

Each type of action may have one or more ``arguments'' associated
with it.  These are mentioned below as ``given'' values.

Movement:

@itemize @bullet
@item
@i{Move to} a given location.
The unit being moved may be in a
transport or out in the open, the destination is any location in the
open (this will usually, but not always, be an adjacent cell), and may
be at any altitude allowed for the unit.  (@code{move-to})

@item
@i{Enter} a given transport unit.
The transport need not be on the same
side as the entering unit.
(@code{enter})

@end itemize

Combat:

@itemize @bullet

@item
@i{Attack} a given unit.
A successful attack causes damage and destruction
to the unit being attacked.
(@code{attack})

@item
@i{Overrun} a given location.
The overrunning unit attempts to
occupy the destination, capturing, ejecting, or eliminating any
unfriendly unit present.
(@code{overrun})

@item
@i{Fire at} a given unit,
either using a given material as ammunition, or using any available
material.
(@code{fire-at})
 
@item
@i{Fire into} a given location,
either using a given material as ammunition, or using any available
material.
(@code{fire-into})

@item
Attempt to @i{capture} a given unit.  If the attempt is successful,
the unit changes side to match that of the capturing unit.
Occupants will either escape, die, or be captured also.
(@code{capture})

@item
@i{Detonate} at a given location.
Detonation may damage any or all units in the vicinity
of the detonation, and it may change terrain types as well.
(@code{detonate})

@end itemize

Construction:

@itemize @bullet

@item
@i{Research} a given unit type.
This increases the tech level for the type being researched.
(@code{research})

@item
@i{Tool up} to build a given unit type.
(@code{toolup})

@item
@i{Create} a unit of the given type @i{in} a given unit.
The unit will usually be incomplete.
(@code{create-in})

@item
@i{Create} a unit of the given type @i{at} a given location.
The unit will usually be incomplete.
(@code{create-at})

@item
@i{Build} a given unit towards completion.
(@code{build})

@item
@i{Repair} a given unit, restoring lost hp.
(@code{repair})

@end itemize

Unit Manipulation Group:

@itemize @bullet

@item
@i{Disband} a given unit, causing it to disappear.
(@code{disband})

@item
@i{Transfer part} of a unit, either to another given unit,
or to a new unit created by this action.
(@code{transfer-part})

@item
@i{Change side} of a given unit to a given side.
(@code{change-side})

@item
@i{Change type} of a given unit to a given type.
(@code{change-type})

@end itemize

Material Manipulation Group:

@itemize @bullet

@item
@i{Produce} a given quantity of a given material type.
(@code{produce})

@item
@i{Transfer} a quantity of a given material type to a given unit.
(@code{transfer})

@end itemize

Terrain Manipulation Group:

@itemize @bullet

@item
@i{Add terrain} of a given type to a given location.
(@code{add-terrain})

@item
@i{Remove terrain} of a given type from a given location.
(@code{remove-terrain})

@item
@i{Alter terrain} to a given type at a given location.
(@code{alter-terrain})

@end itemize

Normally, you as the player and the side simply tell units to perform
these actions themselves.  However, some games will allow the unit to
cause the action to done as if another unit were doing the action.  For
instance, a transport can pick up or drop off a non-moving unit.

Not all interfaces can be guaranteed to allow the most general forms of
all these actions; you must consult the interface's documentation to
find out which of these actions is available.

@node Movement, Combat, Types of Actions, Moving the Units

@subsection Movement

Movement into a cell is easy to request--interfaces let you do this with
a keystroke or mouse click--but each game design will have many rules
constraining possible moves, depending both on the unit and the terrain
it is moving over.  Certain kinds of terrain cost extra time to enter,
leave, or cross.  The destination must usually be adjacent to the unit's
current location, and may be at any altitude.

The other kind of movement action is to enter/leave a transport.  The
only argument is the unit to enter, but again the constraints are
complicated.  The transport must have sufficient space, both the
entering unit and the transport must have sufficient mp and acp to
complete the move, and the entering unit must be able to cross the
intervening terrain.  The transport may be able to @dfn{ferry} the
would-be occupant over any barriers; possibilities include no ferrying,
ferrying only over the transport's terrain, ferrying over any borders,
and ferrying over all terrain between the would-be occupant and the
transport.

Although as with other actions, you use up action points to move, the
cost of movement is based on @dfn{movement points} or @dfn{mp}.  A
unit's @dfn{speed} determines the relationship between acp and mp; most
of unit have a speed of 1.00, so for them acp and mp are the same.
However, a unit with a speed of 4.50 and 2 acp will be able to do moves
costing up to 4.50 * 2 = 9 mp.

In some games, you may be able to make one of your units leave the world
entirely.  Sometimes this will seem like a good idea, perhaps to keep a
trapped unit from falling into enemy hands, or because you win the game
by leaving through a designated place.  To do this, you just direct your
unit (which must already be at the edge of the world) to move into one
of the cells along the edge.  If the departure is allowed, then the unit
will simply vanish and be out of the game permanently.

In other games, you may be able to do a @dfn{border slide}.  This is
where a unit can jump to a non-adjacent cell if the two cells have a
border whose endpoints touch the starting and ending cell.  This is
typically allowed in games so that ships can go through narrow straits
without having to be ``between cells'' at any time.

@node Combat, Research, Movement, Moving the Units

@subsection Combat

@quotation
War is a matter of vital importance to the State; the province of life
or death; the road to survival or ruin.  It is mandatory that it be
thoroughly studied.  -- SUN TZU (ca 400 BC)
@end quotation

There are two basic kinds of combat, each with two versions.  A unit can
either attack or overrun, meaning that it comes to grips with the enemy
in some way, or it can fire, meaning that it keeps its position and
throws rocks or whatever at a target.

@dfn{Attack} is directed at a particular unit, while @dfn{overrun} is a
more complex action where the unit attempts to clear enough units from a
given location so that it can move in.

A unit wishing to attack picks a position or unit to attack, @i{Xconq}
computes the defender's response, then the outcome is computed.

(In future versions of @i{Xconq}, units may become locked in a
``battle'' and unable to do anything else until the battle is over or
the unit has disengaged somehow.)

@dfn{Firing} can happen at long ranges, up to the @code{range} of a
unit.  It may or may not involve using a specific material as
ammunition; if the game gives you a choice, you will have to choose
which, or else all possible types will be used.  You can @dfn{fire at} a
specific unit if you can see it, otherwise you will have to @dfn{fire
into} a cell; perhaps without knowing whether or not you're actually
hitting anything in it.  Some units may also have a @code{range-min} and
cannot fire at anything that is closer than that range.  (ICBMs and some
kinds of artillery are limited in this way.)

Some units are capable of capturing other units, with a probability
depending on the types of both units involved, and whether the unit
being captured is independent or belongs to a side
(@code{capture-chance} and @code{independent-capture-chance}).  If the
capture attempt is successful, the capturer will move into the cell if
possible, either as occupant or transport.  In some games, the capturer
may be partially or even completely disbanded, to serve as the garrison.
Capture may also occur as a side effect of a normal attack or overrun.

Detonation is a special kind of ``combat'' available to some units.  The
action requires a location, either the unit's own position or a nearby
cell.  Upon detonation, the detonating unit may lose some hp and even
die (changing to its wrecked type, if defined, or else vanishing).  At
the same time, it makes one hit on any units within its radius of
effect.  Detonation may also be triggered automatically, such as by
damage to the unit or even by another unit appearing nearby.

@node Research, Construction, Combat, Moving the Units
@subsection Research

@quotation
Knowledge is power.  -- FRANCIS BACON (1597)
@end quotation

@dfn{Research} increases a side's tech for the unit type being
researched.  Although you can only research a specific type of unit,
some game designs allow for a crossover effect, where increases in the
tech level for one type also increases the level in others.

You can have more than one researcher researching the same type, and
thereby speed up your progress, but some games put a ceiling
(@code{tech-per-turn}) on how much progress you can make in one turn.

@node Construction, Repairing Units, Research, Moving the Units

@subsection Construction

@quotation
We must be the great arsenal of democracy.
-- FRANKLIN ROOSEVELT (1940)
@end quotation

@dfn{Tooling up} prepares a unit to create or construct the desired
type.  As with research, game designs may allow a crossover effect for
tooling.  Tooling may also decline gradually over time; this is called
@dfn{tooling attrition}.  Many games do not require tooling up.

Actual construction of a unit happens in two steps; creation and
building towards completion.  Most interfaces will also schedule
research and toolup actions if a unit is told to build something that
needs tech or tooling first.

@dfn{Creation} is the actual step of bringing a new unit into existence.
If the new unit is @i{complete}, then it can be used immediately.  If
not (which is usually the case), then the incomplete unit will exist and
belong to your side, but be unable to do anything at all.  Incomplete
transports cannot have any occupants, unless the occupants are types
capable of helping complete the transport.  Incomplete units always have
1 hp, so they're vulnerable to attack.

@dfn{Completion} is achieved by doing build actions on the unit.
Multiple units can all work on completing the same unit, but they must
be sufficiently close, within a range defined by the game (usually the
same or an adjacent cell).  In some games, there is a level of
completion past which the unit will start working on itself
automatically, and eventually become complete without any further
action.

It is @i{usually} the case that the same unit will be able to both
create and complete a unit, but if not, you will have to pay special
attention to your construction plan, since an incomplete unit cannot act
in any way.  You would have to either transport the incomplete unit to a
type that can complete it, or the completing unit must come to the
incomplete one.  Some games may allow the incomplete unit and its
completer to be some distance apart, but the usual rule is that they
must be in the same cell.

Note that multi-part units will be considered ``complete'' when just one
of their parts is completed.  Most interfaces will have the builder
continue growing the just-completed unit as long as it remains within
construction range.

@node Repairing Units, Disbanding Units, Construction, Moving the Units

@subsection Repairing Units

@dfn{Repair} restores lost hit points to a unit.  Repairs can be done by
the damaged unit itself, if it is not too badly damaged, or by another
unit that is close enough.

Some games also feature automatic hit point recovery
(@code{hp-recovery}), so you don't always have to remember to do
explicit repair actions.

@node Disbanding Units, Transferring Unit Parts, Repairing Units, Moving the Units

@subsection Disbanding Units

@dfn{Disbanding} is a voluntary loss of hp, ultimately resulting in the
disappearance of the unit.  Most games only allow it for a few types of
units.  Depending on the game, you may be able to disband the unit with
one action, or you may need several before the unit actually goes away.

Units with occupants can disband, but only if the occupants are
unaffected by the action.  If the unit would vanish or lose transport
capacity, then the occupants must be disbanded or removed first.  (The
interface may arrange to do this for you automatically.)

You always get back all of the disbanded unit's supplies, and they will
be distributed to other units nearby.  In addition, the disbanded unit
itself may become a source of materials, according to the table
@code{recycleable-material}.  A percentage of the total material will
become available after each action, if disbanding takes several actions
to accomplish.

@node Transferring Unit Parts, Changing Unit Side, Disbanding Units, Moving the Units

@subsection Transferring Unit Parts

In games where units can vary in size, you can shift one or more parts
of a multi-part unit to another unit, or else create an entirely new
unit.

You would use this action if, for instance, you wanted to detach a
survey party from an exploring expedition, then rejoin later.

@node Changing Unit Side, Changing Unit Type, Transferring Unit Parts, Moving the Units

@subsection Changing Unit Side

In many games, you can give some of your units to another side.  You may
also be able to take them from another side, if you control that side.

Unlike other actions, you may be able to cause a unit to change side
without actually needing any action points, if the type is one that
cannot act on its own.

@node Changing Unit Type, Producing Materials, Changing Unit Side, Moving the Units

@subsection Changing Unit Type

A few games allow you to change the type of a unit.

For instance, you might have this ability in a construction-oriented
game, where you can take a town that has accumulated sufficient building
materials and change it into a city.  Another possibility is that you
have increased your technology level and are now able to transform a
low-tech ship into a higher-tech ship.

@node Producing Materials, Transferring Materials, Changing Unit Type, Moving the Units
@subsection Producing Materials

@dfn{Production} is how a unit can produce a quantity of a material.

In many games, units already have a @dfn{base production} that is the
amount of material that they produce automatically each turn.  This will
often depend on the terrain, so that explorers in the forest will always
``produce'' enough water to drink each turn, but will start to use up
their water supply when in the desert.

@node Transferring Materials, Changing the Terrain, Producing Materials, Moving the Units
@subsection Transferring Materials

Often there will be plenty of some type of material in the world, but
the problem is getting it from the units that have it to the units that
need it.  The @dfn{transfer} action is how you move material supply from
one unit to another.

As with production, many games have some automatic transfers set up.
For instance, games involving aircraft generally refuel them
automatically whenever the aircraft has landed in a place with fuel to
spare.  [Demands should be set by doctrine.]

@node Changing the Terrain, , Transferring Materials, Moving the Units

@subsection Changing the Terrain

In some games, units can add or remove borders, connections, or
coatings, or may even be able to change the overall type of terrain in a
cell.  The actions are @dfn{add-terrain}, @dfn{remove-terrain}, and
@dfn{alter-terrain}, respectively.

The change happens immediately (for the sake of simplicity), but in
practice, you may find that preparing for the change may take awhile.
For instance, the unit executing the change might have to accumulate acp
or materials required for the change.

@node Automation of Units and Sides, Modes, Moving the Units, Playing Xconq

@section Automation of Units and Sides

Specifying the exact sequence of actions and their operands for every
single unit would be mind-numbingly complex, and, for that matter, not
very realistic either.  Therefore, @i{Xconq} includes several levels of
automation for human players.

The elements of automation are the @i{task}, the @i{plan}, the
@i{doctrine}, and the @i{strategy}.  These are related to each other by
@i{goals}.

@dfn{Tasks} are single activities of a unit that require one or more
actions to accomplish.  Examples of tasks include moving to a given
position, or waiting 15 turns to be picked up by a transport.  Most of
the commands that you give while playing actually set up tasks rather
than individual actions.

A @dfn{plan} is the unit's object that expresses its decided-upon
behavior.  Elements of a plan include a type, possibly one or more
goals, a @dfn{task agenda}, plus some assorted flags and properties.
All units that can act and that are on a side will have a plan, while
independent units that can do actions may have a plan that is preset by
a scenario.  Plans primarily govern individual behavior, in many cases
allowing the unit to act on its own, without needing any explicit
direction from the player.

The @dfn{doctrine} is the set of parameters governing how the side will
play and how its units should work generally.  For instance, per-unit
doctrine specifies the point which a unit low on supply should start to
look for a place to replenish itself.

The @dfn{strategy} and associated subobjects is what an AI uses to make
all the decisions about what to do.  This object is not directly
visible, unless the AI is acting as your assistant and the interface
includes a display of its strategy.

Of all these types of objects, only the doctrine can be manipulated
directly; all others are implicitly changed as a result of player
commands, which are different for each interface.

The @dfn{Standing order} command allows you to set up conditions for
execution of tasks.

@menu
* Using Doctrine::
* Plans::
* Tasks::
* Standing Orders::
@end menu

@node Using Doctrine, Plans, , Automation of Units and Sides

@subsection Using Doctrine

There is a doctrine for each type of unit on your side.  Several types
may share a single doctrine, so that changes to it will affect all types
equally.

@itemize @bullet

@item
construction-run

@end itemize

[more doctrine info]

@node Plans, Tasks, Using Doctrine, Automation of Units and Sides

@subsection Plans

A unit's plan must be one of the types listed here.

@itemize @bullet
@item
None (@code{none}).
Units with this type of plan do absolutely nothing. 

@item
Passive (@code{passive}).
Units with a passive plan will execute any tasks they have
been given, but will not add to the task agenda on their own.
By default, if you are running the side by yourself,
with no AI assistant, your units will have this type of plan.

@item
Offensive (@code{offense}).
Units with an offensive plan will look for favorable
combat opportunities, usually within an area specified as their goal
to hold.

@item
Defensive (@code{defense}).
Units with a defensive plan will seek to preserve the status quo.

@item
Exploratory (@code{explore}).
Exploratory units will seek to collect information about
unknown parts of the world.

@end itemize

@node Tasks, Standing Orders, Plans, Automation of Units and Sides

@subsection Tasks

A task has several standard properties and may have additional properties
specific to the task's type.  @i{Xconq} keeps track of how many times a
task has been executed and how many times it has failed to execute a
step correctly.  For example, a movement task to a distant location may
need to execute 100 times, but it will only fail if the unit is actually
blocked from moving.  If a task fails too many times, the plan or the AI
may decide to remove the task from its agenda.
If a task succeeds, it will always be removed.

Each task in a plan's task agenda must be one of the types listed here.

@itemize @bullet
@item
Do nothing (@code{none}).

@item
Sentry (@code{sentry @var{turns}}).
Stand sentry at the present location for a given number of turns.
This is not the same as sleeping, since it is for a definite period
of time.

@item
Move in a direction (@code{move-dir @var{direction}}).
Move in the given direction up to the given distance.

@item
Move to a location (@code{move-to @var{location}}).
Move to within a given distance of the given location.

@item
Occupy a unit (@code{occupy @var{unit}}).
Move towards a given unit and attempt to enter it.

@item
Pick up a unit (@code{pickup @var{unit}}).
Move towards the given unit and wait for it to enter.

@item
Build (@code{build @var{unit-type n}}).
Build a given number of units of a given type.
This task will do research actions if necessary and possible,
and toolup actions if necessary.
Also, if there is an incomplete unit of the given type
nearby, this task will complete it before creating a new unit.

@item
Research (@code{research @var{unit-type n}}).
Do research to increase the tech for a given type
up to a given level.

@item
Hit a position (@code{hit-position @var{location}}).
Attempt to attack or fire on any units at the given position.

@item
Hit a unit (@code{hit-unit @var{unit}}).
Attempt to attack a given unit.

@item
Capture a unit (@code{capture @var{location}}).
Attempt to capture a unit at a given location,
optionally of a given type and on a given side.

@item
Resupply (@code{resupply @var{material-type}}).
Replenish depleted supplies.
This may be accomplished by production actions,
moving to higher-productivity terrain,
or by moving within supply range of a unit with the desired
supplies.

@item
Repair (@code{repair @var{unit}}).
Repair damage to the given unit.

@item
Do a specific action (@code{do-action @var{action-parms...}}).

@end itemize

@node Standing Orders,  , Tasks, Automation of Units and Sides

@subsection Standing Orders

Standing orders are basically a combination of a test or condition and
a task to be performed when the condition is met.
The textual form of the command is ``if <type> <test> <task>'',
where <type> is a name of a unit type, <test> is some sort of condition,
and <task> is a task, as described previously.

Possible tests include @code{at @var{location}}, @code{in @var{unit}},
and @code{near @var{location} @var{dist}}.

The @code{at} test applies to the unit if it comes to be in a particular cell,
for whatever reason.  The @var{location} may be either a comma-separated pair
of coordinates, or the name of a unit.

The @code{near} test is similar to @code{at}, but you give an additional
argument that says how close, in cells, the unit must be for the order to apply.
For instance, a distance of 1 means that the order applies to units at the
given location and to all adjacent units.  This is useful if you want to
have several kinds of units use a rendezvous point that is on a type of
terrain that some of the kinds can't use, or if there are stacking limits
and requiring all units to converge on a single cell would result in
traffic jams.

The @code{in} test applies to the unit if it is an occupant of the given
unit.

If a unit is already performing another task, it will ignore any standing
orders in any location that it happens to be passing over; so it is not
possible for the standing order to waylay the unit and send off doing
something else.  The unit must be under your orders (``passive'' plan),
not have any tasks on its agenda, and cannot be asleep or in reserve.

@example
if armor in Paris move-to Antwerp

if bomber in London move-to 33,54
if bomber at 33,54 hit-position 34,60
@end example
The second example shows how you can use several standing orders together to
route units around obstacles or dangerous areas.

@node Modes, Standard Keyboard Commands, Automation of Units and Sides, Playing Xconq

@section Modes

Interfaces to @i{Xconq} have typically two major modes governing how
input will be handled; @dfn{survey mode} and @dfn{move mode}.  The
purpose of these modes is to streamline the input and interaction
process; they have no other consequence, and all functionality should be
available in either mode.

In survey mode, you are basically just looking around the map.  Normal
mouse clicks change the focus and perhaps scroll the map, but do not
cause any units to do anything.

In move mode, a normal mouse click means to move the currently selected
unit or units to the location of the click.

@node Standard Keyboard Commands, Unit Info, Modes, Playing Xconq

@section Standard Keyboard Commands

These commands should be available in all versions of @i{Xconq}.
Additional commands may be defined for some interfaces; see the
interface's documentation below for more details.

@set FULL

@include commands.texi

@node Unit Info, Backdrop Weather, Standard Keyboard Commands, Playing Xconq

@section Unit Info

Most of the interfaces in Xconq use a common format for displaying
textual information about a unit.

First comes the unit type, ownership, and name or number:

@code{your city New York}

Then there is the current values of the most important properties.
Each value includes its maximum, so that there is no confusion about
what the current value means.

@code{HP 37/40  ACP 0/1}

Next comes the location of the unit.  This will vary in form, so for
instance a unit out in the open by itself will have something like

@code{in mountains at 23,59}

while an occupant of a transport will have

@code{in 2nd troop transport at 10,35}

Location information also includes descriptions of roads, rivers,
and other linear features nearby, plus elevation and temperature
if appropriate.

If the game allows for stacking multiple units at one location,
unit info will briefly list counts of the other types present,
usually with single characters to indicate the types, as in

@code{2 i 1 f 1 N here also}.

If the unit is a transport with occupants, then the list of
occupants appears, in a similar format:

@code{Occs 1(1) i 2 b}

(The first number is actually only a count of the complete units, the
number of incomplete units is in parentheses.)

Unit info includes a list of all materials being carried as supplies,
in a straightforward form:

@code{fuel 8/10  ammo 4/4}

The unit's current plan appears as a word describing the plan type,
followed by plan properties, such as awake/asleep, reserve, and AI
control:

@code{passive AI 1 task}

Plan information is followed by task info.  The details of each task
description depend on the task type:

@code{move-to 34,10 x 2}

The ``x <n>'' indicates the number of times the task has been executed
so far.  There may also be a ``fail <n>'' indicating the number of failures
of execution that have occurred, for instance because a unit's movement
has been blocked.

@node Backdrop Weather, Backdrop Economy, Unit Info, Playing Xconq

@section Backdrop Weather

Some games include @i{environmental effects}, which includes what we
normally think of as weather; the temperature, clouds, wind, rainfall,
snowfall, and snow cover on the ground.

The temperature falls in a range specified by the game, and may be
computed in different ways depending on the game design, but typically
depends on terrain, latitude, the severity of the seasons, and
elevation.  Temperature may also vary randomly from turn to turn and
cell to cell.  [describe effects of temperature on units]

A game may include clouds.  Clouds in @i{Xconq} are a single band, with
a density, altitude of cloud bottom, and cloud height in each cell.  In
this example side view below, @code{o} and @code{O} represent different
densities of cloud, and @code{-} is the tops and bottoms, while @code{^}
shows the ground.
@example
    ----     --  -
  --oOOo --  OO  o
  OOoOOo oo--OO  -
^^--oOO- --OO--
  ^ --- ^^^--  ^^^^^
   ^^^^^   ^^^^
@end example
The chief effect of clouds is to prevent the viewing of units on the
other side of the clouds.

A game may also include wind.  Wind has a force and a direction for each
cell.  Wind affects the weather by causing clouds and storms to move
around.  Certain unit types, such as sailing ships and balloons, may
depend on the wind to be able to move around, and their speed will
depend on the direction they take with respect to the wind.

Games may assert that the playing area represents part of a sphere,
possibly tilted on its axis, and that poles and equator correspond to
various latitudes.  If the game allows temperatures to vary according to
the time of year and the latitude, you will have seasons.

@node Backdrop Economy, Backdrop Random Events, Backdrop Weather, Playing Xconq

@section Backdrop Economy

The economy in @i{Xconq} is based upon materials.  Games that do not
include any material types do not have any of the activities described
in this section.

@menu
* Material Consumption::
* Material Movement::
@end menu

@node Material Consumption, Material Movement, , Backdrop Economy

@subsection Material Consumption

Units consume their supplies, both in the course of existence, and by
motion/combat.  The rate depends on game and unit type; it consists of
an overhead consumed each turn without fail, and consumption for each
cell of movement.  The total is a max, not a sum, since units with a
constant consumption rate are not likely to need additional supplies to
move (consider foot soldiers who eat as much sitting around as they do
walking).  Supplies may also be consumed for production and repair,
again depending on game and unit types, but this consumption happens
during the build phase.  Consumption is not affected by the situation of
the consuming unit; armies in troop transports eat just as much as when
in the field.

@node Material Movement, , Material Consumption, Backdrop Economy

@subsection Material Movement

Excess production is discarded, unless it can be unloaded into the
producer's occupying units, or distributed to nearby units via
@dfn{supply lines}.  Supply lines automatically exist between units that
are close enough (as set by the game), and there is no need for explicit
manipulation.  Supply line length depends on the game and the units on
both ends, but is not affected by the intervening terrain.  Supply
redistribution does not account for special needs anywhere; it just
tries to utilize production excess.  The redistribution method is rather
adhoc; units try to get rid of all their excess supply, and try to take
up supply from other units within supply range.  Each direction is
controlled independently, so for instance airplanes can get
automatically refueled from a nearby city, but not from each other.  No
unit will transfer all of its supply via supply lines.  Normally units
in the same cell can exchange supplies, but some games can disable this
behavior (@code{out-length} < 0), so that explicit transfer using the
give and take commands is always necessary.

@node Backdrop Random Events, Scoring, Backdrop Economy, Playing Xconq

@section Backdrop Random Events

Some games may include @dfn{random events}.  These are usually rare, but
not always -- be sure you know the odds!

@menu
* Accidents::
* Attrition::
* Revolts::
* Surrenders::
@end menu

@node Accidents, Attrition, , Backdrop Random Events

@subsection Accidents

For some types of units in some types of terrain, there is a chance for
it to have an @dfn{accident} that wrecks or eliminates the unit
instantly.  This depends on both unit type and terrain type.  If the
accident occurs, the unit is wrecked or vanishes along with all its
occupants.  ``Wrecking'' and ``vanishing'' have separate probabilities.
Occupants may survive wrecking, but never vanishing.

@node Attrition, Revolts, Accidents, Backdrop Random Events

@subsection Attrition

@dfn{Attrition} is ``slow death''; it takes away some number of hit
points each time it occurs.  The rate of attrition depends on unit type
and terrain or transport type.  Very low attrition rates may only take
away one hp once in a while.

@node Revolts, Surrenders, Attrition, Backdrop Random Events

@subsection Revolts

In a @dfn{revolt}, the unit changes sides spontaneously, perhaps to
independence, perhaps to the side of a nearby unit.  Occupants will
change over if possible, or else escape if possible, or else be killed.
Any plans will be cancelled.

@node Surrenders,  , Revolts, Backdrop Random Events

@subsection Surrenders

@dfn{Surrender} is like revolt, but is always to the side of a nearby
unit that is capable of attacking and/or capturing.  The capturing unit
does not move.  Occupants of the surrendering unit also change over,
escape, or die.


@node Scoring, Playing in Realtime, Backdrop Random Events, Playing Xconq

@section Scoring

@quotation
Victory at all costs, victory in spite of all terror,
victory however long and hard the road may be;
for without victory there is no survival.
-- WINSTON CHURCHILL (1940)
@end quotation

Different games can have different ways for players to win or lose.
Some games may not have any scoring at all, while others have very
complicated formulas.  You should be aware of the scoring in effect
@emph{before} you start to play a game!

In @i{Xconq}, a game's @dfn{scorekeepers} define how scoring is to be
done.  Each scorekeeper tests some sort of condition and/or maintains a
numeric score.  Scorekeepers also define when they run (perhaps only
during certain turns or certain times within a turn) and which sides to
look at.  Each scorekeeper is independent of the others, meaning it only
takes one to decide if you win or lose.

In a game with many players, winning and losing can be a complicated
issue; read the conditions carefully.  A scorekeeper can also decide to
declare a game to be a draw and end it on the spot.

Once a side has won, it is out of the game.  Some scorekeepers only
allow one winner, others allow several; in those cases, the scorekeeper
will say what happens to the winning side's units.

Once a side has lost, it cannot be brought back into a game, even if
another side tries to give it some more units or otherwise to reverse
things.

It may also be possible to declare a draw, but all players still in a
game have to agree to this.  While human players just have to enter the
appropriate command (or answer appropriately when asking to quit the
game), AIs may not always be willing to go along, particularly if they
think they still have a chance to win.  If that happens, you must
continue on.  (Some cowards have been known to abort the program or
reboot the machine, in order to avoid an ignominious fate; unfortunately
@i{Xconq} is merely a program and cannot prevent such slimy tricks.)

Finally, some games may record everybody's final scores into a file.

@menu
* Last-Side-Wins Scorekeeper::  
* Occupation Scorekeeper::      
* Unit Count/Sum Scorekeeper::  
@end menu

@node Last-Side-Wins Scorekeeper, Occupation Scorekeeper, , Scoring

@subsection Last-Side-Wins Scorekeeper

The most common form of scoring in @i{Xconq} is called
@code{last-side-wins}.  It is basically a fight to the death; any side
that loses all of its units loses the game, and the last side with any
units remaining is declared the winner.  It is possible that more than
one side will lose all of its units at the same time, in which case
@i{Xconq} declares a draw.

Since this would sometimes lead to bizarre stalemates (a submarine could
hide at sea, thus preventing the side from losing, for instance), many
games also define @dfn{point values} for units.  In such cases,
@code{last-side-wins} makes a side lose when the sum of point values of
all its units is zero, and the interface will have some way to display
your current points.  By default, each unit of each type has a point
value of 1; many games will define point values that apply to all units
of the same type.  Some games may also define special point values for
individual units.

@node Occupation Scorekeeper, Unit Count/Sum Scorekeeper, Last-Side-Wins Scorekeeper, Scoring

@subsection Occupation Scorekeeper

Occupation means that you have one of your own units in or near a fixed
location or unit.

@node Unit Count/Sum Scorekeeper,  , Occupation Scorekeeper, Scoring

@subsection Unit Count/Sum Scorekeeper

This is a simple count of units, or else a summation of the values of
some property, such as hit points.

@node Playing in Realtime, Advanced Play, Scoring, Playing Xconq

@section Playing in Realtime

Some game designs define limits on the realtime duration of a game.  For
instance, the game might be set to end in one hour, a single turn might
be limited to always last at most 2 minutes, or your side might be
limited to 15 minutes of playing time, in the manner of a chess clock.
If such limits are in effect, your display should be able to show you
how much time you have left at any moment; pay attention!

When you run out of time, you are not automatically taken out of the
game, but you can no longer do anything with your units.  Units that
already have plans will continue to act on them.

The game design may give you a limited number of ``timeouts'' that you
can call to stop the clock.  The timeout ends when you order a unit to
do something.  Other sides will also be able to play while the clocks
are not running.

You can see what the limits are by looking at the ``game design'' node
of the online help.

@node Advanced Play, Playing Hints, Playing in Realtime, Playing Xconq

@section Advanced Play

This section covers additional features that may interest experienced
players.

@menu
* Mixing Game Modules::         
* Personalizing Your Side::     
@end menu

@node Mixing Game Modules, Personalizing Your Side, Advanced Play, Advanced Play
@subsection Mixing Game Modules

Some interfaces (such as those using Unix-style command lines) may let
you ask for more than one game design when starting up.  This is
sometimes useful, for instance, if you want to play on the
@code{steppes} world with a non-standard set of units; your command line
might look like @code{-g my-hacked-standard -g steppes}.  You can also
turn things around and load a file with your own changes after a
complete game, as in @code{-g gettysburg -g my-tweaks}.

Be aware, however, that this cannot be guaranteed to work always, since
the mixed-together game designs may have mutually conflicting
definitions, or interfere with each other in subtle or not-so-subtle
ways.  Just imagine the disaster if the world consists entirely of
terrain that is instant death to your initial units!  Worse, @i{Xconq}
may start up and run OK for awhile, then at the moment you're about to
win---the object that you must capture simply cannot be captured by any
unit at all.

So be careful about mixing designs!

@node Personalizing Your Side,  , Mixing Game Modules, Advanced Play

@subsection Personalizing Your Side

Many games will pre-assign your side's name, emblem, enemies, and so
forth.  However, many others allow you to change all that to suit your
tastes.

The name is a proper noun such as ``Poland'', the noun is what you would
call an individual, such as ``Pole'', the plural is for more than one,
and <adj> is the adjective for things on that side, such as ``Polish''.
The color scheme is a comma-separated list of color names, and <image
name> names some sort of image file (like a bitmap).

The image may be of any size and combination of colors, with the caveat
that it may not always work correctly.  For instance, two subtly
different shades may get fused into a single solid color.  The emblem
should also be small enough to fit reasonably into unit icons.  As a
rule, most national flags will fit into a 7x5 rectangle, and coats of
arms into a 7x9 region.  The color scheme should be useful by itself,
when the unit icons are too small to fit the emblem.

@i{Xconq} will not allow you to have the same name, color, or emblem as
another player in the same game.

The interface-specific side configuration uses the favored mechanism for
that interface (if one is defined).  You should check with the interface
documentation for more details.

@node Playing Hints, Problems and Troubleshooting, Advanced Play, Playing Xconq

@section Playing Hints

This section is a collection of bits of information and advice derived
from players' actual experience playing @i{Xconq}.

@menu
* Player Alliances::            
* Advantage Rounding::          
* Strategy::                    
@end menu

@node Player Alliances, Advantage Rounding, , Playing Hints

@subsection Player Alliances

Informal alliances frequently happen in games involving more than two
people, so I have a few words of advice.  First, an alliance between two
of the players is almost certain in a three-person game, and inevitably
results in the ``odd man out'' being quickly defeated.  In four-person
games, the alliances could be decided after looking at the map via a
command-line option such as @code{-v}, so that one pair is not
hopelessly separated.  Five or more players is going to be a
free-for-all of formal and informal alliances.  Some scenarios are
designed with a particular number of players in mind.

@node Advantage Rounding, Strategy, Player Alliances, Playing Hints

@subsection Advantage Rounding

When you set the advantage, @i{Xconq} multiplies the desired advantage
with the normal number of starting units, then divides by the default
advantage and ROUNDS DOWN.  This means that you might end up with a lot
fewer units than you thought.  For instance, suppose that you have a
game where each player starts with one large city and five towns, and
this is considered to be an advantage of 10, because one large city is
worth about as much as 5 towns.  Then if you select an advantage of 8,
and your opponent selects 14 (because you're a better player perhaps),
@i{Xconq} will give you 8/10 of the normal setup, which means four towns
and NO large city.  Your opponent will get 14/10 of the setup, which
works out to one large city and seven towns, which is really a 1 to 3
disparity, much more than the planned 4 to 7.  This is not a bug, just a
limitation of the method.

@node Strategy, , Advantage Rounding, Playing Hints

@subsection Strategy

The correct strategy for a game will depend on the game; some are
deliberately designed to encourage or even force you to adopt a
particular strategy.  In general however, classic principles of strategy
apply perfectly to @i{Xconq}.  First, the words of an ancient master:

@quotation
Generally in war the best policy is to take a state intact; to ruin it
is inferior to this.  -- SUN TZU
@end quotation

@quotation
Attack where he is unprepared; sally out when he does not expect you.
-- SUN TZU
@end quotation

@quotation
There has never been a protracted war from which a country has benefited.
-- SUN TZU
@end quotation

The most important consideration is to conceal your own forces and
movements as much as possible.  Decoys and feints are worthwhile, but
only if they don't draw critical strength away from your real purpose.

Don't rush to attack with weak forces.  Especially over long distances,
the defender has the advantage.  Wait until you have assembled enough to
take and hold a piece of territory, then allow some extra, just in case.

Have a plan, and have some contingency plans ready as well.

Be ready to take advantage of opportunities.

@node Problems and Troubleshooting, The Game Library, Playing Hints, Playing Xconq

@section Problems and Troubleshooting

This section describes some of the problems you might encounter,
and what to do about them.

@menu
* Errors and Warnings::            
* Cheating::          
@end menu

@node Errors and Warnings, Cheating, , Problems and Troubleshooting

@subsection Errors and Warnings

``Errors'' are fatal flaws.  @i{Xconq} must shut itself down in order to
prevent a bad situation from getting worse.  You may be able to save the
game, repair it, and restart it, but you must understand a good deal
about GDL and about how @i{Xconq} works.

``Warnings'' are advice that something is amiss, but that there is no
obvious reason to quit.

Any error or warning not listed below is almost certainly a bug, most
likely in a game design, but maybe in @i{Xconq}, and should be reported
as such.

@table @code

@item Can't find module @var{xxx} anywhere
This means that @i{Xconq} searched in the library locations it knows
and found no modules named @var{xxx}.

@item Module @var{xxx} could not be opened
This typically means that although the module was found, it could
not be opened; for instance, it might have been read-protected.

@item Too many players
Some game designs limit the number of players, and you asked for
more than that.  Ask for fewer.

@item Requested advantage is too (low, high)
The game design limits the range of advantages that you may request,
and you went outside that range.

@item Only @var{n} of the requested displays opened
(not the most useful message in the world - only document the
"xxx could not be opened" message?)

@item Need at least one display to run
@i{Xconq} is an interactive game; a game with no displays at all
is sort of pointless, eh?

@item Images were not found
A game design may not have had images defined for
all types of units and terrain.
@i{Xconq} will warn about this, then make up some (typically ugly)
default images itself.  Actual game play will be unaffected.

@item @var{xxx} color is way off on display @var{yyy}
It may be that a particular display and its software will not
have set up a color that matches what was requested (this can
happen in X, for instance).  This has no direct effect on game
play, but some of the players may have difficulty if, say,
their displays show several different terrain types as having
the same color.

@item Memory exhausted
Some @i{Xconq} games are exceedingly large and complex, and it is
not unusual that they will need more than that available RAM or
swap space.  This will typically occur during game setup, since
@i{Xconq} preallocates nearly all of the space it will need.
If you have no way to get more memory, you must choose a smaller
game.  You can make a given game smaller by choosing the ``See All''
variant (no need to record views for each side) or by having fewer
players and/or fewer AIs.  For instance, instead of playing against 7 AIs,
you can play against one AI with an initial advantage of 7.

@item Can't open statistics file @var{xxx}
(Obvious)

@item Can't open score file @var{xxx}
(Obvious)

@item Sides have undesirable locations
A game can specify how close and how far away each side should be from
all the others, and the kind of terrain each will start on.  If the
world is too small, or doesn't have the right kinds of terrain, then
@i{Xconq} will warn about this.  The game will still play normally, but
it may be grossly unfair, and if the sides start out hidden from each
other, it may be a while until it becomes obvious how unfair it really
is.

@end table

@node Cheating,  , Errors and Warnings, Problems and Troubleshooting

@subsection Cheating

The standard builtin AI @code{mplayer} does not cheat; it always plays
according to the same rules as you do.  This should be true of any AI in
@i{Xconq}.  If you have evidence that would seem to indicate that any AI
is using information it should not have, or is otherwise cheating, that
is a bug and should be reported.  Note that sometimes the AI is smarter
than you are, or moves more quickly; it may very well have spotted one
of your units and disappeared again without you noticing.

Cheating by human players is possible, though not easy.
For instance, a player could examine a saved game and learn all kinds
of things, perhaps even starting up a separate game from it.
As always, human ingenuity will defeat any purely technical defenses,
and the best way to forestall cheaters is to refuse to play with them.
If you suspect cheating, look at the game history and the final game
statistics for things that seem suspicious.

@node The Game Library,  , Problems and Troubleshooting, Playing Xconq

@section The Game Library

One of @i{Xconq}'s distinguishing features is its extensive game library.
The variety can be rather confusing; which game @emph{should} you be playing?

The following sections describe the games that appear in the games list
that is in the distributed library (these show up in the "New Game" dialog
in the Mac port, for instance).
Details of the
games may change from release to release, so treat this only as a guide.
Read the game's own instructions and notes for detailed information.

The library will generally include many game modules not listed here; in some
cases, the modules are supporting modules for other games, and not playable
on their own, while in other cases the game is still under development.
Because of this, you should be prepared to experience problems if you try
to play any module not on the games list.

@menu
* Generic Games::
* Ancient History::
* European History::
* American History::
* WWII::
* Empire-Building::
* Fantasy::
* Science Fiction::
* Miscellaneous Games::
@end menu

@node Generic Games, Ancient History, The Game Library, The Game Library

@subsection Generic Games

@i{Xconq} belongs to what one might call the ``Empire'' family
of computer games; players each start with a small country and
attempt to take over the world.  The available units, which
players must build for themselves during the game, are generally
modern military but somewhat abstract; armies, airplanes, battleships,
and suchlike.
The game designs in this category are just variations
on the theme, being more/less complex or faster/slower-paced.

@table @code

@item intro
This is a simple game designed for newcomers to @i{Xconq}.  The rules
are simple, the map is fixed, so it's not really very interesting once
you've learned how to play @i{Xconq}.

@item standard
The standard game is, well, the standard @i{Xconq} game.  It is by far
the most developed, tested, and polished.  You can enjoy @i{Xconq} for
years playing only this game and its variants.

@item classic
The standard game of version 7 has been enhanced to take advantage
of its new features, such as stacking, rivers, and roads, but if you
like the standard game of @i{Xconq} 5.x and want to continue with it,
@code{classic} is a very close approximation.

@item crater-lake
This is a classic of 5.x, so named because of the mountain ring
with lake in the middle.  The real notable feature of this is the
difficulty of mounting any offensive; this game has been
fought to a stalemate time and time again.

@item old-empire
Stroll down memory lane.  This is a workalike of the old simple
Empire game, complete with imbalance, slow pacing, and other problems.
Compare how it plays versus the standard game; the flaws should be
obvious.

@c @item earth-2deg, earth-1deg, earth-50km
@c The entire Earth, at scales of 2 degrees/cell, 1 degree/cell, and
@c 50km/cell, respectively.  This means that the areas are 180x64, 360x140,
@c and 800x320 cells in size, which makes for games that are simply
@c gigantic.

@end table

@node Ancient History, European History, Generic Games, The Game Library

@subsection Ancient History

@table @code

@item pelops
If you're a fan of ancient history, try this version of the
Peloponnesian War.  Although its game parameters need more work,
you can get some idea of the scale of the conflict.  This is
also a three-sided game, allowing for someone to play the Persians
and perhaps win by exploiting the Athenians and Spartans.

@item rom-civ-war
The Roman Civil War, played out on a very nice map of the Roman world.

@end table

@node European History, American History , Ancient History, The Game Library

@subsection European History

@table @code

@item voyages
This represents the Age of Discovery.

@item magellan
Attempt to re-create Magellan's voyage around the world.
Based on @code{voyages}.

@item 1756, 1757
These are renditions of the annual campaign seasons that made up the
Seven Years' War.

@item 1805
Napoleon's Austrian campaign of 1805, of which the battle of Austerlitz
proved to be the key action.

@item red-october
The Russian revolution.

@end table

@node American History, WWII, European History, The Game Library

@subsection American History

@table @code

@item gettysburg
This is a set-piece version of the Battle of Gettysburg, at the brigade
level with hourly turns.  The setup is very detailed, but the mechanics
too simple, which unfortunately allows some rather bizarre-looking
battles to develop.

@end table

@node WWII, Empire-Building, American History, The Game Library

@subsection WWII

The WWII games listed here are technical, detailed, and specialized to
particular time periods or scenarios.

@table @code

@item panzer
This is a fast-paced tactical Eastern Front game, similar to the board
games on the subject.  Features include strict line-of-sight (thus you
can hide behind hills and trees), ranged fire, and a wide assortment of
hardware.  It's not really very accurate, and it's stretching
@i{Xconq} to use it for a tactical game, but great fun anyway.

@item magnusvew
A large panzer scenario based on a Panzerblitz(tm) board game scenario
designed by Robert Harmon.

@item cherbourg, cobra, normandy
These are all battalion-level games using the base game @code{ww2-bn}.
The @code{cherbourg} scenario covers the capture of Cherbourg in the
Normany campaign, while @code{cobra} is a reenactment of Operation Cobra,
and @code{normandy} is the whole invasion!  While @code{cherbourg} is
reasonably sized, the others are monster games that will need lots of
memory and lots of time to play.

@item nw-europe
This game is at the division level, being about the entire
NW Europe campaign.  Although you can open by landing in Normandy,
you can try invading anywhere you like.

@item ww2-eur-42
This is a theater-level simulation of WWII in Europe, starting in
January 1942.  The Germans are on the ascendant everywhere, the Soviets
hard-pressed, and the Americans only just getting involved.  The game
has a lot of sides; either AIs have to play them or you'll need to round
up a bunch of players.

@item ww2-38, ww2-39, ww2-42
These are full global scenarios for advanced WWII.  Can they really be
played as games?  Probably not -- but so what, we just want to scroll
around and admire it all!

@item ww2s-eur-42, ww2s-pac-41, ww2s-42
WWII again, but using the unit types and terrain of the standard game,
and with only two sides, Axis and Allies.  It's not realistic enough
for purists, but can certainly be exciting to play.

@item flattop
This game is a somewhat abstract version of tactical naval combat.
You have a force of carriers and battleships, plus a contingent
of smaller vessels, and a similar opposing force somewhere out
there.  Use your PBYs to find them, before their subs and destroyers
get in to sink your capital ships.

@item coral-sea
This is the battle of the Coral Sea, both land and sea, at the operations
level.  Airplanes are simply part of carriers' combat abilities.

@c @item midway
@c The Battle of Midway.

@item gazala
The battles around Gazala and Tobruk in North Africa.  The Axis is out
to capture Tobruk, the British have to block them with very few units.

@end table

@node Empire-Building, Fantasy, WWII, The Game Library

@subsection Empire-Building

The games in this category include more economic development than the
combat oriented generic games.

@table @code

@item empire
An Xconqification of ``true'' or ``net'' Empire, which is a large and
complex economic/military game.

@c @item modern
@c Stan's conception of modern times.

@end table

@node Fantasy, Science Fiction, Empire-Building, The Game Library

@subsection Fantasy

Although @i{Xconq} was never designed for the swords&sorcery genre,
it turns out to be able to support some rather interesting games.

@table @code

@item cave
A basic dungeon game, where you wander around a maze, collect
valuable items, and battle various monsters.

@c fantasy

@c wizard

@end table

@node Science Fiction, Miscellaneous Games, Fantasy, The Game Library

@subsection Science Fiction

@i{Xconq} was never really designed for outer-space games either,
but there are some fun if unrealistic designs.

@table @code

@item galaxy
A sort of generic outer space game with units mixed from various
fictional universes.

@item tokyo, monster
Inspired by a description of an old board called ``Crush Crumble and Chomp'',
this is a game featuring one side as Godzilla and the other side as Tokyo.
Hard to say whether it's more fun to play Godzilla and stomp on buildings,
or to play the national guard and try to defeat him before Tokyo is
entirely flattened!

If you ask for just @code{monster}, you will get a randomized setup for
this game.

@c postmodern

@end table

@node Miscellaneous Games, , Science Fiction, The Game Library

@subsection Miscellaneous Games

Some games just don't fit in any category.

@table @code

@item beirut
A somewhat disrespectful rendition of the fighting in Beirut during the
early 1980s.  Seven different sides, all fighting each other with tanks,
death squads, and car bombs.

@c @item duel
@c Two tanks, small area, no tricks.

@c @item hill
@c Play the children's game ``King of the Hill''.  As an early tester said,
@c ``Man, I figured you must have been on some really good drugs!''

@item insects
This is a silly but amusing game involving various kinds of insects.

@item mormon
This is a downright blasphemous version of the heroic age of the Mormon
pioneers in Utah.  The Mormons try to reproduce faster than the US
Cavalry and the Ute Indians can massacre them; to strike back, the
Mormons have their Avenging Angels.

(I can do this, I'm descended from Mormon pioneers. -sts)

@c @item time

@end table