\input texinfo
@setfilename xconq.info

@c @set DOUBLEDENSITY
@clear DOUBLEDENSITY

@settitle Xconq
@setchapternewpage odd

@ifinfo
This file documents how to play the strategy game @i{Xconq}.

Copyright (C) 1987-1989, 1991-2000 Stanley T. Shebs

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).
@end ignore

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
section entitled ``GNU General Public License'' is
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that the section entitled ``GNU General Public License'',
and this permission notice, may be included in translations
approved by the Free Software Foundation instead of in the original
English.
@end ifinfo

@c This is one way to make a double-density printout.  Another
@c way is to use the mpage utility on postscript.
@c
@c @ifset DOUBLEDENSITY
@c @iftex
@c @magnification = 833
@c @smallbook
@c @c from @afourpaper:
@c @global@tolerance=700
@c @global@hfuzz=1pt
@c @setleading{12pt}
@c @global@parskip 2pt plus 1pt
@c @global@vsize= 65@baselineskip
@c @advance@vsize by @topskip
@c @global@hsize= 20cm
@c @global@outerhsize=@hsize
@c @global@advance@outerhsize by 0.5in
@c @global@outervsize=@vsize
@c @global@advance@outervsize by 0.6in
@c @global@pagewidth=@hsize
@c @global@pageheight=@vsize
@c @end iftex
@c @end ifset

@titlepage
@sp 6
@ifhtml
<h1>
@end ifhtml
@center @titlefont{Xconq}
@ifhtml
</h1>
@end ifhtml
@sp 4
@ifhtml
<h3>
@end ifhtml
@center The School for Strategy
@sp 4
@center Version 7.4
@sp 4
@center December 2000
@sp 5
@center Stanley T. Shebs
@ifhtml
</h3>
@end ifhtml
@page
@iftex
@vskip 0pt plus 1filll
@end iftex
Copyright @copyright{} 1987-1989, 1991-2000
Stanley T. Shebs

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
section entitled ``GNU General Public License'' is
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that the section entitled ``GNU General Public License'',
and this permission notice, may be included in translations
approved by the Free Software Foundation instead of in the original
English.
@end titlepage

@iftex

@headings off
@everyheading @thistitle @| @thischapter @| @thispage
@everyfooting Version 7.4 @| December 2000 @| (printed @today{})

@end iftex

@ifinfo

@node Top
@top Top

@menu
* Xconq::			General information about Xconq.
* Quick Start::			A basic description of how to play.
* Playing Xconq::		Complete information for players.
* The Game Library::		Descriptions of games in the library.
* Common Interface::		How to play the common interface.
* Unix/X11 Xconq::		Details specific to Unix/X11.
* Windows Xconq::		Details specific to Windows.
* Mac Xconq::			Details specific to Macintosh.
* Other Interfaces::		Details of other interfaces.
* Troubleshooting Xconq::	Guide to problem handling.
@c the blank line below seems to be needed with RH 4.0

* Glossary::
* License::
* Index::
@end menu

@end ifinfo

@node Xconq

@chapter Xconq, the School for Strategy

Welcome to @i{Xconq}!

@i{Xconq} is a powerful multi-player strategy game system.  With
@i{Xconq} you can build empires, fight wars, relive history, and
adventure across fantastic worlds.  You can play computerized board
games, or be Godzilla rampaging through Tokyo.

@i{Xconq} runs on many computer systems.  It includes user interfaces
for Unix/X11 systems, Apple Macintosh, and PCs running Windows 95/98/NT.
Although all share the same basic design, the ``look and feel'' of each
interface matches the system you're on.  The details of an actual
@i{Xconq} game depend heavily on its @i{game design}, which defines the
pieces in the game and the rules of play.  So, to understand everything
about a game you're playing, you need both this manual, and
documentation for the game design in effect.  While this seems like a
lot, most games don't use every feature of @i{Xconq}, and the game
program itself includes plenty of online guidance.

@menu
* About This Manual::		Roadmap to the rest of the manual.
* Compatibility::               Compatibility with older versions.
* Additional Resources::	How to find more information.
* History::			A brief recounting of Xconq's evolution.
* Acknowledgments::		Credits and contributors.
@end menu

@node About This Manual
@section About This Manual

This manual is for @i{Xconq} players.  It discusses general principles
of @i{Xconq} play, the details of specific platforms, and games in
the game library.

@c should add refs to other chapters

The remainder of this chapter discusses compatibility with older
versions of @i{Xconq}, and additional information resources.

@node Compatibility
@section Compatibility

@i{Xconq} version 7 is not directly compatible with any previous version
of @i{Xconq}, although most of the basic game concepts remain unchanged.
If you've played @i{Xconq} before, you should have little trouble
getting used to the differences.

If you've designed any games (periods, maps, or scenarios) for version
5, you will discover many changes.  Version 5 of @i{Xconq} used a mix of
crude fixed-format syntax and a simple postfix language for game designs
(which were then called ``periods'').  This version has changed too
radically to be able to read any of the old period, map, or scenario
files.  In fact, version 7 eliminates the formal distinctions between
``period'', ``map'', and ``scenario''.  Therefore, if you have old
@i{Xconq} files, you should invest the time to convert.  You may even
discover that some of the new features of @i{Xconq} provide a better
solution to your design problems.  (The shell scripts @code{per2game},
@code{map2game}, and @code{scn2game} will help you get started on
conversion; you can find them in the @code{misc} directory.)

@node Additional Resources
@section Additional Resources

You are encouraged both to modify any of the existing game designs and
to develop your own.  The manual ``Designing Games with Xconq'' includes
a comprehensive tutorial on how to do this.  The version 7 game design
language (GDL) is better-designed and more robust than the machinery in
version 5, so if you've been discouraged by mysterious problems before,
you might want to try designing with version 7 instead.

The ftp server @code{sources.redhat.com} usually has the latest
version of @i{Xconq}, along with other contributed material, in the
directory @code{pub/xconq}.  The directory @code{pub/games/xconq} on
@code{ftp.uu.net} has long had @i{Xconq} material, although it is
generally for version 5.  Other servers also have copies of @i{Xconq}.

@node History
@section History

By now @i{Xconq} has accumulated some history, and confusions have
arisen about it.

I started @i{Xconq} in the summer of 1986, partly motivated by the lack
of sources to the simple two-player Empire that came with VAX/VMS, and
partly to experiment with fractal terrain generation.  I got this
version working under curses, then added a simple graphical interface
using X10 on HP workstations.  Since X allowed a single program to open
windows on several displays, I made it multiplayer that way.  This
version appeared in @code{comp.sources.games} in July 1987.  It used
squares rather than hexes, allowed only one-at-a-time play, and had only
three games (@code{standard}, @code{napoleon}, and @code{greek}), each
of which was a set of compiled-in structure definitions.  Even in this
simple form, @i{Xconq} met with an enthusiastic response from the
then-tiny number of people who used X.

After much hacking to use hexes, to add a postfix language for defining
games, and to allow simultaneous play (each of these changes were to be
versions 2, 3, and 4, but none were released to more than a few people),
I released 5.0 in July 1988.  This version also had an X11 interface
written by Chris Peterson at MIT.  5.1 was a bugfix release in August of
the same year.

August 1988 was also when I graduated from Utah and went to work as a
research scientist at Apple, and @i{Xconq} work languished.  I did spend
some time on a true client/server version of @i{Xconq}, and got it to
work after a fashion, but it was very slow, buggy, and complex, so I
abandoned it.  About this time a version 5.3 appeared on the net (author
unknown), then Greg Fisher at Rutgers took it up and did more work,
releasing as 5.4 around May 1991.

At about the same time as 5.4, I had started my own major development,
which was originally just to port to the Mac, and to make the design
language Lisp-like rather than Forth-like.  When it became clear that
this was going to be a big project, and that accumulated smaller changes
and fixes ought to be released first, I put out 5.5 in May 1992, mostly
by incorporating bits from others, notably Robert Forsman.

While I was off in a corner hacking, others released their own versions;
Alain Brossard released a 6.0 with some interesting features, if not
major changes (thus my new version had to be 7.0 instead of 6.0), there
were minor releases 5.5.1 and 5.5.1a, and a 5.6 by Mike Peters in April
1995 that included a Motif interface.

Version 7.0, with both Mac and X11 versions, appeared in August 1995,
with a 7.0.1 shortly afterwards.  7.1 came out in April 1996.  In
between these, there were a number of development snapshots with numbers
like 7.0.91; these were not real releases, but intended for developers.
Some of these are still wandering the Net though.

Version 7.2 came out in April 1998, with followon point releases
7.2.1 and 7.2.2 in May and June, respectively.

Versions 7.3.0 through 7.3.3 came out in June 2000.

Version 7.4.0 came out in December 2000.

@node Acknowledgments
@section Acknowledgments

Since the first release of @i{Xconq} in 1987, it has benefited from the
work and ideas of literally hundreds of people, first at the University
of Utah, then worldwide.

Special thanks must go to Eric Muehle, a tireless source of ideas,
advice, and playtesting at Utah; Greg Fisher, who added many good things
to make 5.4; and Robert Forsman, who did a great deal of work for 5.5.
Eric Ziegast and Alan Clegg have been essential to maintaining the old
@i{Xconq} mailing list and archives at @code{ftp.uu.net}.

For version 7, Massimo Campostrini deserves special note for
contributing the PS printing code, X11 color image display code, X11 new
game dialogs, xshowimf, and a number of library modules, as well as many
other fixes and enhancements.

Hans Ronne contributed extensive improvements to the Mac interface
starting with 7.2, including offscreen graphics, color controls, and
more preferences.  He is also responsible for the scientific advances
for scientific advances, for the advanced unit support, and many other
improvements.

Sami Perttu contributed a supply line model.

Erik Sigra contributed the Swedish place name generator.

Other contributors have been (in alphabetical order):
Jim Anderson,
Tom Baker,
Ed Boston,
Richard Braakman,
Mark Bradakis,
Alain Brossard,
Richard Buonanno,
Michael Burschik,
Germano Caronni,
Harold Carr,
Ben Chase,
Chris Christensen,
Kevin Deford,
Dan Dickey,
Fred Douglis,
Miles Duke,
Barry Eynon,
Doug Ghormley,
Thomas Granvold,
Stephen Griese,
David Harr,
Scott Herod,
Eiji(``A.J.'') Hirai,
Kurt Hoyt,
Jeff Kelley,
Bob Kessler,
Jim Kingdon,
Dan Koppenheffer,
Timo Korvola,
Jed Krohnfeldt,
Rick Ledoux,
Brian Lewis,
Sandra Loosemore,
Michael Lounsbery,
Antoine Makhlouf,
Steve McInerney,
Eric Mehlhaff,
Jimmy Miklavcic,
Tim Moore,
Scott Mueller,
Keir Novik,
Julian Onions,
Dave Pare,
Stephen Peters,
Chris Peterson,
Mohammad Pourheidari,
Dan Reading,
Cary Renzema,
Tom Richards,
Joel Rives,
David Ronis,
Jay Schuster,
Larry Schwimmer,
Jay Scott,
Jose' Manual Sebrosa,
John Shovic,
Josh Siegel,
Leigh Stoller,
Ravi Subrahmanyam,
Cimarron Taylor,
Spencer Thomas,
John Tonry,
Rich van Gaasbeeck,
Henry Ware,
Grant Weiler,
Jeff Young,
and many others.

Thanks to Tatu Rissanen and the FreeCiv team for the ``trident''
Civ image library.

The standard @i{Xconq} distribution includes several packages
incorporated more-or-less verbatim:
@i{Ad2C} script, by George Ferguson and others,
@i{SelFile} library, by Michiharu `NinjaTerm' Ariza and Erik M. van der Poel,
@i{Infinity Windoid} WDEF, by Troy Gaul,
@i{libcurses} library, by Larry Gensch and Robert Zimmerman,
@i{texi2html} script, by Lionel Cons,
@i{texinfo.tex}, by Robert Chassell.

Thanks also to the University of Utah, Apple Computer, and Cygnus
Solutions (now Red Hat), who have all contributed machine resources that
helped in the development of @i{Xconq}.

@node Quick Start

@chapter Quick Start

First, install the game according to the instructions for your system.
(These are to be found in the files @file{README} and @file{INSTALL}.)
@c add xrefs to platform-specific detail.

Double-click on the @i{Xconq} icon (all platforms) or type @code{xconq}
at a shell (Unix/Windows).  You get an initial screen with several
buttons.  Click on ``New''.  You get a screen with a list of available
games.  The ``Introductory'' game will be at the top of the list.  Click
on it, then click on ``OK''.  You may get a screen for variants, but if
you do, don't mess with these, just click ``OK'' again.  You then get a
list of sides and players; the default setup is correct already, so
click ``OK'' again.

After a short pause while @i{Xconq} sets up the game, you will get
one or more windows, depending on your system.  The big window is
the one to be interested in; it is a view of your new world.

It's also almost entirely black, representing the unknown.  In the
middle you should see a small picture of buildings, representing your
first town ``Jinod'', and right below a small picture representing the
soldiers of your 1st infantry unit.  Your infantry is framed by a
scrolling marquee, which indicates that it is your ``current'' or
``selected'' unit; the unit to which commands will apply.  Your units
are in a greenish hexagon, which is their ``cell'', and the cell is
surrounded on five sides by similar cells.  All of these represent
plains.  To the west there is a brownish patterned cell, which means
mountains.

When the mouse pointer is over the map, you see that it looks like a
gunsight with cross hairs.  (On the Mac, this is a small arrow that
always points away from the current unit.)  This means that you're in
``move mode'', and that if you click on any location, the unit will try
to move there.  This happens the same whether you click in an adjacent
cell or one far away, or even somewhere out in unknown regions.  Your
units are smart enough to find its way around some obstacles, and will
stop and let you know they need new orders if they are blocked.

Click on the cell east (right) of the town and infantry.  Hey, something
happened!  Your infantry is now out in the open, and it's discovered the
sea to the east and northeast.  At the same time, there is another
infantry inside the town, but it looks fuzzy; that's because it is
``incomplete''.  Your town Jinod will continue to work on the new
infantry while you move around.  Also note that the turn number is now
5, when it was 4 before.  An infantry gets to move once/turn, so when it
moved, it was done for the turn, and since there was nothing else to do,
@i{Xconq} automatically went to the next turn.  Your 1st infantry is the
only unit not doing something already, so it gets to be the current unit
again.

Your infantry can't go into the water (try it, you'll get beeped), so
instead click on the land cell to the northwest, then northeast, just
following the water's edge.  Click to move east; you then discover
another town!  While your own units have a little blue-and-white flag in
the upper right corner, this town (which is named Mebnels) has no such
emblem, which means that it is independent.  Since you want to save the
town from being taken over by the evil robots, try to capture it--just
click on the town.  The town, not knowing that your benevolent rule is a
better fate than being exploited by the evil robots, will try to resist.
If it's successful, you'll have to keep trying, once each turn.  Mebnels
may even destroy your infantry.

At some point during all this, you'll find that the current unit is no
longer your 1st infantry!  Jinod has been quietly working on your 2nd
infantry all along, and the new unit is now ready for orders.  @i{Xconq}
automatically jumps you to it when the 1st infantry is done for the
turn.  Click on the cell @i{immediately west of Mebnels}; you'll see
your 2nd infantry appear to jump two cells, then highlight the 1st
infantry (if the 1st is still alive, anyway).  What actually happened
was that you gave a ``move to'' task to the 2nd; it moved once, the turn
ended and a new turn started, the 2nd moved again because it wasn't at
the destination yet, and then since 1st wasn't doing anything, it became
the current unit.

Continue trying to capture Mebnels.  When the 2nd infantry arrives west
of Mebnels, you can click on Mebnels to have it attack there as well.
This is crucial, because the robots are coming@dots{}

In the turn after you've captured Mebnels, you'll see that Mebnels
itself becomes the current unit.  Towns can't move around, but they can
produce new units.  Choose ``Build'' from the Play menu, or type
@samp{P}.  You will get a prompt asking to choose from a list of
letters.  To see what they mean, type @samp{?}  to get an explanation.
You can choose by either clicking on the unit icons on the right side of
the window, or by typing one of the letters.  Armor is faster than
infantry and more powerful too, which will come in handy shortly, so
type @samp{a}.  You will see a small gray tank picture appear underneath
Mebnels' picture.

(On the Mac, you can either type as described above, or use the
construction window, which displays Mebnels on one side and a list of
unit types on the other.  Click on armor and then on ``Construct''.)

Continue moving your 1st and 2nd infantry east.  When you get your 3rd
infantry, click anywhere near the location of your 1st or 2nd infantry.
The 3rd will work its way up to the others eventually.

Some time about now you'll start seeing units or towns with the red X
of the robots.  Those are the enemy; attack!  As with Mebnels, you just
have to click on the enemy unit when your current unit is adjacent to
it.  Keep an eye on the notices window/pane, it will tell you about
how the fighting is going.  You'll also see some flashing on the units;
bigger means more damage.  If one of the units disappears, that will
be because it was destroyed.

Since this game is so simple, there is not a lot of strategy to winning
it.  You need to capture as many towns as possible (search around your
first town Jinod to find others to help you build units), and you need
to wear down the enemy by capturing its towns.  Eventually either the
AI will dominate and eventually wipe you out, or you will defeat all its
armies and capture all its towns.  The AI does not cheat, and doesn't
get any special advantage, so if you lose to a mere machine@dots{}


@node Playing Xconq

@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}.

@cindex Interface
The term @dfn{interface} refers to the particular graphical user
interface in use.  Examples include X11, Windows, Macintosh, and curses.
Interfaces can vary radically from each other, since each is designed to
be best suited for its environment.  However, 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 too.

@cindex Game design
When reading this chapter, you should be aware that @i{Xconq} allows for
many different kinds of @dfn{game designs}, which are the set of rules
and definitions for a game.  The range of possibilities is so broad that
for any particular game, some of the information in this chapter will be
irrelevant to it.  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.  For instance, wind does not play a part in the
standard game, so all the information in here about wind doesn't apply.
But, it's an option (variant) in the ``voyages'' game, and very
important when it's enabled, because it governs how fast and in which
directions your sailing ships can move.

@menu
* Setting Up A Game::		How to choose options for a new game.
* Starting Play::		
* Getting Help::		How to use the help system.
* Worlds and Areas::		Concepts relating to the terrain.
* Units::			Details about units in the game.
* Materials::
* Advances::
* Sides::
* Moving the Units::		What you can do with your units.
* Automating the Units::	How to avoid doing everything.
* Modes::			Description of survey and move modes.
* Standard Keyboard Commands::	List of all the commands available.
* Unit Info::
* Weather::
* Economy::
* Random Events::
* Scoring::			How you win games.
* Playing in Realtime::
* Advanced Play::
* Playing Hints::
@end menu

@node Setting Up A Game
@section Setting Up A Game

@cindex Setting up a game
The details of setting up a game depend on what kind of system you're
using, although it will usually be a series of dialogs.  Consult the
appropriate chapter for more details.

The remainder of this section describes the general process of setup
common to all interfaces.  Game setup is complex because @i{Xconq}
allows you to choose the networking, the game, its variants, and the
players, and many different combinations are possible.

@cindex Game
@cindex Game module
The first thing you do is to choose the game.  The standard @i{Xconq}
game library has many different game modules from which to choose,
and there are more to be found on the net and elsewhere.

The game that you choose may 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.

@cindex AI
@cindex Artificial intelligence
@cindex Mplayer
@cindex Player
In addition, most games also give you a choice of which @dfn{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.

@c add a generic example here?

@cindex Advantage
Some game designs provide a way to balance things if the players are of
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.

@cindex Trial player setup
@cindex Synthesis methods
In networked games, the process of agreeing on a player setup may take a
while.  However, this is still only a @dfn{trial player setup}; once it
has been agreed upon, @i{Xconq} runs @dfn{synthesis methods}.  The
synthesis methods of a game design tell how 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
player positioning rules are 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 game setup succeeds, @i{Xconq} will try to open up displays for
every player that wanted one.  Once all the players are in, @i{Xconq}
will start the game for real.

@cindex Icons
@cindex Images
@cindex Patterns
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{Troubleshooting Xconq} describes more of the errors and
warnings that you may encounter, and what to do about them.

@node Starting Play
@section Starting Play

@quotation
Cry ``Havoc!'' and let slip the dogs of war.  --WILLIAM SHAKESPEARE
@end quotation

What you'll first see depends on the interface you're using, but
typically there will be some sort of map or view of the world.  Help is
available by typing @code{?} or clicking on a button or menu item that
says @samp{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.)

@cindex Backdrop
@cindex Turns
@cindex Units
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.

@cindex Scorekeepers
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, the game is an ``interactive experience'' where 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
@section Getting Help

@cindex Getting help
@cindex Help
@cindex Help nodes
@i{Xconq} includes extensive online help.  The keyboard command @samp{?}
is available in all versions; some interfaces 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.  The topics include information about
commands, the game overall, individual units, scientific advances, and
so forth.

@node Worlds and Areas
@section Worlds and Areas

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

@cindex Area
@cindex World
In @i{Xconq}, the @dfn{world} is always a sphere.  You 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.

@cindex Area height
@cindex Area width
@cindex Cells
@cindex Hexagon
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.  You can ask for areas down to 10x10
or less, or up to 1000x1000 or even more, but 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!  For most games,
an area from about 60x30 up to 100x60 is about right.

@cindex Circumference
@cindex Cylinder shape
If the area's width matches the @dfn{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

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

@cindex Edge cells
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 they're leaving the area entirely.  (Most games don't
allow this though; an army up against the edge cannot escape its fate.)

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

@cindex Terrain subtypes
@cindex Cell terrain
Terrain comes in several subtypes; it 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.

@cindex Border terrain
A @dfn{border} is the boundary between two adjacent cells; it has a
distinct terrain type, such as ``river'' or ``beach''.  There may be
more than one type of border between two cells.  Units moving into a
cell will be affected by all borders while crossing them.

@cindex Connection terrain
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; possibilities include roads, railways,
or canals.  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 is usable as a bridge.  You may also find more than
one type of connection 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 prefer.

@cindex Coating terrain
A @dfn{coating} is a sort of modifier, like snow or mud; 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 each 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.

@cindex Elevation
In some games, each cell has an @dfn{elevation}, which is normally
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.

@cindex Control
@cindex People
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, when occupying a cell, will cause the
people's side to change to match their own.  Cells may also be under
@dfn{control} by a side, which may not be the same side as the people!

@cindex Features
@cindex Geographical features
A world can have named @dfn{geographical features} (usually shortened to
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{to NW of Big
Round Top}.

@cindex Coordinate system
The coordinate system is ``oblique'', with the X-axis horizontal, and
the Y-axis almost 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.  In general
though, you won't need to keep track of numerical coordinates.

@node Units
@section Units

@cindex 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}.

@cindex Location
@cindex Occupant
@cindex Stack
@cindex Transport
Units have a @dfn{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 is called an @dfn{occupant} in a @dfn{transport}, even if the
``transport'' is a type that can never move.

@cindex Altitude
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.

@cindex Independent unit
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!

@cindex Unit name
@cindex Unit number
Units can have a name, full name, 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 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.

@cindex Hit points
@cindex Hp
@cindex Repair
@cindex Unit parts
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.  In some
games, you may be able to merge multi-part units into a single larger
unit, and detach part of a multi-part unit.  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).
@c explain part/hp relationship better

@cindex Supplies
@cindex Materials
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.

@cindex Action points
@cindex Acp
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}.

@cindex Combat experience
@cindex Cxp
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.

@cindex Wrecked type
@cindex Wrecks
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 continue to
occupy a wrecked transport with no problem, then nothing will happen to
it.

@node Materials
@section Materials

@cindex 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 Advances
@section Advances

@cindex Advances
Games that feature technological development may include the notion of
@dfn{advances}.  Advances range from ancient technologies or discoveries
such as pottery or horseback riding, through modern-day innovations
like jet engines, computers, and MTV (OK, maybe not MTV), and into
future advances such as limb regeneration or faster-than-light travel.

You achieve an advance by acquiring any prerequisite advances, then
having your side or individual units do research on the desired advance.
Advances may be prerequisites to unit construction, and/or to other
advances.

@node Sides
@section Sides

@cindex Side
Each player in @i{Xconq} runs a @dfn{side}.  The concept of a 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.  Sides often
represent countries, but not invariably; they may be factions,
governorships, or alliances, or just a convenient division of the game's
units.

@cindex Players
It is important to be clear about the distinction between 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 a player, but in one game you may play the Canadian
side, and in another the Klingon side.  During a game, there will always
be a side for each player, and vice versa.  The distinction is most
important during game setup and restart of saved games, since that is
when you can choose which players go with which sides.

@cindex Emblem
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::	Different kinds of side relationships.
* Using Agreements::
* Tech Levels::			Usage of tech levels.
* Side Research::		How to acquire advances through research.
* Side Classes::
* Self-Units::
@end menu

@node Interaction Between Sides
@subsection Interaction Between Sides

In games with two players, your interaction is usually pretty simple,
@i{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.

@cindex Trust
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.

@cindex Side control
@cindex Releasing a side
You can make your side be @dfn{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
@subsection Using Agreements

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

@cindex Agreements
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
@subsection Tech Levels

@cindex Tech level
@cindex Tech
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 development and espionage.

@cindex Tech to build
@cindex Tech to own
@cindex Tech to see
@cindex Tech to use
There are several possible tech thresholds for each type of unit.  First
there is @dfn{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 a @dfn{tech to own} that
you must have in order for a unit to be on your side and get the benefit
of its eyes and so forth.  After that there is a @dfn{tech to use},
which you must have in order to make the unit do any actions.  In order
to build a unit, you need to have achieved the @dfn{tech to build}.

@node Side Research
@subsection Side Research

@cindex Side research
@cindex Research, side
Games may allow you to research advances using your side rather than
units.  For instance, Civ-type games work this way; your ``wise men''
work on an advance, without being associated with any specific city or
other unit.  If the game includes side research, the interface will
ask you which of several possible advances you want the side to
research.  You can also ask not to research, perhaps if you want to
conserve resources consumed by research.  Once a topic is chosen,
the research runs automatically until the advance is achieved, at
which point @i{Xconq} announces the advance and asks you what you
would like to pursue next.

@node Side Classes
@subsection Side Classes

@cindex 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 sufficiently high tech level.)

@node Self-Units
@subsection Self-Units

@cindex Self-unit
A @dfn{self-unit} is a unit 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'' 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.  In any, the game will define which types may be
self-units.

@node Moving the Units
@section Moving the Units

@cindex Moving
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; for instance, you may
be required to move all your aircraft before any ships can move.

@menu
* Turn Setup::
* Types of Actions::
* Movement::			Different ways for units to move.
* Combat::			How units fight each other.
* Research::
* Development::
* 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
@subsection Turn Setup

@cindex Action points per turn
At the beginning of each turn, @i{Xconq} computes the number of action
points available to each unit.  Each unit gets a certain number of
action points each turn.

Normally, each of your units gets its action points, uses them up during
the turn, and must stop doing anything when no action points are left.
However, some unit types may have a minimum ACP below 0, and/or a
maximum that is greater than the number gotten each turn.  You can use
this extended 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
@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.
Fire, using either a given material as ammunition, or using any
available material.  (@code{fire-at})

@item
@i{Fire into} a given location.
Fire at no unit in particular, using either 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{Develop} a given unit type.
This increases the tech level for the type being developed.
(@code{develop})

@item
@i{Tool up} to build a given unit type.
This increases the tooling points for the construction of a 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.
The part goes 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{Extract} a given quantity of a given material type from a given location.
(@code{extract})

@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
@subsection Movement

@cindex 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.

@cindex Enter transport
@cindex Ferry
The other kind of movement action is to enter a transport.  The only
argument is the unit to enter, but again the constraints may be
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.

@cindex Movement points
@cindex Mp
@cindex Speed
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.

@cindex Leaving the world
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.

@cindex Border slide
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
@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

@cindex Combat
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 something at a target.

@cindex Attack
@cindex Overrun
@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.

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

@cindex Fire
@cindex Firing at units
@cindex Firing into cells
@dfn{Firing} can happen at long ranges, up to a maximum range for each
type can that can fire.  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 minimum
range and cannot fire at anything that is closer than that range.
(ICBMs and some kinds of artillery are limited in this way.)

@cindex Capture
@cindex Capturing units
Some units are capable of @dfn{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.  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.

@cindex Detonation
@dfn{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
@subsection Research

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

Individual units may perform @dfn{research} to achieve advances.

@node Development
@subsection Development

@quotation
Genius is 1% inspiration and 99% perspiration.  -- THOMAS EDISON
@end quotation

@cindex Development
@cindex Tech development
@cindex Tech crossover
@dfn{Development} increases a side's tech for the unit type being
developmented.  Although your unit can only develop one specific type of
unit at a time, 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 developer unit working on the same type, and
thereby speed up your progress, but note that some games put a ceiling
on how much progress you can make in one turn.

Development is different from research in that its goal is to enable the
ability to see or work with a specific type of unit, while research
achieves abstract advances.

@node Construction
@subsection Construction

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

@cindex Building units
@cindex Creating units
@cindex Construction
In some games, the construction of new units is an important part of play,
whether you're recruiting cannon fodder for the wars or building great
ships in a shipyard.

@i{Xconq} always uses units to perform construction.  It first checks
that the research, development, and tooling prerequisites have been met
(most interfaces will autom development and toolup actions if a unit is
told to build something that needs tech or tooling first).  Actual
construction of a unit happens in two steps; creation and building
towards completion.

@cindex Tooling
@dfn{Tooling up} prepares a unit to create or construct the desired
type.  As with development, 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.

@cindex Creation
@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
exactly 1 hp.

@cindex Completing units
@cindex Completion
You achieve @dfn{completion} by doing @dfn{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, some units will have a level
of completion past which the unit will start working on itself
automatically, and eventually become complete without you needing to
do anything else.

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.

@cindex Unit parts
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
@subsection Repairing Units

@cindex 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.

@cindex Hit point recovery
@cindex Hp recovery
Some games also feature automatic hit point recovery, so you don't
always have to remember to do explicit repair actions.

@node Disbanding Units
@subsection Disbanding Units

@cindex 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.)

@cindex Recycling
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.  A percentage of the total
material will become available after each action, if disbanding takes
several actions to accomplish.

@node Transferring Unit Parts
@subsection Transferring Unit Parts

@cindex Multi-part units
@cindex 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
@subsection Changing Unit Side

@cindex Changing unit side
@cindex Giving units
@cindex Taking units
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
@subsection Changing Unit Type

@cindex 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.
@c how does this work? no i/f defined

@node Producing Materials
@subsection Producing Materials

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

@node Transferring Materials
@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
@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 Automating the Units
@section Automating the Units

@cindex Automation
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}, and the
@i{doctrine}.  These are related to each other by @i{goals}.

@cindex Unit task
@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.

@cindex Unit plan
@cindex Task agenda
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.

@cindex Doctrine
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.

@c mention when a strategy ever gets displayed
@c @cindex Ai strategy
@c The @dfn{strategy} and associated subobjects is what an AI uses to make
@c all the decisions about what to do.  This object is not directly
@c visible, unless the AI is acting as your assistant and the interface
@c 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 your
commands.

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

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

@node Doctrine
@subsection Doctrine

@cindex Doctrine
@cindex 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.  The game design oftens sets default values for doctrine, based
on what the designer thought would be convenient values.

@table @code

@item resupply
@cindex Resupply percent
This is the percent of supply at which a unit wakes up and wants to
return for resupply.  The default is usually around 50%, but for
instance aircraft that go all the way out to the halfway point will
sometimes be run out of fuel and be lost if they run into obstacles
(such as enemy aircraft).  If you want to be more conservative, set
the resupply percent to be, say, 60%.  Resupply applies to materials
that are part of base or movement consumption.

@item rearm
@cindex Rearm percent
This is similar to resupply doctrine, but applies to materials used
in combat, aka the ammo.

@item repair
@cindex Repair percent
This is the damage percentage at which the unit will wake up and
want to return for repairs.

@item run
@cindex Construction run
This specifies the number of a type of unit to build by default.  You
can override this by using a prefix argument to the build command.
@c should rename to build-run?

@end table

@node Plans
@subsection Plans

@cindex Unit plans
@cindex Plan types
The @dfn{plan type} of a unit's plan defines the unit's overall
class of behavior.

@table @code

@item none
Units with this type of plan do absolutely nothing.

@item passive
@cindex Passive plan
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 offense
@cindex Offense plan
Units with an offensive plan will look for favorable combat
opportunities, usually within an area specified as their goal to hold.

@item defense
@cindex Defense plan
Units with a defensive plan will seek to preserve the status quo.

@item explore
@cindex Explore plan
Exploratory units will seek to collect information about unknown parts
of the world.
@c what happens if world already known? announce that nothing left
@c to do?  check accomplishment of goal

@item colonizing

@item improving

@item random
@cindex Random plan
Units with a random plan will literally try to do anything.

@end table

@node Tasks
@subsection Tasks

@cindex Tasks
@cindex Unit 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 plan's 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.

@table @code

@item none
Do nothing.

@item sentry @var{turns}
Stand sentry at the present location for a given number of turns.  This
is not the same as sleeping, since the task is only for a definite
period of time, while a sleeping unit will sleep indefinitely.

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

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

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

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

@item build @var{unit-type} @var{n}
Build a given number of units of a given type.  This task will do
development 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 develop @var{unit-type} @var{n}
Do development to increase the tech for a given type up to a given
level.

@item hit-position @var{location}
Attempt to hit any units at the given position, using attack or fire
as appropriate.  The unit will move to get within range as necessary.

@item hit-unit @var{unit}
Attempt to hit a given unit.  The attacking unit will move to get within range as necessary.

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

@item resupply @var{material-type}
Resupply with the given material.  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 collect @var{material-type} @var{location}
Extract the given type of material from the given location (or nearby)
and optionally deliver it to a unit that can transfer it to the side's
treasury.

@item product @var{material-type}

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

@item disband
Disband self.  If a unit cannot disband itself with a single action,
this task runs the multiple actions necessary.

@end table

@node Standing Orders
@subsection Standing Orders

@cindex Standing orders
Standing orders are basically a combination of a test or condition and a
task to be performed when the condition is met.  Some interfaces may
provide a dialog to guide you through order setup, but all support the
textual form of the command, which is
@example
if @var{type} @var{test} @var{task}
@end example
where @var{type} is a name of a unit type, @var{test} is some sort of
condition, and @var{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.  The unit must be designated by name currently.

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
(@code{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 and third example commands show how you can use several
standing orders together to route units around obstacles or dangerous
areas.

@node Modes
@section Modes

@cindex Move mode
@cindex Survey mode
Interfaces to @i{Xconq} have 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
left-button mouse clicks change the focus and perhaps scroll the map,
but do not cause any units to do anything.

In move mode, a normal left-button click means to move the currently
selected unit (or units, if on Mac) to the location clicked upon.

In both modes, right-click will move the selected unit(s).

@node Standard Keyboard Commands
@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.

@c Include all the text describing the command.

@set FULL

@c Do this as an include, the same file goes into a cheat sheet also,
@c with FULL cleared.

@include commands.texi

@node Unit Info
@section Unit Info

@cindex Unit info, text
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}

@i{Xconq} keeps track of a unit's original side as well, and will report
that if it's different from the current ownership:

@code{your (German) city Berlin}

Next you will see the current values of the most important unit data.
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 terrain features at the location, plus elevation and temperature
if appropriate.  Names of geographical features, such as seas or
mountain ranges, may also appear here.

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.)

In both of these cases, the letter used is generally the first letter
of the type's name.  See the unit help to find a complete list of
which letters go with which unit types.

Unit info includes a list of all materials being carried as supplies, in
a straightforward form, current amount followed by maximum possible.

@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 Weather
@section Weather

@cindex Environmental effects
@cindex 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.

@cindex Temperature
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, season, and elevation.  Temperature may
also vary randomly from turn to turn and cell to cell.

@cindex Axial tilt
@cindex Seasons
Some games may define an @dfn{axial tilt} for the world.  If the game
allows temperatures to vary according to the time of year and the
latitude, you will have @dfn{seasons}.

Temperature may directly affect unit hp, acp, and supply consumption
rate.  A unit's transport or occupants may be able to reduce the
severity of these effects.

@cindex Clouds
A game may include @dfn{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  ooooo
  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.

@cindex Winds
A game may also include @dfn{winds}.  Wind has a force and a direction
for each cell.  Wind may affect the weather by causing clouds to move
around.  Also, 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.

@node Economy
@section Economy

@cindex 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 Production::
* Material Consumption::
* Material Movement::
@end menu

@node Material Production
@subsection Material Production

@cindex Base production
@cindex Material production
In many games, units 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.

Units may also be able to produce additional material by doing explicit
production actions.
@c add xref to the action

Another way to produce material is by extraction.
@c another xref

@node Material Consumption
@subsection Material Consumption

@cindex Consumption
@cindex 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 as
part of doing actions.  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
@subsection Material Movement

It is often the case the units will produce more material than they
can use.  In those cases, @i{Xconq} will attempt to distribute the
excess to nearby units.

@cindex Redistribution
This redistribution occurs automatically between units that are close
enough (as set by the game), and there is no need for explicit
manipulation.  This redistribution is not affected by the intervening
terrain.  Supply redistribution also 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, so that explicit transfer using the
give and take commands is always necessary.

@node Random Events
@section Random Events

@cindex 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
@subsection Accidents

@cindex 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, if they can escape and survive on the
underlying terrain, but if the unit vanishes, they automatically vanish
also.

@node Attrition
@subsection Attrition

@cindex 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.  When a unit reaches 0 hp because of
attrition, unit becomes wrecked(?), and any occupants have a chance to
escape.  You are not notified of hp loss due to attrition.
@c should add reporting as an option...

@node Revolts
@subsection Revolts

@cindex 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
@subsection Surrenders

@cindex 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, however.  Occupants of the surrendering unit may either
change sides also, escape, or die, depending on their types.


@node Scoring
@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

@cindex Scoring
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!

@cindex Scorekeepers
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, most types of games 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
@subsection ``Last Side Wins'' Scorekeeper

@cindex Last side wins
@cindex Scorekeepers
The most common form of scoring in @i{Xconq} is called ``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.

@cindex Point values
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, the
``last side wins'' rule 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
@subsection Occupation Scorekeeper

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

@c is this really implemented?

@node Unit Count/Sum Scorekeeper
@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.

@c is this really implemented?

@node Playing in Realtime
@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.

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

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

@node Advanced Play
@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
@subsection Mixing Game Modules

@cindex 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
@subsection Personalizing Your Side

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

@cindex Side name
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.

[ but none of the interfaces actually make all this work? ]

@node Playing Hints
@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
@subsection Player Alliances

@cindex Players 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
@subsection Advantage Rounding

@cindex 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 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
@subsection Strategy

@cindex 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 The Game Library

@chapter The Game Library

@cindex 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).  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.

At the end of each description the file name of the game module is
mentioned.

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

@node Generic Games
@section 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, with
different degrees of complexity and pacing.

@table @b

@item Introductory Game
This is a simple scenario designed for newcomers to @i{Xconq}.  The
world is small and unchanging, so it's not really very interesting
once you've learned how to play @i{Xconq}.  (@code{intro.g})

@item Standard Game
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.  (@code{standard.g})

@item Steppes
If you like land combat better than naval combat, steppes is just a
version of the standard game where all the cities are scattered over
featureless plains.  The rules of the game are as usual.
(@code{steppes.g})

@item Classic Xconq
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.  (@code{classic.g})

@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.  (@code{crater-lake.g})

@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.
(@code{old-empire.g})

@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
@section Ancient History

@table @b

@item Peloponnesian War
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.  (@code{pelops.g})

@item Roman Civil War
The Roman Civil War, played out on a very nice map of the Roman world.
(@code{rom-civ-war.g})

@end table

@node European History
@section European History

@table @b

@item Voyages of Discovery
This module lets you explore the world.  (@code{voyages.g})

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

@item Frederick, Europe 1756, Europe 1757
These are renditions of the annual campaign seasons that made up the
Seven Years' War.  (@code{fred.g}, @code{1756.g}, @code{1757.g})

@item Austrian campaign, 1805
Napoleon's Austrian campaign of 1805, of which the battle of Austerlitz
proved to be the key action. (@code{1805.g})

@item October Revolution
The Russian revolution.  (@code{red-october.g})

@end table

@node American History
@section American History

@table @b

@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 allows some rather bizarre-looking battles to develop.
(@code{gettysburg.g})

@end table

@node WWII
@section WWII

The WWII games listed here are technical, detailed, and specialized.

@table @b

@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.  (@code{panzer.g})

@item Panzers at Magnuszew
A large panzer scenario based on a Panzerblitz(tm) board game scenario
designed by Robert Harmon.  (@code{magnuszew.g})

@item Fall of Cherbourg
This battalion-level scenario covers the American VII Corps drive on
Cherbourg during the Normandy campaign.  (@code{cherbourg.g}, based on
@code{ww2-bn.g}).

@item Operation Cobra
This is a reenactment of Operation Cobra, also at the battalion level.
This is a very large game that will need considerable memory and time to
play.  It seems to be very difficult to break out and get to Avranches
in the allotted time; the game balance probably needs work.
(@code{cobra.g})

@item Normandy; 6 June 1944
An attempt to re-enact the whole Normandy campaign, from the beach
landings on.  (At present, this is really only interesting for the
initial invasion, since German reinforcement schedule is incomplete.)
(@code{normandy.g})

@item NW Europe Campaign
This game is at the division level, being about the entire ``Northwest
Europe'' campaign.  Although it works to land in Normandy, you can try
invading anywhere you like.  (@var{nw-europe.g})

@item WWII Europe Jan 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.  Keep an eye on your ground units' supply
situation!  (@code{ww2-eur-42.g})

@item WWII Jan 38
@item WWII Sep 39
@item WWII Jan 42
These are full global scenarios, using the ``WWII Advanced'' rules.  Can
they really be played as games?  Probably not, but it's fun to try; and
you can always just scroll around and admire it all!  (@code{ww2-38.g},
@code{ww2-39.g}, @code{ww2-42.g})

@item WWII (Std), Europe Jan 42
@item WWII (Std), Pacific Dec 41
@item WWII (Std), World Jan 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 very realistic, but
fun nevertheless.  (@code{ww2s-eur-42.g}, @code{ww2s-pac-41.g},
@code{ww2s-42.g})

@item Flattop Battles
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 aircraft get in to sink your
capital ships.  (@code{flattop.g})

@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.
(@code{coral-sea.g})

@item Midway
The Battle of Midway.  This is the whole battle at the operations level,
including maneuvers in the Aleutians.  (@code{midway.g})

@item Gazala Battles, 1942
The battles around Gazala and Tobruk in North Africa.  The Axis is out
to capture Tobruk, the British have to block them with a very few units
operating behind a belt of minefields.  (@code{gazala.g})

@c metz 1944

@end table

@node Empire-Building
@section Empire-Building

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

@table @b

@item Empire
An Xconqification of ``true'' or ``net'' Empire, which is a large and
complex economic/military game.  This game is very much incomplete.
(@code{empire.g})

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

@item Time: Combat Through The Ages
This game is similar to Civilization in that you try to develop your
technology as well as your empire.  (@code{time.g})

@end table

@node Fantasy
@section Fantasy

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

@table @b

@item Cave
A basic dungeon game, where you wander around a maze, collect
valuable items, and battle various monsters.  (@code{cave.g})
@c need to add to game list?

@c fantasy

@c wizard

@end table

@node Science Fiction
@section Science Fiction

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

@table @b

@item Galaxy
A sort of generic outer space game with units mixed from various
fictional universes.  (@code{galaxy.g})

@item Tokyo 1962
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!  (@code{tokyo.g})

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

@item Post-Modern
A post-apocalypse game where you can achieve some advanced technologies
starting from the ruins.  (@code{postmodern.g})

@end table

@node Miscellaneous Games
@section Miscellaneous Games

Some games just don't fit in any category.

@table @b

@item Beirut 1982
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.  (@code{beirut.g})

@item Insects
This is a silly but amusing game involving various kinds of insects.
(@code{insects.g})

@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.  (@code{mormon.g})

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

@end table


@node Common Interface

@chapter Common Interface

Both the X11 and Windows versions of @i{Xconq} use the same graphical
interface.  The following sections describe this @dfn{common interface}
screen by screen.

@menu
* Starting a Common Interface Game::
* Playing a Common Interface Game::
* Common Interface Menus::
* Common Interface Maps::
@end menu

@node Starting a Common Interface Game
@section Starting a Game

The common interface takes you through four dialogs or screens to set up
a game: the splash screen, the game load choice, the variant setup, and
the player setup.

@cindex Splash screen
The splash screen gives you four choices: ``New'', which brings up a
list of games; ``Open'', which allows you to pick a file; ``Connect'',
which allows you to join a network game, or start your own; and
``Quit'', which lets you escape.

Usually you will want to choose ``New'', which brings up a dialog
listing all the games.  You can select one and see a brief description
of it.

You can also load a game from a file by choosing ``Open''.  This just
uses a standard file-opening dialog.  You restore a saved game this way.

The use of ``Connect'' is described later.

You can use the ``Quit'' button at any time during game setup.

@menu
* Loading a Common Interface Game::
* Choosing Common Interface Variants::
* Common Interface Player Setup::
* Common Interface Final Setup::
* Common Interface Networked Game Setup::
@end menu

@node Loading a Common Interface Game
@subsection Loading a Game

Whether you've chosen to start a new game or load an old one, @i{Xconq}
will go through a loading process, which may take a while if the game is
large or complicated.

You may get some warning alerts, which are often benign (such as an
inability to find some images), but others are indicative of disaster
ahead.  If you see one and continue anyway, don't be surprised if the
game goes up in a cloud of smoke later!

@node Choosing Common Interface Variants
@subsection Choosing Variants

@cindex Variants
If the game includes any variants, you will then get a dialog with
assorted buttons and checkboxes to choose from.  For instance, some
games let you choose whether the whole world is visible when you start,
or what kind of scoring system to use.  (At present, there is no help
info for game-specific variants.)

Different games have different variants, but there are several used by
many games.

@cindex World seen
The ``World Seen'' checkbox, when set, makes the whole world seen right
from the beginning of the game.  This only affects the initial view, and
you will only see some types of units belonging to other players, such
as their cities, but not necessarily all types.

@cindex See all
The ``See All'' checkbox makes everything seen all the time, right down
to each occupant of each unit of each side.  This makes @i{Xconq} more
like a boardgame, where little or nothing is secret.

@cindex World size
The ``World Size'' button brings up a dialog that you can use to change
the dimensions of the world in everybody will be playing.  In @i{Xconq},
the available area of the world is either a hexagon, or a cylinder
wrapping entirely around the world.

@c Click or drag within the display
@c area of the dialog to select an approximate size, or type in the text
@c boxes.

You get the cylinder by setting the circumference equal to the width of
the area. See the generic player's info [where?] for more details about
world size and shape, and be aware that it's very easy to select a world
that is much too large for reasonable play (the default of 60x30 is a
medium-sized game; 200x100 is enormous!)

The ``Real Time'' button brings up a dialog that you can use to set
realtime countdowns.  You can limit both the total time allotted to a
game, to each turn, and/or to each side.

@node Common Interface Player Setup
@subsection Player Setup

The player setup window shows the sides that will be in the game and who
will play each side.  As with the variants, you will often just want to
accept it (click ``OK''), since the game's designer usually sets the
defaults reasonably.

If you want to change the setup, you first need to understand the
current set of sides and proposed players.  Each entry in the list of
sides starts off with the side's emblem (if it has one), followed by the
name of the side.  Then there is some information about the player, and
then the initial advantage for the player.  You, the person sitting in
front of the screen, is described as ``You'' [not currently for cif
though], while players that are actually run by the computer are
described as ``AI mplayer'', ``AI'' being short for ``artificial
intelligence'' (In some games, a player may be a specialized AI, named
@var{name}, in which case it will be described as ``AI @var{name}''.)

Most of the buttons along the side require you to have selected a
side/player pair.  Initially the first pair is selected.  You can select
any of the others by clicking anywhere in the box describing it, which
will be highlighted in response.

@cindex Advantage, adjustment
To adjust the advantage, click on the @samp{A+} and @samp{A-} buttons.
Keep in mind that the advantage is literally a multiplier, so setting
your advantage to three means that you have three times as many units to
control.  In single-player games against the mplayer AI, you will
generally want to dial up the AI's advantage, since it is probably not
quite as smart as you.

In games that allow you to have more than the default number of sides,
you can just click the @samp{Add} button.

@c remove button should work someday

The @samp{Side Name} popup menu lets you choose a different name and
emblem for the selected side.  This only works in games for which there
is a list of different possible sides.  The choice of side name and
emblem does not have any effect on game play.
@c but what if the side library included sides of different classes?

The @samp{Random} button just chooses a random new name for your side.

The @samp{Computer} button toggles the AI for that side.  You can add an
AI to any side, including your own.  You can also remove the AI from any
side; a side with no AI and no human player will just sit quietly and do
nothing throughout the entire game.  Units on the side will fight back
if attacked, just like any other units, but if you capture things like
cities, the side won't even attempt to take them back.
@c add xref to info about playing a side with an AI

If you don't like the side you're on, you can use the @samp{Exchange}
button to switch.  The ordering of the sides is fixed, so the exchange
just exchanges players between the currently selected side/player pair
and the next one.  It can take a little experimentation to get the hang
of using this, but you can generate any arrangement of players using a
combination of selection and exchange.

The @samp{Indep Units} button brings up an additional dialog that allows
you to choose how to handle the independent units in the game.  The
usual default is for the independent units to do nothing, but by
choosing the @samp{Units have AI} option for instance, independents will
be set up with a simplified AI (the @samp{iplayer}) that knows about
basic defense and such.  Experimentation with these options will yield
some unusual games, and is only recommended for the experienced player
looking for a change.

@node Common Interface Final Setup
@subsection Final Setup

When you have OKed all the setup dialogs, @i{Xconq} will finish setting
up the game.  For some games, this will take quite a while - @i{Xconq}
generates random terrain, positions countries so that they are neither
too close nor too far apart, and does many other things to set up the
game, so just kick back and wait.

Once everything is set up, @i{Xconq} then opens up a main map window.
The map shows you terrain with different patterns, and your playing
pieces (units) with small pictures.

Note that @i{Xconq} allows all players, including AIs, to start doing
things as soon as the windows come up.  You may even find yourself being
attacked before you know what's happening!  (This is a feature; the AI
isn't good enough to afford to give you any breaks...)

@node Common Interface Networked Game Setup
@subsection Networked Game Setup

@i{Xconq} uses a peer-to-peer networking strategy, which means that all
players in the game run their own copies of the full program; there is
no separate server program.

To set up a networked game, choose ``Connect'' from the initial setup
dialog.  This will cause a second dialog to appear.  This dialog is a
combination connection setup and chat dialog, similar to what some other
games call a ``lobby''.

The connection setup is at the top of the connect/chat dialog.  It
include text boxes to set the hostname and TCP port number.  The
hostname should be the name of the computer where the game will be
running.  The default port number of 3075 is standard for @i{Xconq}
games, but you may use any value (and will need to, if running multiple
games on a single machine).

Then you need to click on ``Host the Game'' or ``Join the Game''.  The
first player in the game should be the host.  Once the host button has
been clicked, the status display will say ``Accepting Connections''.
All the other player should edit their hostname boxes to specify the
computer on which the host is running, then click on their join buttons.
When the connection is successful, all players' chat areas will get an
announcement, and a prompt to type into the chat area.

The chat area allows players to discuss setup options and game play.  It
may remain up during the entire game, and may be also be closed and
reopened at any time.  Anything that you type into the chat area will
appear in other peoples' chat areas immediately, although on a separate
line so everybody's words don't get mixed up.

At this point the host may now choose New or Open as with a
single-player game.  When this happens, the other players' setup screens
are blanked, waiting for the host to choose a game.  When the host has
chosen, the game is loaded, then downloaded to all the other players.
(This is to ensure that all players are running with the same game
rules.)

When all downloads are complete, every person's setup screen will change
to variant setup.  At this point, any player can click on any variant to
change it.  However, only the host can OK the setup.  (The chat area may
prove helpful when arguing about the choice of variant---and the quit
button is always available too.)

When the variants are OKed, then the player setup screen comes up.
Again, all participants can select any of the side/player assignments,
and may click on any of the buttons, even if the side is not going
to be played by them.  But also again, only the host brings order
out of chaos by OKing the setup.

When each participant receives the host's OK for the player setup, the
map window comes up and play can begin.  At this point the host becomes
just another one of the players.  The host does remain pivotal though;
it does tiebreaking when two players try to do something at the same
time, and it holds the TCP channels open, which means that when the host
quits, the game cannot continue.  (A future version of @i{Xconq} may be
able to designate one of the other programs as host, and shift all the
connections over.)

@node Playing a Common Interface Game
@section Playing a Game

There are two basic modes of play: survey mode and move mode.
In move mode, @i{Xconq} automatically finds the next unit that
needs orders, gets it visible on your screen, and selects it for
you.  Then you can left-click on a destination or target, and the
unit moves there or attacks, whichever makes sense.  Move mode is
very fast to play, although the bouncing around from unit to unit
can be disorienting.  In this mode, the selected unit has a moving
marquee hightlighting it.

In survey mode, you click on a unit to select it, then right-click
on a destination to move it.  Then you have to find another unit
and do the same.  This mode is better for careful play, although
in a complicated game it can be difficult to find all the units
that can be moved.

Experienced players will usually shift back and forth between the
two modes.  For instance, you can start out in survey mode, move
all the units you can see in the sea, then switch to move mode,
which will find the nearest unit not moved and select it, then
switch back to survey mode to give it orders.

The selected unit is indicated by an outline box - solid black&white
lines to indicate that it can move, dark gray to indicate that it cannot
move, and gray to indicate that it cannot do anything at all (at least
during this turn; some types of units may only get to do something once
in a while).  If clicking on a unit image doesn't have any effect, then
it's not a unit that belongs to you.

Some games allow you to fire at units from a distance.  To shoot at
another unit, position the mouse over the desired target, type the fire
command `f', and the selected unit will attempt to fire.  If the target
is too far away, nothing will happen.  'f' can only fire at units that
you actually have under observation.  Use `Control-f' to fire into a
cell where you can't see anything.

To jump ahead to the next turn, do the menu command @samp{End This Turn}
or the key `return'.  You may have to do this if some of your units
still have action points, but not enough to do any of the things you
want them to do.

@node Common Interface Menus
@section Menus

This section describes all the menus in the common interface.

@menu
* Common Interface File Menu::
* Common Interface Edit Menu::
* Common Interface Find Menu::
* Common Interface Play Menu::
* Common Interface More Menu::
* Common Interface Side Menu::
* Common Interface Windows Menu::
* Common Interface View Menu::
@end menu

@node Common Interface File Menu
@subsection File Menu

The File menu includes the usual sorts of commands that all Mac programs
share.

@table @code

@item New Game...
Brings up the new game dialog.

@item Open Game...
Brings up a standard file dialog.  @i{Xconq} will assume the selected
file to be a game module and attempt to load it as such.

@item Connect
Use the Connect item to join in a game that is already running elsewhere.

@item Chat
In a networked game, this brings up the chat window.

@item Help
Brings up the help window.

@item Save
Saves the game to a file.

@item Save As
Saves the game to a file, with a name chosen from a dialog that pops up.

@item Preferences...
Brings up a dialog that you can use to select various options.
See below for more detail.

@item Print...
Prints the front window. [not implemented yet]

@item Resign
Offers your resignation.

@item Quit
Leaves @i{Xconq}.  If the game has not ended, you will be asked if you
want to save; if not, and the AI(s) don't want to quit, you may have to
resign in order to get out.

@end table

The Preferences dialog includes several screens of options you can set, the
specific screen being chosen from the list on the left side of the dialog.

The Map View group allows you to personalize your map windows.

@table @code

@item Power
This popup lets you select the default magnification of the map.

@item Grid
@item Coverage
@item Elevations
@item Day/Night
@item People
@item Control
@item Temperature
@item Winds
@item Clouds
@item Unit Names
@item Feature Names
@item Feature Boundaries
@item Meridians
@item AI Info
These items set the default values for the View menu's display controls.

@end table

The Fonts group gives you control over the size and appearance of the
text used in various windows.  The family and size popups list the
various options available.

The Imagery group control the more arcane aspects of display.

@table @code

@item Terrain Images
When enabled, map drawing will use cell-shaped images to draw the
terrain, if possible.

@item Terrain Patterns
When enabled, map drawing will use tiling patterns to draw terrain.

@item Terrain Transitions
When enabled, map drawing will ``fade'' different types of terrain into
each other.  This makes the map look more natural, but also takes longer
to draw.

@end table

@node Common Interface Edit Menu
@subsection Edit Menu

Note that there is no Undo.  Hey, this game is a life-or-death struggle,
and you may have noticed that you don't get an Undo in real life either...

@table @code

@item Cut
@item Copy
@item Paste
@item Clear
These are not currently enabled.

@item Select All
This is not currently enabled.

@item Design...
The Design item is for access to game designer tools.  You cannot use
these during a normal game; you will be asked to confirm that you want
to design, and if so, @i{Xconq} will change all windows appropriately
and bring up a special designer's palette.  This is a one-way activity;
once somebody in the game becomes a designer, all players will be
notified and computer-run players will no longer bother to play.  (In
case it's not obvious, this is because it's too easy to cheat using the
designer's powers.)

@end table

@node Common Interface Find Menu
@subsection Find Menu

This menu is for various kinds of searching.

@table @code

@item Previous
This item selects the previous unit that can do actions.

@item Next
This item selects the next unit that can do actions.

@item Next Occupant
This item selects the next occupant among the occupants of a unit or cell.
If the selected unit has occupants, then this command will select one of
those first, and if the selected unit is the last occupant, the the command
will select the transport; thus repeated uses of this command will eventually
cycle through all units at a single location.

@item Location...
This item brings up a dialog that allows you to type in a set of
coordinates or the name of a geographical feature, then scrolls the map
over to that location.  (This item is currently disabled.)

@item Unit by Name...
This item brings up a dialog that allows you to type in a name of a
unit, then scrolls the map over to that unit.  (This item is currently
disabled.)

@item Distance
This allows you to measure distances.  When you choose this item, a
cross-shaped cursor will appear, and when you click on the map, you will
get a notice about the distance (in cells) from the selected unit to the
point you clicked.

@item Current Unit
This item scrolls the map over to center on the selected unit.

@end table

@node Common Interface Play Menu
@subsection Play Menu

This menu is the main set of commands that you can give to individual
units.  When you specify one of these, the units affected will be
whatever is selected in the map window.

@table @code

@item Closeup
This item opens closeups (see below) of all the selected units.
(This item is currently disabled.)

@item Move To
This item moves the selected unit to the location specified by a mouse
click.

@item Return
@cindex Return
This item directs the selected unit to return to the closest place
where it can replenish supplies that have been used up.  If the unit
has been damaged, it will also look for places to get repairs.

@item Set Formation
@cindex Formation
This item directs the selected units to maintain their current positions
relative to a given ``leader'' unit.  When you choose this item, you will
see a cross-shaped cursor, and must click on the one of your units that
you want to be the leader.

@item Wake
@cindex Wake
Wakes up the selected unit.

@item Wake All
@cindex Wake
Wakes up all units at the selected unit's location, including all
occupants.

@item Sleep
@cindex Sleep
Puts the selected units to sleep indefinitely.

@item Reserve
@cindex Reserve
Puts the selected units into reserve for the remainder of the turn.

@item Idle

@item Delay
@cindex Delay
Delays the move of the selected units until all other units have moved.

@item Build
Asks you what type of unit you would like to build, and sets the
selected unit to the task of building that type.

@item Repair

@item Attack
Orders the selected unit to attack.  You will get a cross-shaped cursor
and must click on the target.  This is useful if the normal click-to-move
would cause the unit to enter or to stack with the target, rather than
attacking it.

@item Overrun
Orders the selected unit to attack all units in the designated cell.

@item Fire
This item commands the selected unit to fire at a given target
unit.

@item Fire Into
This item commands the selected unit to fire into a given cell,
regardless of whether any units are actually there.

@item Detonate
This item commands the selected unit to detonate.

@end table

@node Common Interface More Menu
@subsection More Menu

The ``More'' menu contains additional actions, typically those that you
will need less often.

@table @code

@item Give

@item Take
Make the selected units take supplies from their transports if possible.

@item Embark
This item commands the selected units to get into the nearest transport.

@item Disembark
This item commands the selected units to get out of their transports but
remain at the transport's location, if stacking rules allow.

@item Detach

@item Disband

@item Add Terrain
Make the selected units do terrain additions.

@item Remove Terrain

@item Plan Type

@item AI Control
This item toggles the AI's control of the selected unit.  By default,
when an AI is playing a side, it controls all units.  If you disable the
AI's control, then you can play the unit yourself.

@item Rename...
This item brings up a dialog that allows you to rename the selected unit.
If the ``Random'' button is enabled, then there is a random name generator
available for that type of unit, and you may click it repeatedly to get
different randomly-generated or -selected names to choose from.

@item Give Unit
This submenu gives you a list of sides to which you may give the selected
units.  If the side is grayed out, then the selected type(s) may not be
on that side.

@end table

@node Common Interface Side Menu
@subsection Side Menu

This menu is for overall control of the side you're playing.

@table @code

@item Closeup
This item will bring up a window that displays more details about a side.
[not implemented yet]

@item End This Turn
This item declares your movement for this turn to be over.  It is the same
as typing Return.

@item Move Mode

@item Survey Mode

@c @item Sounds
@c This item enables and disables sound effects.

@item AI
This is a submenu that lists the possibilities for AIs to run the side
for you.  Select the name of an AI to have it decide units' moves for
you.  If you select @samp{None}, then the AI will shut itself off and
return the units it was controlling to your control.

@item Doctrines

@item Message

@item Agreements

@c @item Rename Side...
@c This item brings up a dialog that allows you to alter the side's name,
@c the noun to be used to refer to units on that side, the side's emblem,
@c and so forth.
@c
@c The button ``Choose Randomly'' will run a random side name generator or
@c selector, if available.
@c
@c Note that while there is a side property ``Color Scheme'' that you may
@c edit, the Mac interface does not currently use the property in any way.
@c However, if you restore a saved game on another type of machine, whose
@c interface does use color schemes, then your choice in this dialog will
@c have an effect.

@end table

@node Common Interface Windows Menu
@subsection Windows Menu

This menu is for the creation and arrangement of windows.

@table @code

@item Scores
This item brings up a listing of your past games of this type and
how you did on them.  It will not include the current game until
it is over.

@item New Map
This item creates another map window.

@end table

@node Common Interface View Menu
@subsection View Menu

The View menu gives you control over the appearance of the window you're
currently looking at.

@table @code

@item Closer

@item Farther

[etc]

@end table

@node Common Interface Maps
@section Maps

@cindex Map window
@cindex Map
The main playing window of the common interface is called the @dfn{map
window} (or just @dfn{map} for short).  At present you can have only
one map window, but this will change.

@c re-add when multiple windows available
@c Each map window has identical capabilities, so you can play by using
@c just one, or have one for each area of interest, or have some of them
@c serve specialized purposes.  For instance, you can have a map window
@c that shows the entire world.

@menu
* Map Panes::
* Scrolling Maps::
@end menu

@node Map Panes
@subsection Map Panes

Each map window consists of a number of panes, whose size you may
adjust by dragging the small square grips that may be seen on the
the pane boundaries.

@example
----------------------------------------------------------
|                                     |    turn/date     |
|         notices/commands            |------------------|
|                                     |                  |
|                                     |      sides       |
|                                     |                  |
|-------------------------------------|                  |
|       |      mouseover text         |------------------|
|       |-----------------------------|                  |
|       |                             |                  |
|       |        unit info            |                  |
|       |                             |                  |
|       |-----------------------------|                  |
|       |                             |    unit types    |
|       |                             |                  |
| ctrl  |                             |                  |
| panel |                             |                  |
|       |                             |                  |
|       |         map view            |                  |
|       |                             |                  |
|       |                             |------------------|
|       |                             |                  |
|       |                             |                  |
|       |                             |    world map     |
|       |                             |                  |
|       |                             |                  |
----------------------------------------------------------
@end example
@c should prevent break across pages here

@cindex Map view pane
The @dfn{map view} is a detailed display of part of the world.  You can
view it at different magnifications, and can enable or disable the
display of various kinds of data, such as country borders or wind
direction.

@cindex Current unit
Each map window has one @dfn{current unit} (aka @dfn{selected unit}).
Both the map view and the world map highlight it specially, and the unit
info pane (see below) describes it in detail.  The current unit is the
one to which your commands apply; it will always be a unit that you
control.

@cindex Unit info pane
The @dfn{unit info pane} has the general form
@example
<picture><unit owner/type/name>  <hp> <acp>|<cp> <cxp>
<location>                       <other units here>
<occupants>                      <supply>
<plan>                           <more supply>
<tasks>                          <even more supply>
@end example
Items like @code{<hp>} and @code{acp} have the form
@code{@var{current}/@var{max}}, so that you can get an idea of how the
value compares to what it could be.
@c xref general description of these

@cindex Mouseover
The @dfn{mouseover} pane is a brief description of what the mouse is
over, and updates continuously as you roll the mouse around, both inside
the map view and outside.  Use it to get info about cells, enemy units,
and buttons.

@cindex Notices
The notices pane is a scrolling list of textual notices about what is
happening, and what has already happened in the game.  Combat and
construction reports come out here, as well as copies of warnings and
feedback from commands.

The bottom line of the notices pane also serves as an input field for
commands that need textual input.  When this happens, you will see a
prompt here, and anything you type in response will be echoed here also.
Prefix arguments to keyboard commands also appear on this line.

The control panel along the side of the map is just a collection of
buttons for the most common commands.

The turn/date pane shows the current turn.  In many games, the turn is
displayed as a date, so you may see it in that form.

@cindex Side list pane
@cindex Side progress
The @dfn{side list pane} lists all of the sides in the game, including
emblem, name, and player.  Most importantly, it displays each side's
progress in moving units for the current turn.  The black part of the
progress bar indicates the total number of acp left for units to move
with, while gray indicates units that could move, but that are asleep or
in reserve.  The turn is over for a side when the black part is gone.
Note that a sleeping unit may wake up, in which case the gray part will
shrink and the black part will expand.

The side list also displays the current value for each scorekeeper for
each side.

@cindex Unit type list
The @dfn{unit type list} displays all available unit types in a
scrolling list.  Units that your side can never own in this game (for
whatever reason) will not appear.  Each unit type appears along with its
name and a count of how many completed units of that type you own.  If
you have incomplete units, their numbers appear in parentheses
following.

@cindex World map
The @dfn{world map pane} is similar to the map view, but magnified so
that you can see the whole world.  It also includes a outline showing
the locations that are displayed in the map view.

Note that for some very large areas, the world map's pane may not be
large enough to display it all, even at the lowest magnification.  You
can drag the sizing grip to increase the area given to the world map.

@node Scrolling Maps
@subsection Scrolling Maps

@cindex Scrolling
It will nearly always be the case that the world is too large to be seen
all at once.  You can scroll around in several ways.

If you position the cursor close to the edge of the map view, it will
begin to scroll.

@c should implement this
@c If you are in survey mode, and click near any edge of the view,
@c @i{Xconq} will put the position you clicked at the center of the view.
@c By clicking in the same place repeatedly, you can ``walk'' the view in
@c any desired direction.

If you want to go directly to a particular part of the world, use the
world map in the bottom right corner of the map window.  Just click
anywhere within the world map, and @i{Xconq} will center the main map
on that point.


@node Unix/X11 Xconq

@chapter Unix/X11 Xconq

@cindex X11 Xconq
@i{Xconq} runs on just about any Unix system, using the X Window System
(version 11) for graphical display.

@menu
* Installing X11 Xconq::
* Starting a New X11 Xconq Game::
* X11 Xconq Command Options::
* Troubleshooting X11 Xconq::
@end menu

@node Installing X11 Xconq
@section Installing X11 Xconq

The usual @samp{make} and @samp{make install} will generate and install
the executable and library into @file{usr/local/bin} and
@file{usr/local/lib/xconqdir}, respectively.  (See the file
@file{INSTALL} in the main source directory for more detailed
instructions.)

The name of the executable is @file{xconq}.

@c As with most X programs, you can customize @i{X11 Xconq} by using
@c resources.

@node Starting a New X11 Xconq Game
@section Starting a New X11 Xconq Game

To play X11 @i{Xconq}, just type @samp{xconq}.  This will bring up an
initial splash screen; click on it and the following setup screens to
get a game going.
@c For further details, xref cif startup.

By default, X11 @i{Xconq} opens up windows on the display named in the
environment variable @code{DISPLAY}, and connects it with the first side
and player in the game.

You may also set up a game by supplying arguments on the command line,
in the traditional Unix style.  This is useful when you know exactly how
you want to play a game, and don't want to bother going through all the
startup screens.

@node X11 Xconq Command Options
@section X11 Xconq Command Options

The arguments to an X11 @i{Xconq} command consist of a list of player
specifications and possibly some additional options.

@table @code

@item [@var{name}[,@var{ai}][/@var{config}]@@]@var{display}[+@var{adv}]
Attempt to open a display on @var{display} and assign a player/side to
it.  Options include naming the player @var{name}, adding an AI of type
@var{ai}, using the side config file @i{config} and asking for an
advantage of @var{adv}.  @var{adv} defaults to 1.  If @var{name} is not
supplied, then @var{name} is assumed to be the display name.  A display
named just @code{"_"} is equivalent to the default display, as in the
value of the environment variable @code{DISPLAY}.

@end table

You can get a variety of uses out of player specs.  For instance, the
player spec @code{,ai+4} asks for an AI, of a default type appropriate
to its side, with a starting advantage of 4.  If you want to give
yourself an advantage, just specify @code{+4} anywhere on the command
line.

The following options are always available:

@table @code

@item -c @var{n}
Write a checkpoint every @var{n} turns.
@c add material on how to use, also pref for GUIs.

@item -design
Make every side in the game be a designer.

@item -e[,@var{ai}][+@var{adv}] @var{n}
Create @var{n} sides and AIs to play them, using the optional @var{ai}
and @var{adv} to set the AI type and advantage of each.

@item -f @var{filename}
Play the game found in @var{filename}.

@item -g @var{gamename}
Play the game @var{gamename}, if one by that name exists in the library
(the default, or the location specified with @code{-L}.

@item -h @var{n}
Wait for @var{n} human players to join.
@c still available?

@item -help, --help
List all of the options.  If a game was loaded using @code{-g} or
@code{-f}, also list all of the variants for the game.

@item -host @var{name}
Set up a network game named @var{name}.  @var{name} must currently have
the form @var{host}:@var{port}, where @var{host} is the name of a host,
and @var{port} is a TCP port number.  The port number should not already
be in use; good choices are 4-digit numbers like 1539 (@code{'^X' << 6 +
'^C'}) or 3075.

@item -join @var{name}
Connect to an existing game named @var{name}.  @var{name} must currently
have the form @var{host}:@var{port}, where @var{host} is the name of a
host, and @var{port} is a TCP port number.

@item -L @var{directory}
Search in @var{directory} for game modules.

@item -noai
Suppress all AI creation during game setup.

@item -pre @var{form}
@item -post @var{form}
Evaluate the GDL form @var{form} before or after all game modules have
been read in.  These are primarily of interest to game designers and
testers.

@item -r
Do not automatically add a player with a display set to @code{$DISPLAY}.
If you use this option, you must specify all players on the command line
explicitly.

@item --version
Display version information.

@item -w
Suppress all warnings, both during startup and during the game.

@item -x
Bring up a set of new game, variant, and player setup dialogs.  This
is necessary if you want to both use setup dialogs and to supply
command arguments.

@end table

The following options only work if the game design allows for the
corresponding variants.  In each case, the option corresponds to a
particular setting of a particular variant, as seen in the online help
info.

@table @code

@item -M @var{width}[x@var{height}][W@var{circumf}][+@var{lat}][+@var{long}]
Set the size and position of the game area.  If only @var{width} is
given, then the @var{height} defaults to the same as @var{width}.
Circumference (@var{circumf}) defaults to 360, @var{lat} and @var{long}
default to 0.  The name of the variant is @code{world-size}.

@item -seq
Set sides to move in sequence, one at a time.  This is equivalent to
@code{-vsequential=1}.

@item -sim
Set sides to all move simultaneously.  This is equivalent to
@code{-vsequential=0}.

@item -tgame @var{mins}
Set the maximum total number of real minutes that a game may last.
The variant is @code{real-time}.

@item -tside @var{mins}
Set the maximum total number of real minutes allowed for each side's
play.  (This is like a chess clock.)  The variant is @code{real-time}.

@item -tturn @var{mins}
Set the maximum numbers of real minutes for each turn.  When the maximum
is reached, each side automatically finishes, as per the command, and
the next turn begins.  The variant is @code{real-time}.

@item -v
Set the world to have been seen already.  This is equivalent to
@code{-vworld-seen=1}.

@item -v[@var{name}][=@var{value}]
Set the variant named @var{name} to have the value @var{value}.  If the
@var{value} is not supplied, it defaults to 1 (@code{true}).

@item -vhelp
Display variant help info only.  This lists the available variants as
@code{-help} does, but without all the other help info.

@item -V
Set everything to be seen all the time.  This is equivalent to
@code{-vsee-all=1}.

@item -V0, -Vfalse
Set everything not to be seen all the time.  This is equivalent to
@code{-vsee-all=0}.

@end table

If debugging has been compiled in, then the options @code{-D} and
@code{-R} are also available.  See the @i{Xconq} hacking manual for more
detail.

The following options apply only to the default X11 display:

@table @code

@item -bg @var{color}
Set the background color for each window.

@item -display @var{displayname}
Open the given display for the default player.

@item -fg @var{color}
Set the foreground color for each window.

@item -geometry @var{geometry}
Set the geometry of the initial window.

@item -name @var{name}
Set the name of the application to use when looking up resources.

@end table

@node Troubleshooting X11 Xconq
@section Troubleshooting X11 Xconq

@c By far the most common problem with the X11 interface is setting up a
@c game with multiple displays.


@node Windows Xconq

@chapter Windows Xconq

Windows @i{Xconq} uses the common interface.
@c xref common interface

If you invoke the program from a DOS prompt or from a Cygwin bash shell,
you may supply command-line options.  In general, the same options are
available as for X11 @i{Xconq}.
@c xref command options

@menu
* Files and Directories for Windows::
@end menu

@node Files and Directories for Windows
@section Files and Directories for Windows

The scorefiles are normally kept in a sibling directory of the location
of the executable.  However, you can ask to keep them elsewhere by
setting @samp{XCONQ_SCORES} to the pathname of a directory.  @i{Xconq}
will not create the scores directory if it does not already exist.

@node Mac Xconq

@chapter Mac Xconq

@menu
* Introduction to Mac Xconq::	Introduction to Mac Xconq
* Playing Mac Xconq::		Playing Mac Xconq
* Troubleshooting Mac Xconq::	Troubleshooting Mac Xconq
@end menu

@node Introduction to Mac Xconq
@section Introduction to Mac Xconq

@i{Xconq} on the Macintosh(r) features multiple windows,
click-and-drag operations, both menu and keyboard access to commands,
and support for both b/w and color displays.

@i{Xconq} requires no special installation once you have unpacked it.
Since the distribution consists of a number of files and folders in
addition to the application proper, it will be less confusing to keep
@i{Xconq} in a separate folder.

The standard distribution comes with documentation in the form of HTML
files, which you can look at using your favorite Web browser.  You can
also print them out using the browser.  These files may be found in
the @file{doc-html} folder.

@node Playing Mac Xconq
@section Playing Mac Xconq

@menu
* Starting a Game::
* Playing a Game::
* Menus::
* Windows::
* Keyboard Commands::
* Mac Preferences::
@end menu

@node Starting a Game
@subsection Starting a Game

The splash screen gives you four choices: ``New'', which brings up a
list of games; ``Open'', which allows you to pick a file; ``Connect'',
which will allow you to pick a game to join; and ``Quit'', which lets
you escape.

Usually you will want to choose ``New'', which brings up a dialog
listing all the games.  You can select one and see a brief description
of it.

You can also load a game from a file by choosing ``Open''.  This just
uses the standard Mac file-opening dialog.  You restore a saved game
this way.  You can also open from the Finder by double-clicking on the
file's icon.

@menu
* Loading a Game::
* Choosing Variants::
* Player Setup::
* Final Setup::
@end menu

@node Loading a Game
@subsubsection Loading a Game

Whether you've chosen from New Game or Open Game, @i{Xconq} will go
through a loading process, which may take a while if the game is large
or complicated.

You may get some warning alerts, which are often benign (such as an
inability to find some images), but others are indicative of disaster
ahead.  If you see one and continue anyway, don't be surprised if the
game goes up in a cloud of smoke later!

@node Choosing Variants
@subsubsection Choosing Variants

If the game includes any ``variants'', you will then get a dialog with
assorted buttons and checkboxes to choose from.  For instance, some
games let you choose whether the whole world is visible when you start,
or what kind of scoring system to use.

Different games have different variants, but there are several used by
many games.

The ``World Seen'' checkbox, when set, makes the whole world seen right
from the beginning of the game.  This only affects the initial view, and
you will only see some types of units belonging to other players, such
as their cities.

The ``See All'' checkbox makes everything seen all the time, right down
to each occupant of each unit of each side.  This makes @i{Xconq} more
like a boardgame, where little or nothing is secret.

The ``World Size'' button brings up a dialog that you can use to change
the dimensions of the world in everybody will be playing.  In @i{Xconq},
the available area of the world is either a hexagon, or a cylinder
wrapping entirely around the world.  Click or drag within the display
area of the dialog to select an approximate size, or type in the text
boxes.  You get the cylinder by setting the circumference equal to the
width of the area. See the generic player's manual for more details
about world size and shape, and be aware that it's very easy to select a
world that is much too large for reasonable play (the default of 60x30
is a medium-sized game; 200x100 is enormous!)

The ``Real Time'' button brings up a dialog that you can use to set
realtime countdowns.  You can limit both the total time allotted to a
game, to each turn, and/or to each side.

@node Player Setup
@subsubsection Player Setup

The player setup window shows the sides that will be in the game and who
will play each side.  As with the variants, you will often just want to
accept it (click ``OK''), since the game's designer usually sets the
defaults reasonably.

If you want to change the setup, you first need to understand the
current set of sides and proposed players.  Each entry in the list of
sides starts off with the side's emblem (if it has one), followed by the
name of side, then in italics, some information about the player, and
then the initial advantage for the player.  You, the person sitting in
front of the screen, is described as ``You'', while players that are
actually run by the computer are described as ``AI mplayer'', ``AI''
being short for ``artificial intelligence'' (In some games, a player may
be a specialized AI, named @var{name}, in which case it will be
described as ``AI @var{name}''.)

In games that allow you to have more than the default number of sides,
you can just click the ``Add'' button.  All the other controls require
you to have selected a side/player pair.  You can do this by clicking
anywhere in one of the boxes describing the side/player pair, which will
be highlighted in response.

The @samp{Computer} button toggles the AI for that side.  You can add an
AI to any side (including your own side; more on that later).  You can
also remove the AI from any side; a side with no AI and no human player
will just sit quietly and do nothing throughout the entire game.  Units
on the side will fight back if attacked, just like any other units, but
if you capture things like cities, the side won't even attempt to take
them back.

If you don't like the side you're on, you can use the @samp{Exchange}
button to switch.  The ordering of the sides is fixed, so exchange just
exchanges players between the currently selected side/player pair and
the next one.  It can take a little experimentation to get the hang of
using this, but you can generate any arrangement of players using a
combination of selection and exchange.

@node Final Setup
@subsubsection Final Setup

When you have OKed all the setup dialogs, @i{Xconq} will finish setting
up the game.  For some games, this will take quite a while - @i{Xconq}
generates random terrain, positions countries so that they are neither
too close nor too far apart, and does many other things to set up the
game, so just kick back and watch the progress bars.

Once everything is set up, @i{Xconq} then opens up the game window, the
instructions window, and one map window for you.  The map shows you
terrain with different patterns, and your playing pieces (units) with
small pictures.

Note that @i{Xconq} allows all players, including AIs, to
start doing things as soon as the windows come up.  You may even find yourself
being attacked before you know what's happening!  This is a feature; the
AI isn't good enough to afford to give you any breaks.

@node Playing a Game
@subsection Playing a Game

The basic pattern of play is to find a unit in a map or list window,
click once to select it, and then pick commands from the @samp{Play} menu.
There is also an ``auto-select'' mode that does the selection for you
and interprets mouse clicks as movement commands; @i{Xconq} actually
starts up in this mode.

You can select units by clicking on a unit, shift-clicking a group,
dragging out a selection rectangle, or by using Command-A to select all
units.  A selected unit is indicated by an outline box - solid black to
indicate that it can move, dark gray to indicate that it cannot move,
and gray to indicate that it cannot do anything at all (at least during
this turn; some types of units may only get to do something once in a
while).  If clicking on a unit image doesn't have any effect, then it's
not a unit that belongs to you.

To move a selected unit, drag the selected unit to its desired new
location.  The unit might not move right away if it doesn't have the
action points, but it may get some in the next turn.  To move all
selected units, do Command-click on the desired location and all of them
will attempt to move there.

To shoot at another unit, you can position the mouse over the desired
target, type `f', and all selected units will attempt to fire.
Since you can select all units, and the ones that can't fire will
simply do nothing, you can call down considerable
destruction with `f'!  If the target is too far away, nothing will
happen.  'f' can only fire at units that you actually have under
observation.  Use `Control-f' to fire into a cell where you can't
see anything.

To find out more about a unit, pick ``Closeup'' from the ``Play'' menu
or do `Command-I'.  This brings up a window that shows all kind of data
about a single unit.  You can leave this window up and it will always be
kept up-to-date.

To jump ahead to the next turn, do the menu command ``End Turn'' or
the key `return'.  You may have to do this if some of your units still have
action points, but not enough to do any of the things you want them to
do.

The Game window (`Command-1') shows the status of all the sides in the
game.  The window shows both the emblem (if available) and name of each
side.  A small computer icon indicates that an AI is running the side,
while a face icon indicates your side's relationship with the side
(smiling means friend/ally, frowning means enemy, flat expression means
neutral).

Each side also has a progress bar that shows how many actions its units
have left to do.

@c [describe auto-selection]

@node Menus
@subsection Menus

This section describes all the menus.

@menu
* File Menu::
* Edit Menu::
* Find Menu::
* Play Menu::
* More Menu::
* Side Menu::
* Windows Menu::
* View Menu::
@end menu

@node File Menu
@subsubsection File Menu

The File menu includes the usual sorts of commands that all Mac programs
share.

@table @code

@item New Game
Brings up the new game dialog.

@item Open Game
Brings up a standard file dialog.  @i{Xconq} will assume the selected
file to be a game module and attempt to load it as such.

@item Connect
Use the Connect item to join in a game that is already running elsewhere.

@item Save
Saves the game to a file.

@item Save As
Saves the game to a file, with a name chosen from a dialog that pops up.

@item Preferences
Brings up a dialog that you can use to select various options.
See below for more detail.

@item Page Setup

@item Print Window
Prints the front window.

@item Resign
Offers your resignation.

@item Quit
Leaves @i{Xconq}.  If the game has not ended, you will be asked if you
want to save; if not, and if any of the AIs in the game don't want to
draw or quit, you may have to resign in order to get out.

@end table

@node Edit Menu
@subsubsection Edit Menu

Note that there is no Undo.  Hey, this game is a life-or-death struggle,
and you may have noticed that you don't get an Undo in real life either...

@table @code

@item Cut
@item Copy
@item Paste
@item Clear

These are not normally enabled, but if a text entry window is up,
then you can use these in the usual way.  Examples of text entry
include the command input dialog and the construction run length
item in the construction dialog.

@item Select All
Selects all units that you are currently allowed to select.  Most
commands will operate on multiple unit selections, so this is a powerful
(and therefore dangerous) option.  For instance, if you select all units
then put them all to sleep, nobody will do anything at all.

@item Design...
The Design item is for access to game designer tools.  You cannot use
these during a normal game; you will be asked to confirm that you want
to design, and if so, @i{Xconq} will change all the windows
appropriately and bring up a special designer's palette.  This is a
one-way activity; once somebody in the game becomes a designer, all
players will be notified and computer-run players will no longer bother
to play.  (In case it's not obvious, this is because it's too easy to
cheat using the designer's powers.)

@end table

@node Find Menu
@subsubsection Find Menu

This menu is for various kinds of searching.

@table @code

@item Previous Actor
This item selects the previous unit that can do actions.

@item Next Actor
This item selects the next unit that can do actions.

@item Next Occupant
This item selects the next occupant among the occupants of a unit or cell.
If the selected unit has occupants, then this command will select one of
those first, and if the selected unit is the last occupant, the the command
will select the transport; thus repeated uses of this command will eventually
cycle through all units at a single location.

@item Location...
This item brings up a dialog that allows you to type in a set of coordinates
or the name of a geographical feature, then scrolls the most recently-used
map over to that location.

@item Unit by Name...
This item brings up a dialog that allows you to type in a name of a unit,
then scrolls the most recently-used map over to that unit.

@item Distance...

@item Selected
This item scrolls the most recently-used map over to show the selected unit in a list.

@end table

@node Play Menu
@subsubsection Play Menu

This menu is the main set of commands that you can give to individual units.
When you specify one of these, the units affected will be whatever is
selected in the window.  If the window is of a type that does not have
selected units (such as a help window), then the items on this menu will
be disabled.

@table @code

@item Closeup
This item opens closeups (see below) of all the selected units.

@item Move To...

@item Return
This item directs the selected units to return to the closest place where they can
replenish supplies that have been used up.
If the unit has been damaged, it will also look for places to get repairs.

@item Set Formation...
This item directs the selected units to maintain their current positions
relative to a given ``leader'' unit.

@item Wake
Wakes up the selected units.

@item Sleep
Puts the selected units to sleep.

@item Reserve
Puts the selected units into reserve.

@item Delay
Delays the move of the selected units until all other units have moved.

@item Build
Brings up the construction window and selects the first of the selected
units that can do construction.

@item Repair

@item Attack

@item Overrun

@item Fire
This item commands the selected units to fire at a given target
unit.

@item Fire Into
This item commands the selected units to fire into a given cell,
regardless of whether any units are actually there.

@item Detonate
This item commands the selected units to detonate.

@end table

@node More Menu
@subsubsection More Menu

The ``More'' menu contains additional actions, typically those that you
will need less often.

@table @code

@item Give...

@item Take...
Make the selected units take supplies from their transports if possible.

@item Embark
This item commands the selected units to get into the nearest transport.

@item Disembark
This item commands the selected units to get out of their transports but
remain at the transport's location, if stacking rules allow.

@item Drop...

@item Detach

@item Disband

@item Add Terrain
Make the selected units do terrain additions.

@item Remove Terrain

@item Plan Type

@item AI Control
Toggle an AI's control over the unit.  When control is off, the AI will
not try to give this unit any kind of orders, leaving you to control it
manually.

@item Rename...
This item brings up a dialog that allows you to rename the selected unit.
If the ``Random'' button is enabled, then there is a random name generator
available for that type of unit, and you may click it repeatedly to get
different randomly-generated or -selected names to choose from.

@item Give Unit
This submenu gives you a list of sides to which you may give the selected
units.  If the side is grayed out, then the selected type(s) may not be
on that side.

@end table

@node Side Menu
@subsubsection Side Menu

This menu is for overall control of the side you're playing.

@table @code

@item Closeup
This item will bring up a window that displays more details about a side.
[not implemented yet]

@item End This Turn
This item declares your movement for this turn to be over.  It is the same
as typing Return.

@item Move On Click
When this item is enabled, single clicks in the map window will result in
movement tasks for every selected unit.

@item Auto Jump Next
When this item is enabled, the selection in the front map window will
automatically shift to the next unit that needs to be given directions.

@item Auto End Turn
When this item is enabled, your turn will automatically end when all
units have received directions or have used up their action points.  If
disabled, then you must explicitly end the turn by choosing the menu
item ``End This Turn'' or by typing Return.

@item Sound
This item enables and disables sound effects.

@item AI
This is a submenu that lists the possibilities for AIs to run the side
for you.  Select the name of an AI to have it decide units' moves for
you.  If you select @samp{None}, then the AI will shut itself off and
return the units it was controlling to your control.

@item Doctrines
[not implemented yet]

@item Send Message
This item brings up a dialog that allows you to send a message to
other sides.

@item Rename Side...
This item brings up a dialog that allows you to alter the side's name,
the noun to be used to refer to units on that side, the side's emblem,
and so forth.

The button ``Choose Randomly'' will run a random side name generator or
selector, if available.

@end table

@node Windows Menu
@subsubsection Windows Menu

This menu is for the creation and arrangement of windows.

@table @code

@item Game
This item brings up the game window.

@item Notices
This item brings up the notices window.
Notes are messages about things that are happening in the present.
It has a limited capacity (32K of text), so old notices eventually
disappear.

@item History
This item brings up the history window.
The history is a complete record of important events.

@item Construction
Brings up the construction window.
The window will not be put away after you have requested construction.

@item Command
This item creates or brings forward the command entry window.
The command @code{'o'} has the same effect.

@item Research

@item Scores
This item brings up the scores window, showing wins and losses.

@item Design

@item Agreements

@item World Map
This item creates a map window sized and scaled so as to show the entire world.

@item New Map
This item creates another map window.

@item New List
This item creates another list window.

@end table

The rest of the menu lists the windows that are currently open.  You can
select a menu item to bring its corresponding window to the front.

@node View Menu
@subsubsection View Menu

The View menu gives you control over the appearance of the window you're
currently looking at.  Each kind of window that has any view controls
will have a different view menu.  Currently only map and list windows
have view menus.  Each window has its own view settings, although you
can set defaults for new windows from the preferences.  You can find the
descriptions of each view menu's items under the description of its
window, below.

@node Windows
@subsection Windows

@i{Mac Xconq} lets you have many windows open at once.
Each type has its own specialized functionality.

@menu
* Map Windows::
* Game Window::
* List Windows::
* Unit Closeup Windows::
* Construction Window::
* Notices Window::
* History Window::
* Scores Window::
* Instructions Window::
* Help Window::
@end menu

@node Map Windows
@subsubsection Map Windows

A map window gives you an overhead view of some part of the @i{Xconq} world.
As you might expect, you can scroll around to look at different parts.
You can also zoom in and out using the small zoom icons in the lower
left corner; zooming in (``closer mountains'' icon) makes the cells larger,
while zooming out (``farther mountains'' icon)  makes the cells smaller,
so you can see more of the world.  You can zoom way in or out!

The optional ``top line'' of the map window supplies you with information
about what the cursor is currently over, plus the current game date.

The map control panel is along the left side.  At its top is the
auto-select/move-on-click button.  Below that is a set of
find-next/previous buttons.  The next set of buttons is controls
for how the map will be displayed.  These behave identically to
the map's View menu items.

Since maps are the main interface to @i{Xconq} games,
you have many view menu options for controlling their appearance.

[update this to reflect current organization]

@table @code

@item Closer
This item increases the magnification of the map, which draws
units and cells larger.  This is useful when many units are
stacked in a cell or transport unit.

@item Farther
This item decreases the magnification of the map, which draws everything
smaller and with less detail.  However, you get to see a larger area at
once, which is useful for strategic planning.

@item Set Mag
This submenu allows you to select a magnification directly.
The numbers indicates the approximate size in pixels of the
icons.  Units generally become unrecognizable at less than 16x16.

@item Angle
This submenu allows you to select an angle at which to view the
map.  Choices are 15 degrees, 30 degrees, and 90 degrees (overhead).

@item Names
This item controls whether names of units and features are drawn on
the map.

@item Elevations
This item controls the display of contour lines indicating elevations.

@item People
This item controls the display of which cells' people belong to which sides.

@item Weather
This is a submenu that includes controls for the display of temperature,
clouds, and winds.

@item Materials
This is a submenu that includes an item for each type of material that
a cell might have in it.

@item Terrain
This is a submenu that includes toggles for the display of each
border and connection type.

@item Daylight
This item controls whether the display is darkened for those cells
that are dark.

@item Coverage
This item controls whether view coverage is displayed.  Cells with no
view coverage by any units are darkened.

@item Grid
This item controls whether the grid separating cells is shown.

@item Top Line
This item controls whether the top line of the map is displayed
or hidden.

@item Unit Info
This item controls whether the selected unit info at the top of the map is
displayed.

@item Other Maps
This item controls whether outlines of other maps are drawn on
the map.

@end table

@node Game Window
@subsubsection Game Window

The game window shows you the turn number or date of the current turn,
as well as any realtime clocks that may be counting down, and a list of
all the sides.  For each side, you see its name, the emblem for that
side, a progress indicator, and icons indicating the side's attitude and
whether it is being played by the computer.  You may also numbers
indicating scores and/or real time remaining.

The progress bar shows how much movement a side has done during the
turn.  This usually goes down during the turn, but because it indicates
a percentage rather than an absolute number of actions, the percentage
may go up sometimes.  For instance, if some of your units that have
already acted are captured, then the percentage goes up because the
@emph{total} number of actions has gone down!  A gray bar indicates that
the side has finished all movement for this turn.  There may also be a
gray area below the black area of the bar, which indicates the
percentage of units that are asleep or in reserve.  Note that a player
can always wake up sleeping or reserve units at any time before the end
of the turn.

@node List Windows
@subsubsection List Windows

A unit list window just lists all the units, one line each.  This is
useful for getting a more organized look at your assets.  A unit listing
shows the icon for the unit, its name and type, action points, hit
points, supply, etc.

You can create more than one list window.

If you select a unit in the list and then choose Find Selected from the
the Find menu, then a (randomly selected) map will be scrolled over to
that unit.

List view controls typically either affect what will be listed, or the
sorting of the list.  There is also an item to control the size of the
unit icons.

@table @code

@item by Type
List the units by type, in the order that the types are defined
by the game module.

@item by Name
List the units in alphabetical order by name.

@item by Side
List the units by side.

@item by Acting Order
[should delete?]

@item by Location
[not implemented yet]

@item with Transport
[not implemented yet]

@item with Commanders
[not implemented yet]

@item Larger Icons
This item controls the use of larger (32x32) or smaller (16x16) icons
for displaying units graphically.

@end table

@node Unit Closeup Windows
@subsubsection Unit Closeup Windows

For any unit, you can create a closeup window.  This window supplies
full details on the unit.  The info in the window is in a format shared
by several interfaces: see the ``Unit Info'' section of the generic play
manual for more explanation of what each of them means.

@node Construction Window
@subsubsection Construction Window

You use the construction window to control the construction of new
units.  The window comes in two parts; the left side is a list of all
the units that can do construction, while the right side is a list of
all the types that can be constructed.  You select a unit on the left
and a type on the right, then click on ``Construct'' to add a build task
to the unit's task agenda.

Each unit on the left side is preceded by an estimated number of turns
to complete the type of unit that has been selected, or @code{--} if the
unit cannot build that type.  If the unit already has a build task, that
is mentioned after the unit's identification, and includes the number of
units to build as well as the status of the one currently under
construction.

Each type on the right side is preceded by an estimated number of turns
for the selected unit to complete one, or @code{--} if the selected unit
cannot build that type.  If the type has a tech level prerequisite for
construction, that will also be listed, with the syntax @code{[T
n1/n2/n3]}, where the numbers indicate current tech level, level to
build, and max level.  Following the type is a count of how many
completed units of that type exist, with the number of incomplete types
in parentheses.  You can type a single character to select a type;
typically the first letter of its name, otherwise use the single
character in parentheses immediately following the type name

At the top of the window is the button ``Construct'' that sets up build
tasks, and next to it a button ``Research'', for when you wish to add to
the tech level without building any actual units (such as when you're
using several units to accelerate some unit's construction program).
Note that a build task will automatically do research if necessary
before construction can begin.  The top also includes a small text
window where you can set the number of types to build.

@node Notices Window
@subsubsection Notices Window

The notices window tells you about what is happening at the moment.
Look at this to see what is currently going on.

For information about what happened in past turns, you can scroll
back in the notices window, or you can look at the history window.

@node History Window
@subsubsection History Window

The history window is a comprehensive record of what has happened in
the game, from the first turn on.

@node Scores Window
@subsubsection Scores Window

The scores window lists your win/loss record.

@node Instructions Window
@subsubsection Instructions Window

The instructions window is the basic info about what game you're playing
and what you're supposed to do.  Many game designs have few or no
instructions.  There is a Help button that just brings up the help
window, for convenience.

@node Help Window
@subsubsection Help Window

@i{Xconq}'s help information is organized into a list of topics.  When
you first open the help window, you will see the list, and a row of
buttons.  To look at a specific topic, just click on it.

The ``Topics'' button goes straight to the list of topics, while the
``help'' button shows you the topic describing the help system itself.
``Prev'' and ``Next'' buttons take you through the topics in order,
while ``Back'' goes to the last topic you looked at.

@node Keyboard Commands
@subsection Keyboard Commands

@i{Mac Xconq} understands all the single-character and long-name
commands that are defined for @i{Xconq} in general.

@node Mac Preferences
@subsection Preferences

The Preferences dialog includes several screens of options you can set,
the specific screen being chosen from the popup at the top of the
dialog.

The File screen gives you some options relating to files.

@table @code

@item Checkpoint File
You can choose to have a game saved every few turns.  This is useful if
you want to be sure that a game is not lost due to a fatal error, such
as running out of memory because you're on a small machine.
@c xref checkpointing games

@item Write Game Statistics File
You can choose to have @i{Xconq} write out a statistics file that shows
a summary of each sides' units' fates, average combat outcomes, and
possibly other interesting information about how the game went.

@end table

The Map Display screen allows you to personalize your map windows.

@table @code

@item Grid
@item Names
These items set the default values for the View menu's display controls.

@item Prefer Color Unit Images
@i{Xconq} can support both full-color unit images and silhouettes based
on black-and-white images.  Full color is of course more colorful, but
silhouettes are more efficient in complex games.  Many games have images
in only one style or the other, so your choice may not have much effect
in a specific game.

@item Prefer Solid Color Terrain
As with unit images, you can have your terrain displayed as areas of
single solid color, or as patterned areas.  Again, solid color is not as
attractive, but it reduces the ``noise level'' in a complex map display.

@item Show Latitude/Longitude
This option controls the display of latitude and longitude meridians.
This is mainly useful for game designers building maps based on the real
world.

@end table

The Font screen gives you control over the size and appearance of the
text used in various windows.

@node Troubleshooting Mac Xconq
@section Troubleshooting Mac Xconq

@i{Xconq} rarely crashes, so when it does, that is a serious problem;
please report it, and include as much information as possible about your
system, what you were doing, which options were in effect, and so forth.

@menu
* Errors and Warnings in Mac Xconq::
* Known Bugs in Mac Xconq::
@end menu

@node Errors and Warnings in Mac Xconq
@subsection Errors and Warnings

@c trim down, xref to generic troubleshooting chapter

@i{Xconq} will sometimes display ``error'' or ``warning'' alerts.  These
can be caused either by bugs in @i{Xconq}, or more likely, by mistakes
in the design of the game you're playing.  For instance, you may be
playing a version of a game that has been modified by one of your
friends, but the modification was not done correctly, and you'll get an
alert unexpectedly.

``Error'' alerts are fatal; you may be able to save the game at that
point, but don't count on it.  Common ones for @i{Mac Xconq} include
errors because you're loading a text file that is not a valid game, and
running out of memory.  Most error alerts occur during game startup,
while @i{Xconq} is checking out the game definition that it's loading.
Error alerts that appear during a game, and do not involve running out
of memory, are more serious, and may indicate bugs in @i{Xconq}, so you
should try to save the game and report what happened.

There are many kinds of ``warning'' alerts.  Warnings are not fatal, but
they do indicate that all is not well.  If you get a warning alert and
don't know what it means, it's safer to quit than to try to struggle on.
Most warnings indicate mistakes in the design of the game you're
playing, and should be reported to the game designer.  If you
@emph{know} that a warning is unimportant, and don't want to see it over
and over, you can hold down the Option key while clicking on the
Continue button; this will suppress all future warnings.

@c @xref{Troubleshooting Xconq} for a list of common error and
@c warning messages, and what they mean.

@node Known Bugs in Mac Xconq
@subsection Known Bugs

In the construction window, clicking on ``Build'' doesn't always result
in a unit being created immediately.  It may be that the builder has
used up its acp and can't start construction until the next turn, or
that it hasn't come up for executing actions in the current turn.
Clicking a second time will make the construction start immediately.


@node Other Interfaces

@chapter Other Interfaces

There are other interfaces available.  This chapter documents them for
the record, but they are no longer recommended for players.

@menu
* curses Xconq::
@end menu

@node curses Xconq
@section curses Xconq

@i{cconq} is a version of @i{Xconq} that requires only an ASCII terminal
and a @i{curses} library for cursor movement and screen management.  As
a result, it will run almost anywhere.

@c including DOS - should try to build it under go32 or some such

However, you lose a lot in display power, and games may become much more
difficult to play.  For instance, roads and rivers cannot be represented
directly, and you will have to rely on the textual displays.

(Incidentally, this curses interface is the oldest one in Xconq,
predating even the X10 interface that was part of version 1's release in
1987.)

Because it is no longer used much, the usual @samp{make} and @samp{make
install} will NOT generate and install the executable.  Instead, use
@samp{make all-cconq} and @samp{make install-cconq}.

The resulting executable is @file{cconq}.

@menu
* curses Xconq Command Line Options::
* curses Xconq Screen::
* curses Xconq Commands::
* curses Xconq Troubleshooting::
@end menu

@node curses Xconq Command Line Options
@subsection Command Line Options

@c The command options are as for X11 Xconq (see @xref{Xconq Command Options}),
@c except that the X-specific options will not be recognized.

@node curses Xconq Screen
@subsection Screen

When @file{cconq} starts up, it takes over the whole screen, in the
usual fashion of curses programs.

The layout is generally similar to the appearance of the common
interface.  Some changes were dictated by the need to fit everything
into the standard 24x80 terminal screen (@file{cconq} can use a bigger
or smaller screen if necessary though).

@smallexample
Your town Drumheller will build 99 armor                     Turn   1

your town Drumheller  HP 20  ACP 0/1       |1*  83%/6 Brazilians (term)
In desert(Elev 1825) road/NE at 12,12      |2  100%   Japanese ()
Occ 1 a                                    |-Sides---------------------
fuel 500/500  ammo 200/200                 | *1 Hooker             1w
                                           | *1 Joe Batt's Arm     1w
   ?   ?   ?   ? ++++....  ?   ?   ?   ?   | *1 East Missoula      1w
                ^#+#......                 |**1 Drumheller
 ?   ?   ?   ? ^#+#+#......  ?   ?   ?   ? | *1 Nirmal             1w
              ^^^^*1@@1......               | @@1 Wonthaggi          1w
   ?   ?   ?   ^^^^*1==....?   ?   ?   ?   |
                ^^^^+#*1....               |
     ?   ?   ?   ^^^^*1+#*1..?   ?   ?   ? |
                  ^#^^~~+#++..             |
       ?   ?   ?   ^#~~~~++++  ?   ?   ?   |
                                           |
         ?   ?   ?   ?   ?   ?   ?   ?   ? |
                                           |
           ?   ?   ?   ?   ?   ?   ?   ?   |
                                           |
             ?   ?   ?   ?   ?   ?   ?   ? |
                                           |
--Map--Survey----(units)-------------------|-Units--ALL---by side------
@end smallexample

The main display is the map, which is in the lower left.  It uses
game-defined characters to represent units and terrain - in the above
example, @code{'..'}, @code{'++'}, etc represent sea, land, and so forth
respectively.  Units appear as a character for the type (@code{'*'} is a
town) followed by a decimal digit indicating the side.  Unknown terrain
is a combination of blanks and question marks, while the presence of
borders and connections is flagged by a @code{'#'}.

Above the map is a textual description of the currently selected unit
and its current location.

At the top is a couple of lines for notices of events and feedback from
commands.

The turn or date appears in the top right corner, while below it is a
list of the sides, their numbers as appearing on the map, and their
progress in the turn.  Also, the side being displayed has the display
@code{term}.

Below that is a list area, which you can use to display a list of actual
units, or a summary of the numbers of each type that you have.

Interaction and display modes appear on the bottom line of each major
subwindow.  The map window indicates survey/move modes, as well as the
kinds of optional data being displayed, while the list window indicates
units/types, selectivity (all or only some units), and sorting of the
list.

@node curses Xconq Commands
@subsection Commands

curses @i{Xconq} accepts all of the generic commands.

The @samp{map} command understands the following curses-specific arguments:

@table @code

@item _
Set number of lines in info window.
This command sets the number of lines used by the unit info
window above the map.  The default is 4, which is insufficient
to display the plan's tasks, or all of the supplies in games
with many kinds of materials.  The prefix argument is the
number of lines.

@item v
Set list view.

@item >
Grow the map.  This increases the amount of screen used by the map and
decreases the amount used by the lists.  The prefix argument is the
number of columns to change; its default value is 5.

@item <
Shrink the map.  This decreases the amount of screen used by the map and
increases the amount used by the lists.  The prefix argument is the
number of columns to change; its default value is 5.

@item @code{terrain}, @code{t}
Display or blank out the terrain.
You may prefix with @code{!} or @code{no} to achieve the opposite of the
effect.

@item @code{unit}, @code{u}
Display or blank out the units.
You may prefix with @code{!} or @code{no} to achieve the opposite of the
effect.

@item @code{name}, @code{n}
Display or blank out the names of features and units.
You may prefix with @code{!} or @code{no} to achieve the opposite of the
effect.

@item @code{people}, @code{p}
Display or blank out people.
You may prefix with @code{!} or @code{no} to achieve the opposite of the
effect.

@item @code{one}, @code{1}, @code{two}, @code{2}
Display the terrain character in one or two character positions of each
displayed cell.

@end table

@node curses Xconq Troubleshooting
@subsection Troubleshooting

Screen gets messed up on Sun4, for reasons I don't understand.


@node Troubleshooting Xconq

@chapter Troubleshooting Xconq

@i{Xconq} is a large and complicated program, with a lot of obscure
corners.  So there are lots of ways for things to go wrong.  On the
positive side, the program rarely crashes.  Instead, you're likely
to get large numbers of warning messages, or things won't happen
as you expect.

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

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

@node Errors and Warnings
@section Errors and Warnings

@cindex Errors
@cindex Game Design Language
@cindex Gdl
@dfn{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 the @i{Xconq} Game Design Language (GDL) and about how @i{Xconq}
works.  If the error happens during game setup, you will not be able
to save anything.

@cindex Warnings
@dfn{Warnings} are advice that something is amiss, but that there is no
obvious reason to quit---yet.  Warnings may indicate either mistakes in
a game design or bugs in @i{Xconq}.  If you @emph{know} that a warning
does not indicate a serious problem, you can keep playing, but be wary.

If the warning happens during game setup, you will not be able to save.
Otherwise you can save, and the game can usually be restored as-is,
although the problem causing the warning may still exist, and you'll
see the warning again when you restore the game.

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.

@table @code

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

@item Module @var{name} 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
@cindex Advantage
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
"xyz 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
@cindex Images
A game design may not have had graphical images defined for all types of
units and terrain.  @i{Xconq} will warn about this, then make up some
(ugly) default images itself.  Actual game play will be unaffected,
although the default images really are ugly and will want to make you
stop playing...

@item @var{name} 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 X11, for
instance).  This has no direct effect on game play, but you may have
difficulty if, say, your display shows several different terrain types
as having the same color.

@item Memory exhausted
@cindex Memory
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 @samp{See All} variant if it is
available (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{name}
(Obvious)

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

@item Sides have undesirable locations
@cindex Undesirable locations
Many game designs can specify how close and how far away each randomly
placed 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.

@c should document all the warnings?  what about GDL syntax complaints?

@end table

@node Checkpointing Games
@section Checkpointing Games

@cindex Checkpointing
If you're on a system that is prone to failures, you should consider
using @dfn{checkpointing}.  This is where @i{Xconq} automatically saves
the game every few turns.  If you're playing an important game on an
unreliable system, this will be very valuable.

You ask for checkpointing by using the @samp{-c} command option or by
setting a preference for how often to checkpoint.  You can save as often
as every turn.  The checkpoint files are saved in the same place as
saved games, and have exactly the same format; so you restore from a
checkpoint by simply opening the file as you would for restoring a saved
game.  The checkpoint is saved right at the beginning of a turn, so upon
restoration all sides have their full complement of moves for that turn.

On Mac, the checkpoint file is called @file{Checkpoint}, while on Unix
and Windows the file is named @file{check@var{turn}.xconq}, where
@var{turn} is the turn on which the checkpoint was saved.  (When the
checkpoint is successfully saved, the previous checkpoint is removed, so
files don't accumulate.)

@node Cheating
@section Cheating

@cindex 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 Glossary

@appendix Glossary

@include glossary.texi

@include gpl.texi

@node Index

@appendix Index

@printindex cp

@contents

@bye
