From mipos3!intelca!oliveb!ames!ll-xn!mit-eddie!uw-beaver!tektronix!tekgen!tekred!games-request Fri Jul 10 17:33:03 PDT 1987 Article 34 of comp.sources.games: Path: td2cad!mipos3!intelca!oliveb!ames!ll-xn!mit-eddie!uw-beaver!tektronix!tekgen!tekred!games-request From: games-request@tekred.TEK.COM Newsgroups: comp.sources.games Subject: v01i081: xconq - multiplayer strategy game for X-windows, Part01/07 Message-ID: <1383@tekred.TEK.COM> Date: 10 Jul 87 00:51:19 GMT Sender: billr@tekred.TEK.COM Lines: 1385 Approved: billr@tekred.TEK.COM Submitted by: "Stanley T. Shebs" 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 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 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 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 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 version.h <<'END_OF_version.h' X#define VERSION "1.00 (6/8/87)" END_OF_version.h if test 32 -ne `wc -c 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