games-request@tekred.TEK.COM (07/13/87)
Submitted by: "Stanley T. Shebs" <shebs%orion@cs.utah.edu>
Comp.sources.games: Volume 1, Issue 81
Archive-name: xconq/Part01
[Not having an X-window system, I haven't tried this - so
you're on your own. -br]
[[Here is a new game I have been working on for awhile. It's similar to
Walter Bright's Empire, but has lots more features and runs on color or
monochrome X systems. It's kind of large, but has proved very popular at
Utah over the past three months, so much so that we've already gotten
warnings about playing too much! Please let me you if you run into any
troubles, especially with the fonts; it's not something that X supports
too well, and I've been groping around for the right way to distribute them.
(The recently posted font editor was quite helpful!)
stan shebs
shebs@cs.utah.edu]]
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 1 (of 7)."
# Contents: README MANIFEST help.c version.h xconq.nr
# Wrapped by billr@tekred on Thu Jul 9 17:45:37 1987
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f README -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"README\"
else
echo shar: Extracting \"README\" \(2817 characters\)
sed "s/^X//" >README <<'END_OF_README'
XThis is the source directory for XCONQ, an X-based multi-player strategy game.
X
XTo get started, follow these steps:
X
X0. Finish the unpacking process by doing "make unshar". This uuudecodes
Xand uncompresses some files.
X
X1. Look at config.h and edit as desired. The most important items are
Xthe system you're using and the pathnames to the aux programs and map
Xlibrary. The other things can be tweaked as desired.
X
X2. Edit the makefile's definitions for various directories. There is
Xsome repetition between the makefile and config.h, sigh.
X
X3. "make all" should build everything that needs to be built, with the
Xexception of some specialized games (see the Makefile for details).
X
X4. Decide what to do about the X fonts *.onx. If your X can load from
Xan absolute pathname, then make sure they're in the xconq library directory.
XThey can also live in the default X font directory - xconq will always look
Xin both places for a font. Note that HP's X needs an easy fix to load from
Xan absolute pathname. Finally, it may be possible to use the X defaults
Xto specify a path somewhere - look at the file "Xdefaults" for an example.
X
XIf none of these options work, xconq will still run, but you will get
Xboring letters instead of exciting pictures on the display. It's a total
Xlose with monochrome.
X
X5. If you set config.h to run things in the current dir, just say "xconq"
Xand play. If you want it somewhere else, use "make install".
X
X6. The man page just tells how to start up the program; xconq.doc has
Xcomplete and exhaust{ive|ing} details on every aspect of the game. A lot
Xof behavior can be figured out by experimentation and by using the
Xextensive online help ('?' should always provide something useful).
X
X7. If installed in a public place, announce availability. The library
Xfile "xconq.news" provides a convenient place to put in any notes about
Xchanges, new maps/scenarios, and so forth. Keep in mind that it pops
Xup in a smallish help window and long lines will get truncated.
X
XThe program has been tested on HP9000s300 running HP-UX, Suns, and Vaxen
Xrunning BSD 4.3; it's pretty generic code and should work on a variety of
XX boxes, both monochrome and color (but color looks MUCH better). Moving to
Xa non-X environment should not be too difficult either, since all the
XX calls are hidden in about 30 high-level interface routines.
X
XFinally, to repeat what is all over the files, you may copy, redistribute,
Xmodify, or even mangle the code, as long as the copyright notices are
Xretained, and you don't try to sell it. Common decency dictates that
Xyou identify your changes before passing the sources on. Also I would
Xenjoy seeing any improvements/fixes/suggestions, and will try to incorporate
Xthem in future versions of XCONQ.
X
X stan shebs
X shebs@cs.utah.edu
X seismo!utah-cs!shebs
END_OF_README
if test 2817 -ne `wc -c <README`; then
echo shar: \"README\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f MANIFEST -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"MANIFEST\"
else
echo shar: Extracting \"MANIFEST\" \(1284 characters\)
sed "s/^X//" >MANIFEST <<'END_OF_MANIFEST'
X File Name Archive # Description
X-----------------------------------------------------------
X 1800.u 7
X MANIFEST 1 This shipping list
X Makefile 7
X README 1
X X.c 4
X Xdefaults 7
X atk.c 4
X bitmaps.h 6
X city.c 4
X config.h 7
X do.c 5
X draw.c 5
X greek.c 7
X greek.u 6
X help.c 1
X init.c 6
X input.c 6
X mkmap.6 2
X mkmap.c 2
X mkmap.h 5
X move.c 3
X mplay.c 4
X napoleon.c 7
X order.c 7
X output.c 6
X preshar.7.u 2
X side.c 6
X side.h 7
X unit.c 3
X util.c 6
X version.h 1
X ww2.c 5
X ww2.u 7
X xconq.6 3
X xconq.c 5
X xconq.h 3
X xconq.nr 1
X xmap.6 5
X xmap.c 7
END_OF_MANIFEST
if test 1284 -ne `wc -c <MANIFEST`; then
echo shar: \"MANIFEST\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f help.c -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"help.c\"
else
echo shar: Extracting \"help.c\" \(6563 characters\)
sed "s/^X//" >help.c <<'END_OF_help.c'
X/* Copyright (c) 1987 Stanley T. Shebs, University of Utah. */
X/* This program may be used, copied, modified, and redistributed freely */
X/* for noncommercial purposes, so long as this notice remains intact. */
X
X/* RCS $Header: help.c,v 1.4 87/06/07 20:09:54 shebs Exp $ */
X
X#include "xconq.h"
X
X/* The general help command. It first lists the available commands, */
X/* then the current news about xconq. */
X
Xdo_help(n)
Xint n;
X{
X reveal_help();
X init_wprintf(NULL);
X command_help();
X wait_for_ack();
X reveal_help();
X init_wprintf(NULL);
X sprintf(spbuf, "%s/%s", XCONQLIB, NEWSFILE);
X if (show_file(curside, spbuf)) {
X wait_for_ack();
X }
X conceal_help();
X}
X
X/* Print out the news file if any exists. */
X
Xmaybe_dump_news()
X{
X char cmd[BUFSIZE];
X FILE *fp;
X
X sprintf(spbuf, "%s/%s", XCONQLIB, NEWSFILE);
X if ((fp = fopen(spbuf, "r")) != NULL) {
X fclose(fp);
X#ifdef UNIX
X sprintf(cmd, "cat %s\n", spbuf);
X system(cmd);
X#endif UNIX
X printf("\nHit <return> to continue...\n");
X getchar();
X }
X}
X
X/* This command provides a short note about the current square. It is */
X/* helpful when the meaning of brown terrain is unknown, etc. */
X
Xdo_ident(n)
Xint n;
X{
X char view, terr;
X Side *side;
X
X terr = terrain(curx, cury);
X view = side_view(curside, curx, cury);
X
X if (view == UNSEEN) {
X notify(curside, "You see unexplored territory");
X } else if (view == EMPTY) {
X notify(curside, "You see unoccupied %s", terrnames[terr]);
X } else if (vthing(view) == VCITY) {
X side = side_n(valign(view)-1);
X notify(curside, "You see a %s %s (in the %s)",
X (side == NULL ? "neutral" : side->name),
X citynames[vtype(view)],
X terrnames[terr]);
X } else {
X side = side_n(valign(view));
X notify(curside, "You see a %s %s (in the %s)",
X (side == NULL ? "neutral" : side->name),
X unitnames[vtype(view)],
X terrnames[terr]);
X }
X}
X
X/* Command to dump out all the parameters for a unit. */
X
Xdo_unit_info(n)
Xint n;
X{
X int type;
X
X type = read_unit_type("Which type of unit do you want the details on?");
X reveal_help();
X init_wprintf(NULL);
X describe_unit(type);
X wait_for_ack();
X conceal_help();
X}
X
X/* Full details on the given type of unit. */
X
Xdescribe_unit(type)
Xint type;
X{
X char buf2[BUFSIZE];
X int i;
X
X wprintf(curside, " %s", unitnames[type]);
X draw_unit_pic(curside, type, 2, 2);
X wprintf(curside, "");
X wprintf(curside, "Max move %d every %d turns (randomness %d)",
X utypes[type].range, utypes[type].turns, utypes[type].randmove);
X for (i = 0; i < NUMTERRTYPES; ++i) {
X sprintf(spbuf, "");
X if (utypes[type].moveson[i] > 0) {
X sprintf(buf2, "Moves %d in %s ",
X utypes[type].moveson[i], terrnames[i]);
X strcat(spbuf, buf2);
X }
X if (utypes[type].resupply[i] > 0) {
X sprintf(buf2, "Gets %d supplies in %s ",
X utypes[type].resupply[i], terrnames[i]);
X strcat(spbuf, buf2);
X }
X if (utypes[type].adj[i] > 0) {
X sprintf(buf2, "Gets %d supplies if adj to %s ",
X utypes[type].adj[i], terrnames[i]);
X strcat(spbuf, buf2);
X }
X if (strlen(spbuf) > 0) wprintf(curside, "%s", spbuf);
X }
X wprintf(curside, "");
X sprintf(spbuf, "");
X for (i = 0; i < numutypes; ++i) {
X if (utypes[type].capacity[i] > 0) {
X sprintf(buf2, "%d %c ", utypes[type].capacity[i], unitchars[i]);
X strcat(spbuf, buf2);
X }
X }
X if (strlen(spbuf) > 0) {
X wprintf(curside, "Cargo Capacities: %s", spbuf);
X }
X wprintf(curside, "");
X wprintf(curside, "HP %d", utypes[type].hp);
X wprintf(curside, "");
X wprintf(curside, "Effectiveness vs units:");
X wprintf(curside,
X " does %d hp of damage, %d extra moves used, %d supply used",
X utypes[type].power, utypes[type].hittime, utypes[type].hitsupply);
X wprintf(curside, " chance of hitting is");
X sprintf(spbuf, " ");
X for (i = 0; i < numutypes; ++i) {
X sprintf(buf2, "%.2f vs %c ",
X (utypes[type].hittab[i]/100.0), unitchars[i]);
X strcat(spbuf, buf2);
X if (i < numutypes-1 && utypes[i].domain != utypes[i+1].domain) {
X wprintf(curside, spbuf);
X sprintf(spbuf, " ");
X }
X }
X wprintf(curside, spbuf);
X wprintf(curside, "Effectiveness vs cities:");
X for (i = 1; i < MAXCTYPES; ++i) {
X switch (utypes[type].vscity[i]) {
X case NOWAY:
X sprintf(spbuf, " will not attack a %s", citynames[i]);
X break;
X case ASSAULT:
X sprintf(spbuf, " %.2f to capture a %s",
X (utypes[type].powervscity[i]/100.0), citynames[i]);
X break;
X case BOMBARD:
X sprintf(spbuf, " hits a %s for %d hp",
X citynames[i], utypes[type].powervscity[i]);
X break;
X case FLATTEN:
X sprintf(spbuf, " flattens a %s", citynames[i]);
X break;
X }
X sprintf(buf2, ", %.2f chance of getting hit",
X (utypes[type].cityvs[i]/100.0));
X strcat(spbuf, buf2);
X wprintf(curside, spbuf);
X }
X wprintf(curside, "");
X wprintf(curside, "Production: every %d turns (%d for first)",
X utypes[type].schedule, utypes[type].startup);
X wprintf(curside, "");
X if (utypes[type].buildtime > 0)
X wprintf(curside, "Builds base in %d turns", utypes[type].buildtime);
X}
X
X/* Stick descriptions of all units into a file. */
X
Xdo_period_dump(n)
Xint n;
X{
X int u;
X
X notify(curside, "Dumping period characteristics to %s ...", PARMSFILE);
X init_wprintf(PARMSFILE);
X for (u = 0; u < numutypes; ++u) {
X wprintf(curside, "--------------------------------------------------");
X describe_unit(u);
X wprintf(curside, "");
X }
X finish_wprintf();
X notify(curside, "... Finished dumping");
X}
X
X/* This kicks in on a unit type prompt. */
X
Xhelp_unit_type()
X{
X int i;
X
X reveal_help();
X init_wprintf(NULL);
X wprintf(curside, "Specify one of the following types of unit:");
X wprintf(curside, "");
X for (i = 0; i < numutypes; ++i) {
X wprintf(curside, "%c %s (%s)",
X unitchars[i], utypes[i].name, utypes[i].note);
X }
X wait_for_ack();
X conceal_help();
X}
X
X/* This kicks in on an order type prompt. */
X
Xhelp_order_type()
X{
X int i;
X
X reveal_help();
X init_wprintf(NULL);
X wprintf(curside, "Specify one of the following types of orders:");
X wprintf(curside, "");
X for (i = 1; i < NUMORDERTYPES; ++i) {
X wprintf(curside, "%c %s (needs %s)",
X orderchars[i], ordernames[i], orderargnames[i]);
X }
X wait_for_ack();
X conceal_help();
X}
X
X/* used by various routines to keep display up until no longer wanted. */
X
Xwait_for_ack()
X{
X char ch;
X int x, y;
X
X wprintf(curside, "");
X wprintf(curside, "[Hit any key or mouse to continue]");
X get_input(&ch, &x, &y);
X}
X
END_OF_help.c
if test 6563 -ne `wc -c <help.c`; then
echo shar: \"help.c\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f version.h -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"version.h\"
else
echo shar: Extracting \"version.h\" \(32 characters\)
sed "s/^X//" >version.h <<'END_OF_version.h'
X#define VERSION "1.00 (6/8/87)"
END_OF_version.h
if test 32 -ne `wc -c <version.h`; then
echo shar: \"version.h\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f xconq.nr -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"xconq.nr\"
else
echo shar: Extracting \"xconq.nr\" \(42956 characters\)
sed "s/^X//" >xconq.nr <<'END_OF_xconq.nr'
X.TL
XLIBERATING THE WORLD (Made Simple)
X.AU
XStan Shebs
X.AI
XDepartment of Computer Science
XUniversity of Utah
X.AB
XThis is an in-depth document on
X.I xconq
XVersion 1.00.
XIt covers all aspects of the game; further details
Xmay only be obtained by reading the sources.
X.AE
X.SH INTRODUCTION
X.PP
XWelcome to
X.I xconq,
Xa chance for you to free the world from domination by evil empires.
XIt is a successor to the well-known Unix and VMS game Empire,
Xbut with many more features.
X.I Xconq
Xis a fully X-based multi-player game, allowing almost any combination
Xof human and machine players, and opening up remote X windows as necessary.
X.PP
XYou start the game with one city and no knowledge of the world beyond your
Ximmediate vicinity. You must then explore, contact, and win wars against
Xall the other players, who are trying to do exactly the same things to you!
XThis is made harder by the limited information that the game supplies;
XExcept for the immediate vicinity of your own possessions, the entire view
Xis out-of-date; you don't see enemies until they're close by.
X.PP
XTyping "xconq" without any arguments will start up a game on a small map
X(usually 60x35) against one semi-intelligent machine player. Your first
Xcity will automatically produce a military unit for you to start with.
XWhen it is ready, the starting city will be surrounded with a box-shaped
Xcursor (the "unit cursor"), and the newly produced unit will appear inside
Xit, superimposed on the city. The mouse may then be used to designate
Xany location for that unit to move to. This movement may take several
Xturns, or the unit may stop before it gets there, usually because it is
Xadjacent to something unfriendly. To attack, just direct the unit to
Xmove into a square that has either a city or another unit, and see what
Xhappens (especially check out the notices at the top of the screen).
XWhen you capture a city, the program will ask you what sort of units
Xyou want that city to produce; '?' will show you the possibilities.
X.PP
XIn general, '?' will always work and show you what kinds of inputs
Xare possible, while '/' will tell you what you are looking at on the
Xscreen.
X.PP
XThe foregoing is sufficient to play - just jump in and go!
XAfter a few games, it should be clear what your units can and cannot do.
XThe game will end automatically when your opponents are no longer capable
Xof dominating the world (they have no cities and no units that could
Xcapture cities).
XThe following sections contain many boring details, and should be referred to
Xfor answers to questions. There is also material on designing your own
Xmaps, scenarios, and historical periods.
X.SH
XGENERAL
X.PP
XAn xconq game involves several
X.I sides,
Xeach of which has a human or machine player associated with it.
XA side owns a number of
X.I cities
Xand a number of
X.I units,
Xwhich are the territory and the armed forces of that side, respectively.
XThe game is divided into a number of
X.I turns,
Xduring which each side gets to move some or all of its units.
XWhile one side is moving, everybody else can only watch.
XAll the action happens over a map of a real or imaginary world that is
Xdivided into squares.
X.PP
XThe details of the game have been almost totally parametrized according
Xto historical period. The following sections will be rather vague as a
Xresult, since
Xthe information applies to times ranging from Ancient Greece to World
XWar III.
XLater sections will describe the periods that have been developed so far;
Xin addition, complete online help is available on the period in effect.
X.SH
XTHE WORLD
X.PP
XThe world map on which you play is a cylinder of variable height and diameter.
XAlthough it is always displayed as a rectangle, you can actually
Xcircumnavigate the world. The most northerly and southerly
Xregions are unknown frozen wastes, and you can't go there. The largest
Xworld map at present is the Earth at 1 degree resolution and going to
X60 north and 60 south - no less than 360 by 120
Xsquares! Wars on this take a long time... When starting up, you have the
Xchoice of several maps of real areas, depending on the period, or by
Xdefault you get a randomly-generated 60x35 map. You can get other sizes
Xfrom 35x35 up to about 360x160 (depending on the whims of the installer)
Xby using the -M option on the command line.
X.PP
XEach individual square of the world contains one kind of terrain,
Xwhich is assumed to more-or-less cover the entire square.
XThe set of terrains is fixed, and includes the types listed below.
XMonochrome xconq uses icons for each type of terrain, which cannot
Xpossibly be described verbally, so use the '/' command to help decipher them.
X.IP
XSea (dark blue) is assumed to be deep enough for any ship. Armies can't
Xwalk on water.
X.IP
XShallows (light blue or cyan) include shoals, reefs, rivers, and any
Xother sort of shallow water. They restrict movement of ships and
Xmay entirely prevent passage of the largest ships.
X.IP
XPlains (light green) are generally flat and hospitable areas.
XThey usually offer no impediments to movement.
X.IP
XForest (dark green) is dense forest or jungle, and may hinder movement for
Xsome kinds of units.
X.IP
XDesert (yellow) ranges from Saharan sands to Sonoran cacti. It is always
Xinhospitable but fast to move through (think of armor in North Africa).
X.IP
XMountains (brown) are relatively barren and at higher elevation, thus are
Xalso inhospitable to troops.
X.IP
XIce (white) is deep snow, ice, and glaciers. It is completely impassable
X(aircraft may of course fly over it).
X.LP
XAdjacency is on an 8-neighbor basis, that is, any given square is considered
Xadjacent to squares in diagonal direction. There is no adjustment for
Xdiagonal movement covering approximately 1.4 times as much distance as
Xrectilinear, so there's a small advantage to moving diagonally (seems to
Xbe insignificant in practice).
X.PP
XBy default, squares represent areas about 100 km on a side.
XSome maps have larger or
Xsmaller scales. Squares less than about 20 km on a side have some special
Xcharacteristics described with the relevant maps/scenarios.
X[not implemented yet]
X.PP
XXconq comes with some predefined maps covering particular areas or
Xhistorical periods. To date, the following have been defined:
X.IP 8
X.B earth2
XThe entire earth at about a 2 degree per square scale, going to 60 North
Xand 60 South, thus it is 180x60. The cities are most of the important
Xcities of the world, but some significant towns/bases are missing.
X.IP 8
X.B earth1
XThe earth at a 1 degree scale, resulting in a huge 360x120 map with over
X350 cities and towns. This one is great to look at, but very time-consuming.
XIt is the basis for several scenarios.
X.IP 8
X.B europe
XEurope from Norway to North Africa at about a 1/2 degree scale (50 km squares).
XThe towns are those of from about 1800.
X.IP 8
X.B rome
XThe same map of Europe, but with Roman towns.
X.IP 8
X.B greece
XThe whole Eastern Mediterranean world is included, as far as Rome in the
Xwest and Persia in the east. The town and cities are about correct for
X300 B.C., in the middle of the Hellenic Age.
X.IP 8
X.B pacific
XThe southern and western Pacific region, from India to Hawaii. At present,
Xthis one needs considerable editing (for instance to include Japan!).
X.SH
XCITIES
X.PP
XCivilization has always been associated with the building of cities.
XThey are quite important in this game - in fact, your territory is
Xdefined in terms of cities rather than land. Cities come in three
Xsizes: "city", "town", and "base". A "city" is a metropolis of the
Xlargest sort; it produces armies and equipment quickly, has a great
Xcapacity for barracking and repairs, and is very difficult to capture.
XTowns have less of all these capabilities, while bases are just temporary
Xcamps that do not produce anything. Bases are the only sort of city that
Xcan be built during a game, but unfortunately they are also easily destroyed!
XThey do have their uses, for instance as landing strips for aircraft, or
Xas resupply points for armies crossing large deserts. Only some kinds of
Xunits can build bases, depending on the period and type of unit.
X.PP
XAll cities have names - their proper names on real maps, and randomly
Xassigned ones on generated maps (believe it or not, all the names you
Xsee were taken from atlases). On the map, the city occupies an
Xentire square and the terrain of that square will be open land (farms
Xsupporting the city dwellers).
X.PP
XDuring the game, cities don't actually do anything besides produce
Xunits, repair them, and resupply them. Defenses against attack are
Xautomatic.
X.PP
XTowns have a small chance of revolting, and they always go back
Xto being neutral. A town will not revolt if it is not producing anything.
Xand the chance of revolt depends on your side's morale (explained
Xbelow).
X.SH
XUNITS
X.PP
XUnits can be almost anything: armies, balloons, triremes, cavalry, battleships.
XUnits move around, attack cities and other units, and build bases, among
Xother things. A unit is an indivisible/unmergeable entity - when not in
Xa city or on a transporting unit, it occupies an entire square, and neither
Xan enemy or friendly unit can pass through or be on that square at any time.
X.PP
XOnly towns and cities produce units, at a rate depending on the period, the
Xunit, and the size of the city. The first unit that is produced takes
Xsomewhat longer, then succeeding units come at a higher though constant rate.
XThere is no memory about production, so switching to a different type then
Xswitching back still incurs the extra startup time.
X.PP
XOnce created, a unit moves according to its orders, and subject to various
Xconstraints - armies can't swim, ships can't walk, etc.
XUnits are destroyed by disbanding them with a command, by losing them
Xin battle, by running out of supplies, by being taken prisoner when a city
Xis captured, or by garrisoning a captured city.
X.PP
XEvery unit starts out with a
Xnumber of hit points representing its strength, and a supply which is the
Xfood, fuel etc that it carries around. One unit of supply is used each
Xturn, whether or not the unit does anything.
XAdditional supply may be used up during combat, depending on the type of unit.
XSometimes a unit such as an army can live off the land. This condition may
Xbe met either by being on a particular type of terrain, or else next to it.
XAgain, this depends on the unit type, terrain type, and period.
XIn all periods, any type of city (including bases) will completely replenish
Xthe supplies of any unit that enters it, although this will not happen
Xuntil the beginning of the next turn.
X.PP
XThere are only two situations under which several units
Xcan be in the same square -
Xif one is a transport of some sort and the others are its passengers,
Xor if the units are in a city.
XFor instance, infantry and armor units can be passengers on a troop transport,
Xand atomic bombs are "passengers" on a bomber. Passengers board by moving
Xinto the square occupied by the transport, but will refuse to go if the
Xtransport is full or can't carry that type of unit. Once on board, the unit
Xloses the rest of its movement and may not move again until the next turn.
XPassengers always move with the
Xtransport, but may leave at any time if possible, either onto a valid terrain
Xor onto another transport.
XTo debark, just
Xmove the unit off (the cursor indicates that the passenger
Xand not the transport is to be moved).
X.PP
XCities are like stationary transports - they have a limited capacity, based
Xon the general rather than specific type of unit. The general types are
Xland, sea, and air, and each type of city has a specific capacity for that
Xgeneral type, usually 1-3 for land units, and 10-20 for sea and air units.
X.SH
XBATTLES
X.PP
XBattles happen when one unit attempts to move onto a square occupied by
Xan unfriendly unit or city. When the battle is unit vs unit, the outcome
Xis determined independently for each unit, based on a probability table;
Xthis means that both draws and mutual damage/destruction are possible.
XDamage is assessed using hit points, and if the hit points are zero, the
Xunit is destroyed, along with any passengers. Typically armies have only
Xone hit point each, so they are destroyed if hit. Ships are usually
Xmore durable, but are more vulnerable, since units lose movement capability
Xaccording to damage. For example a ship with 4 out of 8 hit points can
Xonly move at half speed (rounded down).
X.PP
XWhen a unit attempts to attack a city,
Xthe situation is more complicated. A unit
Xmay either assault a city, bombard it, or refuse to attack
Xat all. Assaults are carried out by armies usually, and if successful
Xresult in the capture of the city, at which point you can direct it to
Xproduce more units. The capturing unit is always disbanded, in order to
Xact as a garrison.
X.PP
XBombardment reduces the city's hit points, which are somewhat like those
Xfor units, but cities usually have more.
XLost hit points are regained at the rate of one or two per turn,
Xbut if the number of hit points drops below the number for the next
Xsmaller size of city, then the city is reduced to that size -
Xpermanently. If the city hit points go to zero, then it disappears
Xalong with any units in it, and cannot be reconstructed. If a city
Xis hit sufficiently hard to flatten any city in one blow, that is
Xconsidered a "nuke" and you get more spectacular visual effects, plus
Xthe city site is converted into desert.
X.PP
XCities don't have to take this kind of abuse stoically - any
Xunit that attacks a city has a chance to be hit back at, depending on
Xthe size of the city and the type of unit. The number of hit points
Xof damage is proportional to the size of the city.
X.PP
XIn some periods, capturing a city by direct assault was nearly impossible.
XA city is
X.I besieged
Xby placing your enemy units (not necessarily all on the same side) on every
Xone of the eight squares surrounding the city. This includes naval units
Xfor any sea squares. If this condition is achieved, then there is a
Xchance each turn that the city will surrender. The siege is only in effect
Xin those turns where the city is completely surrounded.
XWhen the city surrenders, one of the surrounding units will be randomly
Xpicked to accept the surrender. The unit will be disbanded to form the
Xgarrison and the city will go over to that unit's side.
X.SH
XORDERS
X.PP
XAlthough units have been said to "move", in actuality they follow orders,
Xsome kinds of which specify movement. When you are moving a unit
Xinteractively, it is following the order "Awake",
Xwhich just means that every turn it asks what to do next.
XThere are many kinds of orders. Some, such as movement in a given direction,
Xor to a given place, take parameters, but all take a repetition, which
Xtells for how many turns the unit will carry out the order.
X(For some orders, the repetition is not particularly meaningful,
Xsuch as in movement to a position.) Repetition is typically specified
Xas a prefix numeric argument to commands.
X
XOrders that a unit can do include:
X
XAwake - ask for a movement or other command.
X
XSentry - sit at the present location as long as the repetition says.
X
XMove Dir - move in the given direction.
X
XMove To - move to the given location if possible.
X
XRandom - move randomly for a while. This really is useful sometimes!
X
XReturn - go to the nearest city or transport by the shortest route.
X
XFollow Coast - attempt to follow a coastline. (flaky)
X
XBuild Base - the unit builds a base at its current location.
X
XFollow Leader - move towards another given unit. (flaky)
X
XPatrol - follow a preplanned course. (unfinished)
X
XMany of the commands just give these orders to the unit currently being
Xprompted about. In addition, a city may be given "standing orders", which
Xbe passed to any unit of the specified type entering or produced in that
Xcity. This is useful for a variety of purposes, such as staging fighter
Xplanes up to the front lines or sending ships out on standard patrols.
X.SH
XSIDES
X.PP
XSides in the conflict include yourself, zero or more enemies,
Xand neutral cities.
XNeutral cities don't do anything, but units will wake up when passing by.
XNeutral cities are more easily captured, but do
Xnot directly count towards victory (except that they can produce stuff!).
XHuman players will of course do whatever they want to, but if there are
Xseveral machine players, they will not attack each other, so as to better
Xconcentrate on YOU!
X.PP
XNames of sides are randomly assigned, or borrowed from the starting city,
Xif it has a particular name associated with it. Since it is usually hard
Xto remember which player has which name, many mentions of sides include
Xthe display that the side is using, or nothing if it is a machine player.
X.PP
XA very important number for each side is the
X.I morale.
XThis tracks the side's momentum in the game. It starts out at 5000, halfway
Xbetween a low of 1 (instant rebellion) and a high of 10000 (fanatical
Xwarriors). Most successes gain morale, most losses lose it. On the
Xaverage, losses in morale tend to be more greater than gains, so in
Xa stalemated situation, the morale of both sides drifts downward.
XIf it goes below 1000, the clock starts ticking; each turn a test
Xwill be made for assassination, the probability being 1% for a morale
Xof 990 and 99% for a morale of 10. If the assassination happens, that
Xside loses instantly. The most important determiner of morale is the
Xside's
X.I territory,
Xdefined as the number of bases, towns, and cities, each adjusted for
Xrelative size (each size is worth roughly five of the next smaller size).
XWhen an enemy city is captured, morale goes up by the same percentage
Xas your territory is increased, and down in the same way.
X.PP
XThe
X.I score
Xis also important. Although it follows morale much of the time, it is
Xmore a measure of generalship. The highest score will be achieved by
Xthe player who gets the most effect out of the fewest resources.
XCrude methods, such as the nuking of cities, actually lose rather than
Xgain you points.
XAt present, there is no sort of penalty or benefit for unusually low or
Xhigh score, though this may change.
XPluses for score: damaging the enemy, capturing enemy cities.
XMinuses for score: being damaged by enemy, losing units, losing cities,
Xcapturing neutral cities, nuking any city.
X.PP
XWhen a side loses, for whatever reason, all of its units are removed and
Xall remaining cities become neutral (thus easy pickings for the
Xremaining players who get to them the quickest).
X.PP
XThe game offers no mechanism for formal alliances between players, but
Xalliances inevitably happen in games involving more than two humans, so
XI have a few words of advice. First, an alliance between two of the
Xplayers is almost inevitable in a three-person game, and inevitably
Xresults in the "odd man out" being quickly defeated. In four-person
Xgames, the alliances should be decided after looking at the map via "-v",
Xso that one pair is not hopelessly separated. Five or more players is
Xgoing to be a free-for-all, but five human players makes a rather slow
Xgame, even with time limitations being used, and has not turned out to
Xbe very popular.
X.SH
XTHE GAME
X.PP
XYou start with one big city, for which you must specify a type of unit to
Xproduce. There will be about five towns within a few squares of this
Xcity, which are part of your "home territory" and should be captured
Xearly in the game, so as to have a production base.
X.PP
XThe order of play is for all cities to repair, produce, or prompt for
Xproduction if they are not producing anything.
XThen the program iterates through all sides, prompting each side to give
Xorders to any unit that is awake or becomes awake during the course of
Xits move. One consequence is that you will not have a chance to change
Xorders, look around, or anything if no city produces a unit and no units
Xwake up. This speeds playing but can be annoying if you get overrun and
Xlose without ever getting a chance to respond (but do you deserve anything
Xelse for pursuing a "hands-off" management strategy? :-) ). Sides that
Xlose are automatically cut out of the game. Since one additional iteration
Xis needed to verify that somebody lost, the final winner will have to go
Xthrough an entire turn before the game will exit (giving everything Sentry
Xorders is easy and quick to do).
X.SH
XTHE DISPLAY
X.PP
XWhen a game is started up, it opens a
Xnumber of windows, of which the most important is the area map (which is why
Xit gets the largest window!).
XAbove the area map are several windows for status
Xand notifications, and next to those is a turn counter and a indicator of
Xthe current player. The indicator is reverse-videoed on the host whose turn
Xit currently is. The lower right-hand corner has a map of the world (really
Xonly useful with color displays).
X.PP
XAll of the xconq windows are actually subwindows of a main window that has
Xa patterned background you can see here and there. You can iconify and move
Xthe main window, and the subwindows will keep their relative positions.
XThe largest of these is the map, which is a (typically) 35x35 section of the
Xworld in full detail. The view is scrolled around as necessary (remember
Xthat the world is cylindrical).
X.PP
XTo the right and down, you see a map of the whole world. This view is like
Xthe close-in map, but units and cities are rendered as solid blobs, since
Xthe world is too large to permit any detail. To assist in matching up the
Xtwo different views, the world map includes an outline square showing
Xwhere the close-in map is at.
X.PP
XThree text displays are stacked at the top of the screen. The uppermost
Xis about ten lines of messages about various notable occurrences, each prefixed
Xby the number of the turn in which it was sent. The display scrolls.
XThe next two lines are an information window that summarizes the status of
Xthe unit or city at the current cursor position. It can display info about
Xenemy things also, but of course the amount of information is limited.
XFinally there is a prompt window just above the map, in which all questions
Xappear.
X.PP
XThe list of sides playing appears above the world map. Sides that have
Xalready lost appear with a line through them, and all sides except the
Xcurrent one are grayed out, so that everybody always knows whose turn it is.
XThe name of the side, it host (if any), and the number of that side are
Xshown.
X.PP
XThe area map is drawn as a number of square blocks that have icons for
Xunits and cities superimposed.
XUnknown territory is black.
XYour own possessions appear in black,
Xneutral cities in gray, and all enemies in red. If there is more than
Xone enemy side, they are distinguished by the number of their side in
Xthe upper right corner of the icon. Of course, hidden enemy units
Xwill not be visible to you. Monochrome screens display enemies and
Xneutrals as inverted from your own appearance, and all enemy units/cities
Xhave numbers, to distinguish them from neutral cities.
X.PP
XAs mentioned previously, the view is a record of what has already been
Xseen, but is not updated except in the immediate vicinity of your own
Xcities and units. In multi-human games, all screens will be kept
Xup-to-date simultaneously, so that persons waiting for their turns
Xcan see enemy units moving around, cities change hands, and so forth.
X.SH
XINPUT
X.PP
XInput may be supplied both from the mouse and the keyboard.
XMoving the mouse cursor to a screen position and clicking either button
Xhas the effect of issuing MoveTo orders to the current unit, which will
Xbe carried out until successful. There are two exceptions. The first is
Xthat if the mouse is on the unit itself, the unit sits where it is until
Xthe next turn (same as the ' ' command below). If the desired new
Xposition is adjacent, the unit will unconditionally move there - this is
Xuseful for attacking enemies. At present, there is no special meaning
Xattached to particular mouse buttons.
X.PP
XAs an alternative to using the mouse,
Xthe standard directions (h = left, j = down, k = up,
Xl = right, y = NW, u = NE, b = SW, n = SE) can be used to specify movement.
XUppercase versions of these makes the unit move forever in that direction.
XLetter directions are really only of use when the mouse fails, or for diehard
XUnix game players for whom the direction keys have been permanently wired
Xin the brain!
X.PP
XAll commands may have a number prefixed of any size. Not all commands will
Xuse this number, while others need a number to know how often to repeat
Xan order. The default repetition is 100. The "current unit" is the one
Xbeing prompted about.
X.br
XCommands to give units orders include:
X.IP 5
X.B s
XSentry; unit "goes to sleep", only wakes up by explicit command or when enemy
Xor transport passes by.
X.IP 5
X.B w
XWake up; all units in the same square as the current unit have their orders
Xcanceled (whatever they were) and will ask about their next orders (not
Xalways immediately).
X.IP 5
X.B W
XWake all; wake ALL units up.
X.IP 5
X.B R
XRandom; unit moves randomly for awhile. It will wake up if conditions
Xare crowded and it can't find a valid move.
X.IP 5
X.B d
XDisband; unit disbands and disappears from game.
XMorale loss if the unit was not in or next to a friendly city.
X.IP 5
X.B r
XReturn; unit returns to nearest city or transport by shortest route.
XMost useful for fighters, but works with any unit.
X.IP 5
X.B c
XConstruct; build a base. Unit will ignore enemies passing by, but will
Xwake up if attacked(?). At end of construction time, unit will disappear
X(they are the new base's garrison) and base will appear, with a
Xmachine-synthesized name attached.
X.IP 5
X.B f
XFollow leader; follow another unit. Each turn the unit attempts to move
Xtowards its given leader, and wakes up if it actually tries to move onto
Xthe leader.
X.IP 5
X.B F
XFollow coast; follow a coast line. This can be applied to any unit, although
Xthe unit will immediately wake up again if it is not next to some sort of
Xterrain that it cannot move into.
XThe command will prompt for a standard direction to decide how to start, then
Xa contour-following algorithm will continually try to keep the unit adjacent
Xto impassable terrain (thus armor might use this command to go around a
Xmountain range or forest). Because the terrain is in discrete squares,
Xit is possible for the unit to get confused and end up going in a circle.
X.IP 5
X.B Space
XSit; unit goes on sentry duty for exactly one turn, and will ask for
Xa move in the next turn. Useful for waiting one or two turns.
X.IP 5
X.B e
XEmbark; put a unit in a city onto a random transport in the same city.
XThis is useful
Xwhen you don't want to move transport or unit out of the city just for the
Xpurpose of boarding.
X.LP
XCommands for cities must be given when the unit cursor is over the city
Xof interest. This can be done in any mode.
X.IP 5
X.B P
XSet city production; will ask for a type of unit and then set city to
Xproduce that unit. Any partial production will be discarded. If the
Xnew type is the same as the old type, nothing happens.
X.IP 5
X.B I
XIdle; cancel production for the given city and leave it idle for as long
Xas the prefix says (default 100).
X.IP 5
X.B O
XSet standing orders; will ask for type of unit, type of orders, any
Xnecessary parameters (depends on type of order), and a repetition which
Xdefaults to the usual value. When any unit of the appropriate type is
Xin the city at the beginning of a turn, it will be given the standing
Xorders and carry them out. There is no way to cancel standing orders
Xfor a city, although giving a standing order of 'w' is almost a substitute.
X.LP
XCommands for modes. There are only two defined at present: move mode (the
Xdefault) and survey mode. Most commands other than movement work the same
Xin both modes.
X.IP 5
X.B z
XSurvey mode; toggle into/out of survey mode. In survey mode, movement pushes a
Xcursor and allows you to look at things. Also, most commands are available,
Xfor instance, to give a unit new orders or to set city production.
X.LP
XCommands for game control.
X.IP 5
X.B M
XMessage; send a message to another side. The side is specified by giving its
Xnumber as a prefix to the command. You may type in a message up to the
Xlength of the prompt window. Backspace is available, but no text cursor will
Xbe visible. When a newline is entered, the message is sent immediately to
Xthe destination (of course, no reply will be possible until the other side's
Xturn).
X.IP 5
X.B X
XResign; resign from the game. The effect is the same as losing, except that
Xthe system messages are ruder.
X.IP 5
X.B Q
XQuit; terminate the game for everybody. This one asks for confirmation.
XNote that although this can be used even in multi-human games, applying it
Xwithout prior consent of the other players is definitely anti-social!
X.IP 5
X.B S
XSave game; record most of the state into a file. Some things are missing,
Xsuch as the current statistics. The saved game is ASCII and unprotected,
Xso it's possible to "checkpoint" games and engage in other kinds of cheating.
XThe game exits once it has been saved. To restart, start up the program
Xwithout any command line arguments, and in the directory where the save
Xfile is located. If players are specified on the command line, then they
Xoverride the saved player data. This is one way to switch sides; for instance,
Xsaving from "xconq" and restarting with "xconq -r -e 1 $DISPLAY" has the
Xeffect of you switching sides with the machine.
X.LP
XInformation commands.
X.IP 5
X.B ?
XGeneral help; show a summary of commands. This list is generated directly
Xfrom the command table, so it shows exactly the commands available.
XHelp is available in either mode and at any time when a unit is being
Xprompted to move. Some specialized prompts (such as for unit type) will
Xalso recognize '?', and will supply more details about possible answers
Xto the prompt.
X.IP 5
X.B /
XIdentify; display a short phrase indicating what is being seen
Xin the square at the current cursor position. This works in all modes,
Xand is useful for deciphering unusual colors or icons.
X.IP 5
X.B =
XList the characteristics of a type of unit. It will prompt for the type,
Xthen format all the period-specific details into a semi-readable summary.
XTo get a hardcopy of this, use '+'.
X.IP 5
X.B +
XWrite all the characteristics of all unit types into a file "parms.xconq".
XThis file may be printed, and is very useful for learning about a period.
X.IP 5
X.B V
XVersion; display the current version and other useless information.
XBe sure to include the version number when reporting bugs.
X.IP 5
X.B ^R, ^L
XRedraw the screen. Redrawing happens automatically most of the time.
XKeep in mind that xconq is a single program, despite opening multiple
Xscreens, and attempts to redraw will be ignored until your turn comes
Xaround.
X.LP
XAdditional commands include some for debugging purposes. They are
Xdocumented in the sources and with the help command.
X.SH
XPERIODS
X.SH
XSecond World War
X.PP
XThe ww2 period is the default built-in set of period parameters. It
Xrepresents units of about 1945, from infantry to atomic bombs. This is
Xthe most familiar, which makes it easier to play, but also more controversial,
Xsince historians have many conflicting theories about which kinds of
Xunits were most effective. This set is not influenced by anybody in
Xparticular, except that S.E. Morison has had some influence on the
Xproperties of naval units.
X.IP
XInfantry. The infantry division is the slowest of units, but it can go almost
Xanywhere. It is also quick to produce. Infantry is the staple of
Xcampaigns - a little boring perhaps, but essential to success.
X.IP
XArmor. The armor division is highly mobile and hits hard. Unfortunately,
Xit is limited to operating in open terrain - plains and desert. It also
Xtakes longer to produce. Armor can last twice as long in the
Xdesert as infantry. Both armor and infantry can
Xassault and capture cities; they are the only units that can do so.
X.IP
XFighters. A fighter is a squadron or wing of high-speed armed aircraft.
XTheir fuel supply can be gotten only at cities, towns, and bases, so they
Xmust continually be taking off and landing. Fighters are not too effective
Xagainst ground units or ships, but they eat bombers for lunch. Fighters
Xare very good for reconnaisance - important in a game where you can't always
Xsee the enemy moving!
X.IP
XBomber groups. Bombers are very powerful, being capable of destroying any
Xcity. Attrition rate in such activities is high,
Xso they're not a shortcut to victory! Bomber performance against
Xother units is less impressive, and of course fighters love to munch on them.
XBomber range is greater, but they are slower, taking several turns before they
Xmust land.
X.IP
XDestroyers. Destroyers are fast small ships for both exploration and
Xanti-submarine activities.
X.IP
XSubmarines. The favorite food of submarines is of course merchant shipping
Xand troopships, and they can sink troop transports with one blow.
XSubs can't be seen by the other side, although their
Xpresence might be suspected. Subs are always highly vulnerable to attack
Xby bombers or even fighters.
X.IP
XTroop transports.
XThis is how ground units get across the sea. They can defend
Xthemselves against ships and aircraft, but are basically vulnerable.
XThey're not very fast either.
X.IP
XAircraft carriers. Compensates for the fighter's limited range by providing
Xa portable airport. Carriers themselves are sitting ducks, particularly
Xwith respect to aircraft. Fighter patrols are mandatory.
X.IP
XBattleships. The aptly named "Dread Naught" has little to fear from other
Xunits of this period. Subs may sink them with enough effort, and a group
Xof bombers and fighters are also deadly, but with eight hit points to start,
Xa battleship can usually survive long enough to escape.
XBattleships are very effective against cities and armies, at least the
Xones on the coast.
X.IP
XAtomic bombs. The Final Solution; but they are not easy to use. A bomb
Xtakes a long time to produce, can move only a short way by itself, is
Xeasily destroyed by other units, reduces the range of bombers that
Xcarry it, and loses points for the side that dares to use it. Of course,
Xthe plus side is instant destruction for any city of any size!
X.PP
XCurrent thinking about optimal strategy for this period differs. In general,
Xblitzkrieg works, and can win the game in a hurry. The problem is to
Xmuster enough force before striking. One full troop transport is not
Xenough; the invasion will melt away like ice cream on a hot sidewalk, unless
Xreinforcements (either air or land) show up quickly. Air cover is very
Ximportant. While building up an invasion force, airborne assaults using
Xbombers and infantry can provide useful diversions, although it can be
Xwasteful of bombers. Human vs human games on the default map generally
Xlast about 100 turns, usually not enough time or cities to build atomic
Xbombs or battleships, and not a big enough map to really need carriers.
X.PP
XThere is one scenario for this period, which models WWII in Europe ca 1941
X(no USA involvement). Appropriately enough, it's called "ww2europe", and
Xis accessible via the "-s" option. The Allies are really England and Russia,
Xwhile the Axis is all of continental Europe (except Spain) and North Africa
Xwest of Egypt. Spain and Turkey are neutral, although both are easily
Xgrabbed up by the Axis. There is nothing anywhere else in the world, which
Xis the "earth1" map described above. Neither side has any units to start
Xwith, but many are scheduled to come out within the first five turns.
XThis scenario quickly gets into full-scale combat; be aware of battleships
Xand bombers. Since most of the country is open, armor is a good choice,
Xespecially for the Allies, because many Russian cities are far away from
Xthe front.
X.SH
XNapoleonic Wars
X.IP
XInfantry.
X.IP
XCavalry.
X.IP
XArtillery.
X.IP
XTransport.
X.IP
XFrigate.
X.IP
XFleet.
X.IP
XBalloon. Almost pure silliness, but can be useful for reconnaissance.
X.PP
XHasn't been played enough even to get the parameters plausible.
X.SH
XAncient Greece
X.PP
XThis period strictly covers about 600 to 200 B.C., since later times were
Xdominated by Romans with rather different sorts of units. Land warfare
Xwas most significant, with some notable sea-fights. Cities were nearly
Xuntakeable, so the action centered around sieges and field battles.
X.IP
XPeltast (light infantry).
X.IP
XHoplite (heavy infantry).
X.IP
XArcher.
X.IP
XCavalry.
X.IP
XBireme (small ship).
X.IP
XTrireme (larger ship).
X.IP
XElephant.
X.IP
XSiege Engine.
X.PP
XThe numbers border on the plausible, but again this one has not been
Xplayed enough to find the imbalances even, let alone decide on good
Xstrategies.
X.SH
XCUSTOMIZATION
X.PP
XXconq has been designed to facilitate the construction of new maps,
Xscenarios, and historical periods. Maps and scenarios may be built
Xwithout recompiling xconq, while periods require a new file (of mostly
Xdata) to be written and compiled in.
X.PP
XMaps are the easiest thing to customize. A map is an ordinary text file,
Xconsisting of some numbers, followed by an array of characters representing
Xthe terrain and city locations, followed by the names of cities in free
Xformat.
XThe numbers are "width height greenwich equator scale" where the first two
Xare the size of the map, the second two are the offsets of longitude and
Xlatitude (for coordinate printing), and the last is the length of a square
Xside in km. Only the first two numbers are really important.
X.PP
XThe terrain data is a number of long lines of characters. The length of
Xthe lines must be exactly the width of the map. The characters for
Xterrain and city types are:
X.IP
X . sea
X.IP
X , shallows
X.IP
X + open land
X.IP
X % forest
X.IP
X ~ desert
X.IP
X ^ mountains
X.IP
X _ ice
X.IP
X / base
X.IP
X * town
X.IP
X @ city
X.PP
XSince the format allows only one character at any coordinate, the program
Xjust assumes that the terrain under a city or base is open land. The only
Xway to avoid this restriction is to build a scenario. Maps should have
Xice on the northern and southern edges; also, remember that the map wraps
Xaround in the east-west direction.
X.PP
XThe city names are free-format text following the map data. Each city name
Xis separated by whitespace. A backslash may be used to escape any spaces
Xthat are part of a city name, as in "New\\ York". Any city or town may also
Xhave the name of a side associated with it using a "*". This side name will
Xbe used if a player starts in that city. Example: "New\\ York*New\\ Yorker"
Xwill cause any player starting in New York to be called the "New Yorkers".
X.PP
XThe easiest way to generate a map is to use
X.I mkmap(6).
XIts result goes to
Xstandard output and may be redirected into a file for further editing.
XFrequently, a random map is not-quite-ideal; a little judicious modification
Xcan remove undesirable features or add new ones. The requirement of
Xlong lines is difficult for most editors to handle, so utilities "split"
Xand "rejoin" have been provided to break a map into 80-column pieces and
Xthen reassemble them. Both take a single filename for a map. The nine map
Xpieces are suffixed with numbers.
X.PP
XScenarios are essentially modified saved games. Since the saved game format
Xis text, it is easy to modify, although the sources should be consulted
Xfor details. Scenarios don't need the whole map or views from each side
Xsaved; to get this alternate form of saving, use the "-D" (debug) option
Xwith
X.I xconq
Xand save in the usual way.
X.SH
XDESIGNER NOTES
X.PP
XAlthough VMS Empire was an extremely absorbing game, it had a number of
Xdefects that became evident after awhile. Chief among these was lack of
Xvariety. There were two different maps, both of which became annoyingly
Xfamiliar.
X.PP
XRandomly-generated maps can have some of
Xtheir own annoying properties, such as islands that can't be gotten off
Xfrom, cities on islands in middles of lakes, little or no land at all,
Xand so forth. We accept that some maps will just be bad, and rely on
Xthe player to detect this quickly and start a fresh game instead.
X[Unfair maps are a different problem entirely, not well solved]
X.PP
XXconq started out as an empire workalike, but after a while, it became
Xclear that many worthwhile features could be added. Even later, it occurred
Xto me that the basic game machinery could be used in contexts outside
Xof modern warfare on random maps, and I put together a great deal of
Xcustomization machinery. Each game is defined first by a period, which
Xsets up the types of units and cities, then by a map of real or random
Xterrain, then by a specific scenario with starting cities and units.
XSome concepts, such as types of terrain and types of unit orders, remain
Xconstant, and are thoroughly wired into the program.
X.PP
XThe period defines the basic flavor of the game. It amounts to a list
Xof unit types and their characteristics, which can vary widely. The
Xlimitations on possible characteristics is the true definition of xconq.
XFor instance, a unit is either always hidden or always visible - it
Xnever depends on the terrain or on the unit doing the looking.
X.PP
XGiven this, it was crucial to settle on the types of parameters that
Xwould make sense over the greatest span of history, but without being
Xunduly complicated or expensive to implement. Also, parameters needed
Xto make sense at the strategic level and partly at the operational level.
XSo for instance it is never possible to have a total surprise attack;
Xthe defender always gets a chance to hit back. All units have only
Xone number expressing their state of repair, and just one for supply,
Xsince considerations of engine vs personnel damage, or food vs fuel,
Xare much too detailed for this level of game.
X.PP
XThe basic classes of parameters are: movement, combat, repair, supply,
Xproduction rate, and construction capability.
X.PP
XThe control structure of alternating turns, although somewhat lacking
Xin realism, is necessary for playability, even in a computerized game.
XSimultaneous movement is very slow and awkward for games involving more
Xthan one or two moving pieces. Interleaved movement works for human vs
Xmachine, but is ill-suited to human vs human games, since everyone has
Xto be ready to move all the time. In xconq, it is possible to do other
Xthings while the other players conduct their turns.
X.SH
XIMPLEMENTATION
X.PP
XThis game is written in fairly standard C. It of course uses lots of
XX features, but relatively few Un*x calls, and should be readily ported.
XThe X routines have been isolated into three dedicated files,
Xso it would not be
Xa herculean task to convert to some other graphics system. (The first
Xversion of this program was based on curses, and conversion to X took about
Xtwo days. Conversion back would be much harder now, since I've taken
Xadvantage of the extra screen space that X offers.)
X.SH
XACKNOWLEDGEMENTS
X.PP
XThanks to Eric Muehle, Mohammad Pourheidari, Bob Kessler, Kevin Deford,
XMark Bradakis, Grant Weiler, Jed Krohnfeldt, Sandra Loosemore and others
Xat Utah for
Xinitial playtesting and endurance of apparently endless bugs and
Xmisfeatures. Thanks also to Leigh Stoller, who suggested the port to X.
END_OF_xconq.nr
if test 42956 -ne `wc -c <xconq.nr`; then
echo shar: \"xconq.nr\" unpacked with wrong size!
fi
# end of overwriting check
fi
echo shar: End of archive 1 \(of 7\).
cp /dev/null ark1isdone
MISSING=""
for I in 1 2 3 4 5 6 7 ; do
if test ! -f ark${I}isdone ; then
MISSING="${MISSING} ${I}"
fi
done
if test "${MISSING}" = "" ; then
echo You have unpacked all 7 archives.
rm -f ark[1-9]isdone
else
echo You still need to unpack the following archives:
echo " " ${MISSING}
fi
## End of shell archive.
exit 0