|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T x
Length: 29125 (0x71c5) Types: TextFile Names: »xconq.ms«
└─⟦b20c6495f⟧ Bits:30007238 EUUGD18: Wien-båndet, efterår 1987 └─⟦this⟧ »EUUGD18/X/Xconq/xconq.ms«
.TL LIBERATING THE WORLD (Made Simple) .AU Stan Shebs .AI Department of Computer Science University of Utah .AB This is an in-depth document on version 5 of the \fIxconq\fP family of programs. Version 5 is quite different from earlier versions; players familiar with those should read everything in here, especially the section on important changes. All aspects of play are covered. Details on customization may be found in a companion document. .AE .SH INTRODUCTION .PP .I War is a matter of vital importance to the State; the province of life or death; the road to survival or ruin. It is mandatory that it be thoroughly studied. -- SUN TZU (ca 400 BC) .R .LP Welcome to \fIxconq\fP, a chance for you to free the world from domination by evil empires. It is similar to previously distributed empire-building games, but with many more features. The same basic game is available with several different interfaces. \fIXconq\fP is a fully X-based multi-player game, allowing almost any combination of human and machine players, and opening up remote X windows as necessary. There is also a restricted variant \fIcconq\fP that needs the curses terminal package only, but allows only one human player. .LP In the standard game, you start with one city and no knowledge of the world beyond your immediate vicinity. You must then explore, contact, and win wars against all the other players, who are trying to do exactly the same things to you! This is made harder by the limited information that the game supplies; except for the vicinity of your own possessions (and for certain type of units), the entire view is out-of-date, and you won't see enemies until they're close by. .LP The "standard game" is played on a small (usually 60x30 hexes) randomly generated map, against one machine player. Your first city will automatically start building your first military unit (usually infantry). When it is ready, the starting city will be overwritten by a picture of the unit, which is itself surrounded by a box-shaped cursor (the "unit cursor"). The mouse (or standard Unix direction keys) may then be used to designate any location for that unit to move to. This movement may take several turns, or the unit may stop before it gets there, usually because it is adjacent to something unfriendly. To attack, just direct the unit to move into a hex that shows another unit, and see what happens (flashes, and maybe a notice at the top of the screen). When you capture some kinds of units (usually cities), \fIxconq\fP will ask you what sort of units you want that unit to produce; '?' will display the possibilities. .LP In general, '?' will always work. When typed during normal movement, you will get a series of help screens, including commands, news, and unit characteristics. (This info may be written into printable files if the interface doesn't have the screen space necessary.) '/' will tell you what you are looking at on the screen. .LP The foregoing is sufficient to play - just jump in and go! After a few games, it should be clear what your units can and cannot do. The game will end automatically when your opponents are no longer capable of winning (either they have nothing left or they have given up). The following sections contain many boring details, and should be referred to for answers to questions. .SH DEFINITIONS OF TERMS .LP An xconq game involves several \fIsides\fP, each of which has a human or machine player associated with it. Sides may be enemies, allies, or neutral with respect to each other, often start out in a hexagonal \fIcountry\fP. A side owns a number of \fIunits\fP, which includes the cities and the armed forces of that side. Units may also be \fIneutral\fP, and belong to no side (this is different from being on a neutral side). Units may be inside other units, in which case the one inside is in \fIoccupant\fP, and the other is a \fItransport\fP (even if it can't move). Units always have \fIorders\fP that they follow, even when they appear to be under manual control. There are also \fIstanding orders\fP that get passed to occupants automatically. The game is divided into a number of \fIturns\fP, during which each side gets to move some or all of its units. All the action happens over a \fImap\fP of a real or imaginary world that is divided into hexagonal shapes usually called \fIhexes\fP. Each hex has a \fIterrain\fP assumed to cover the entire hex. In some games, hexes also have a \fIpopulace\fP belonging to some side. Terrain on the map can produce \fIresources\fP, which are natural items ranging from water and food to gold and weapons; resources being carried by a unit are also called \fIsupplies\fP. \fIScenarios\fP are predefined games that set up maps, sides, units, and \fIwin/lose conditions\fP, which define the circumstances under which one or more sides win or lose in the scenario. .LP The numbers and kinds of units, resources, and terrain are not built in; they are defined by a historical (or ahistorical!) \fIperiod\fP. This means that the following sections will be somewhat vague on specific units and behaviors, since the information applies to times ranging from Ancient Greece to Star Wars. Later sections will describe some of the periods that have been developed so far; in addition, complete online help is available on the period in effect. .SH THE WORLD .PP .I Geography defines the background to conflict. Gold mines are usually in the mountains, far from the sea. Islands tend to be left alone, unless they are on a direct path somewhere else. A seacoast town can be strategically useless if its approach is through shallow water. Attention to terrain and its effect on one's units can make the difference between winning and losing. .P .LP The world map on which you play is a cylinder of variable height and diameter. Although it is always displayed as a rectangle, you can actually circumnavigate the world. The most northerly and southerly rows of hexes are out of bounds. Sizes can range from 20x20 "quicky" maps to the Earth at 1 degree resolution between 60 north and 60 south - no less than 360 by 120 hexes! When starting up, you have the choice of several maps of real areas, depending on the period, or by default you get a randomly-generated 60x30 map. You can get other sizes from about 10x10 up to whatever your machine's memory can hold, by using the \fB-M\fP option on the command line. The \fB-m\fP command line option loads a named map, and the \fB-x\fP option may also offer a menus of maps to use. Predefined maps usually have their own documentation, which is displayed on one of the help screens. .LP Each individual hex of the world contains one kind of terrain, which is assumed to more-or-less cover the entire hex. The exact set of terrains depends on the historical period; the set below is from the standard period, and is actually shared by many periods. Monochrome \fIxconq\fP uses icons for each type of terrain, which cannot possibly be described verbally, so use the help commands to decipher them. .IP Sea (dark blue) is assumed to be deep enough for any ship. Armies can't walk on water. .IP Shallows (light blue or cyan) include shoals, reefs, rivers, and any other sort of shallow water. They restrict movement of ships and may entirely prevent passage of the largest ships. .IP Plains (light green) are generally flat and hospitable areas. They usually offer no impediments to movement. .IP Forest (dark green) is dense forest or jungle, and may hinder movement for some kinds of units. .IP Swamps (gray) are half water and half land, and impassable to almost everybody. .IP Desert (yellow) ranges from Saharan sands to Sonoran cacti. It is always inhospitable but fast to move through - think of armor in North Africa. .IP Mountains (brown) are relatively barren and at higher elevation, thus are also inhospitable to troops. .IP Ice (white) is deep snow, ice, and glaciers. Only specially equipped ground units can pass over it, although most aircraft can fly over. .IP Vacuum (black) is outer space, included for the purpose of doing futuristic periods. .LP Each hex is adjacent to six others, and there is no special border to cross. By default, hexes represent areas about 100 km on a side, although many maps have larger or smaller scales. .LP Randomly generated maps vary in their "roughness", and in the percentages of each kind of terrain. These properties also depend on the period, and it is worthwhile to have a general idea of the values. Percentage coverage is simple (for instance, the earth is 70% covered by water), but roughness is more subtle; essentially the "jagginess" of the terrain. Very rough terrain has lots of sharp peaks and small islands, while smooth terrain has large flat continents. .LP SIDES .PP .I Politics provides the context for war; the war being a result of failed policy. The leader of a country is faced with the problem of achieving certain goals, either externally- or self-imposed. Diplomacy can sometimes accomplish the desired outcome, and is much cheaper to boot. When it fails, one country or another declares war, and any alliances immediately broaden its scope. Declaring peace again is much more difficult... .R .LP Sides in the game can be allies or enemies in various combinations. Any two sides can form a formal alliance; human players do it by sending the message "alliance" to each other using the message command (see below). Machine players are "aware" of their relative incompetence, and will usually ally with each other (except in the case of a machine player attached to a display, so as to facilitate debugging). Players may become neutral or declare war by sending the messages "neutral" and "war" to another side. Scenarios may sometimes set up particular patterns of alliances, although there is nothing to prevent the players from changing them around during the game. If all the sides left in a game are allied, then it automatically ends. .LP Some displays distinguish alignments by using the same colors for allies as for yourself, while painting neutrals and enemies in distinctive colors. For others, you just have to remember who is on whose side. .LP Names of sides come from a scenario or are randomly generated from a list of names, depending on period. If the period doesn't define any names for sides, then the list will be 100+ contemporary names (including Botswanans and Peruvians). Players may also rename themselves, using a command (see below). Since it is usually hard to remember which player has which name, many mentions of sides include the display that the side is using (or nothing if a machine player), or sometimes the number of the side (especially for input). .LP When a side loses, for whatever reason, units are either destroyed or made neutral (depending on unit and period). In the standard period, infantry is destroyed, while cities become neutral (thus easy pickings for the remaining players who get to them the quickest). .LP Informal alliances frequently happen in games involving more than two people, so I have a few words of advice. First, an alliance between two of the players is almost certain in a three-person game, and inevitably results in the "odd man out" being quickly defeated. In four-person games, the alliances should be decided after looking at the map via "-v", so that one pair is not hopelessly separated. Five or more players is going to be a free-for-all of formal and informal alliances. Some scenarios are designed with a particular number of players in mind; hopefully they will also have some natural balance. .SH UNITS .PP .I War is based on the application of force to the other side, using whatever is available; from spears and arrows to the high-tech equipment available as a significant fraction of a nation's GNP. .P .LP Units can be almost anything: armies, balloons, triremes, cavalry, battleships, bridges, headquarters, cities. Units move around, attack other units, produce resources, and build more units, among other things. Individual units occupy entire hexes, and no other unit can enter that hex unless it can occupy or be occupied by the unit already there. .LP Only some kinds of units can build other units, at a rate depending on the period, the unit being built, and the unit doing the building. The first unit that is produced takes somewhat longer, and the very first unit built by a side can take even longer (research and development time), but then succeeding units come out at a constant rate. There is no memory about production, so switching to a different type then switching back still incurs the extra startup time. Most units that do building will do it all the time, and only stop when explicitly directed to (such as cities), while others need to be directed to build, and cannot move while doing so (such as engineers building a base). .LP Once created, a unit moves according to its orders, and subject to various constraints - armies can't swim, ships can't walk, etc. Units can sometimes be disbanded with a command (depending on the period), by losing them in battle, by running out of supplies, by being taken prisoner when a unit is captured, or by garrisoning a captured unit. .LP Every unit starts out with a number of \fIhit points\fP representing its strength, and possibly supplies of food, fuel etc that it carries around. Supplies are used up by movement, combat, and by just existing, and are created by production on certain terrain types, or by transference from some other unit. .LP There is only one situation under which several units can be in the same hex at once; if one is a transport of some sort and the others are its passengers or occupants. The notion of "transport" and "occupant" is general, and covers fighters on carriers, ships in port, bombs in bombers, and troops being led by a general. Occupants board by moving into the hex occupied by the transport, but will refuse to go if the transport is full or can't carry that type of unit. Getting on board takes a number of moves of that unit; if there are any left, it may move off or take some other action. Transports can also move over a occupant to take it on, but only if the transport can move on the terrain that the occupant is on. Occupants always move with the transport (that's what transporting is all about!), but may leave at any time if possible, either onto a valid terrain or onto another transport. To debark, just move the unit off (the cursor indicates that the occupant and not the transport is to be moved). Usually, you will want to put the occupant on sentry duty while moving the transport, and so must wake the occupants up before they can be moved again. .SH THE GAME .LP Games may be predefined scenarios, which define the map, sides, and units, or they may be randomly generated. If randomly generated, depending on the period, you start with either a country-full of units or just one, which may or may not have its production defined already. If you start with one, the period may also define some neutral units in your country, which should be captured as quickly as possible. .LP Sometimes the map will be too small or have the wrong terrain, and then \fIxconq\fP will fail at placement and exit instantly. There is not much you can do at that point except to try again or relax the constraints, perhaps by reducing the number of sides or increasing the map size. (This can also be fixed by altering the period - see the customization document for details.) Since there is a lot of randomness in placement, second tries are frequently successful, although tenth tries usually indicate a real problem. .LP A turn consists of several phases, although only one actually involves player interaction: .IP Spy\ Phase 5 Leakage of information from one side to another. .IP Disaster\ Phase 5 Revolts, surrenders, attrition, and accidents. .IP Build\ Phase 5 Construction of new units and repair of damaged ones. .IP Supply\ Phase 5 Production and distribution of resources. .IP Movement\ Phase 5 Automatic and manual movement of all units. .IP Consumption\ Phase 5 Details relating to supply usage during movement. .LP During the movement phase, the program iterates through all units, prompting each side to give orders to any unit that is awake or becomes awake during the course of its move. One consequence is that you will not have a chance to change orders, look around, or do anything else if no unit produces a unit and no units wake up. This speeds playing but can be annoying if you get overrun and lose without ever getting a chance to respond (but do you deserve anything else for pursuing a "hands-off" management strategy?). Sides that lose are automatically cut out of the game. Since one additional iteration is needed to verify that somebody lost, the final winner will have to go through an entire turn before the game will exit (doing the sentry command on everything is easy and quick). .LP The game ends when the win/lose conditions have been met; these vary from scenario to scenario. For a randomly-generated game, the end comes when no mutual enemies are left, whether by elimination or by peace. Usually this means that only one side is left alive, but multiple machine players (not associated with displays - the usual case) are always allied, and thus may win as a group. This also means that a single member of the alliance will not resign until the position of the whole alliance is hopeless; after all, the WWII Allies included several brigades of Polish troops after Poland was overrun. .LP The last player must type a key to close down the windows (this is so that they will stay up for everybody to look at). When the game closes down, the winners (if any) will be listed. If the STATISTICS option has been set by the installer, \fIxconq\fP will write a file "stats.xconq" into the current directory. This file summarizes some crucial statistics concerning combat performance, losses, and other miscellany. It is quite useful for rationalizing your humiliating defeat! .SH DISASTER PHASE .PP .I War is inherently random. Both military and civilian units desert, get diseases, have accidents, defect, and surrender without a struggle. These effects cannot be eliminated completely, but can be reduced by keeping one's forces out of hazardous situations and by keeping morale up. .P .LP Three types of disasters can befall a unit during the disaster phase: revolt/surrender, attrition, and accidents. .LP Revolts and surrenders are really the same sorts of occurrence; a unit changes sides spontaneously, perhaps to neutrality, perhaps to the side of a nearby enemy unit. During every disaster phase, each unit makes a revolt check. The revolt chance is a hundredth percentage. When a unit revolts, it changes to its original side (whatever the unit started out as - i.e. your initial units will never revolt). Occupants will either change over or be killed. Any construction will be cancelled, unless the scenario is one in which construction changes are not allowed. .LP Surrender only occurs if a unit is capable of capture is present. The capturing unit does not move. Occupants of the surrendering unit also change over or die. Chance of surrender is increased by low unit morale. .LP The chance of surrender can be greatly increased (depending on period) by surrounding the unit completely. This includes naval units for any sea hexes. One of the surrounding units must be capable (even if only a small chance) of capturing the unit by direct attack. The siege is only in effect in those turns where the unit is completely surrounded. When the unit surrenders, one of the "capture-capable" units will be randomly picked to accept the surrender, and things happen as for a direct assault (described below). Note that if several sides are surrounding the same unit, the selection is still random from among those sides, as long as the side is an enemy. .LP Attrition is a "slow death" process applicable primarily to multi-hp units. It takes away some number of hit points each time it occurs, and kills units only if they have no points left. Attrition is also specified in hundredths of a percent, and depends on unit type and terrain type. Morale drops by 1 when attrition occurs. A message will be displayed as well. .LP Finally, there is a chance for an accident to destroy a unit instantly and totally. Like attrition, this depends on both unit and terrain type, and is measured in hundredths of a percent. If the accident occurs, the unit is killed along with all occupants. A message will be displayed. .SH BUILD PHASE .PP .I Sustained efforts in a war depend vitally on the replacement and repair of forces destroyed or damaged in combat. In total war, the production base constitutes a chief strategic target, to be isolated or destroyed if possible. Repair of units is also significant since a battle may result only in damage, but be successful nevertheless if units must retire (as a cheaper alternative to new production). Historically, battle damage has resulted in the termination of an entire campaign. .P .LP During the build phase, units construct new units and repair damaged occupants (or themselves). .LP Construction is straightforward; the schedule is decremented once/turn. When it has counted down to zero, the unit is created, and placed either as an occupant of the builder, or the builder is made to occupy the new unit. If neither alternative works (perhaps because the builder is full already), then completion is postponed, and attempted on the next turn. This will be repeated indefinitely. If the new unit cannot be placed at all, it is thrown away. If the period specifies that the builder is to guard the new unit, then the builder will be assigned to garrison the new unit, and is destroyed. .LP Repair happens automatically if the damaged unit contains or is contained by another unit capable of repairing, or if the unit can repair itself. The repair rate is depends on both the repairer and repairee, and can happen no faster than one hp/turn. .SH SUPPLY PHASE .PP .I The Allies floated to victory on a sea of oil. -- LORD CURZON. .P .LP Resources themselves are basically inanimate material that come in varying amounts and are governed by conservation laws. They can be produced, moved around, and consumed during various activities. Resources originate either as supplies carried by units at the outset, or more typically, through production by units. Production rate depends on unit, resource, and terrain types, and is unaffected by side changes, combat, or anything else. Produced resources go into the producing unit's storage. .LP Excess production is discarded, unless it can be unloaded into the producer's occupying units, or distributed to nearby units via \fIsupply lines\fP. Supply lines automatically exist between units that are close enough (as decreed by the period), and there is no need for explicit manipulation. .LP Units consume their supplies, both in the course of existence, and by motion/combat. The rate depends on period and unit type; it consists of an overhead consumed each turn without fail, and consumption for each hex of movement. The total is a max, not a sum, since units with a constant consumption rate are not likely to need additional supplies to move (consider foot soldiers who eat as much sitting around as they do walking). Supplies may also be consumed for production and repair, again depending on period and unit types, but this consumption happens during the build phase. Consumption is not affected by the situation of the consuming unit; armies in troop transports eat just as much as when in the field. .LP Supply line length depends on the period and the units on both ends, but is not affected by the intervening terrain. Supply redistribution is managed by logistics experts, who are ignorant of the war effort and seek only to even everything out. The redistribution method is rather adhoc; units try to get rid of all their excess supply, and try to take up supply from other units within supply range. Each direction is controlled independently, so for instance airplanes can get automatically refueled from a nearby city, but not from each other. No unit will transfer all of its supply via supply lines. Normally units in the same hex can exchange supplies, but some periods can disable this behavior, so that explicit transfer using the give and take commands is always necessary. .SH MOVEMENT AND COMBAT .LP The movement phase is the one in which all the action happens. At its outset, the phase computes the number of moves available to each unit. This value is essentially the maximum of the unit's moves on each type of terrain. The movement phase continues until all these moves have been expended in some way or another. .LP Some periods may define a small chance of random movement, in which the unit moving actually goes in some other direction than that intended. This is a potentially dangerous occurrence, since the unit will be destroyed if the hex is impassable or contains another unit (whether or not the other unit can take the moving one as an occupant). .LP All combat occurs during the movement phase. Battles happen when one unit attempts to move onto a hex occupied by an unfriendly unit. In most periods, each unit attacks the other equally well, but if "counterattack" is not enabled, then the defender just has to sit and take the punishment. The outcome is determined independently for each unit, based on a probability table; this means that both draws and mutual damage/destruction are possible. The odds are the same whether a unit is attacking or being attacked. Ammunition may be expended by each unit in each combat - if the ammo is gone, then the attacker will not attack and the defender cannot defend itself. The results are announced both by a message and by some flashes on the screen (the size of the flash corresponds to damage seriousness). Damage is assessed using hit points, and if the hit points are zero, the unit is destroyed, along with any occupants. Typically armies have only one hit point each, so they are destroyed if hit. Units with multiple hit points may be \fIcrippled\fP if their hit points drop below a period-specified level. Crippled units move more slowly (in proportion to their damage), have reduced transport volume, cannot repair anything, and do not make progress on any construction. The final outcome of combat depends on whether the defender was destroyed. If so, the attacker will move into the defender's position (if possible), otherwise no movement will happen. .LP If a unit is hit sufficiently hard, that is considered a "nuke" and you get more spectacular visual effects, plus the hex is converted into desert or something else desolate. .LP Some units are capable of capturing other units, with a probability depending on the types of both units involved. If the capture attempt is successful, the capturer will move into the hex if possible, either as occupant or transport. In some periods, the capturer may be all or partially disbanded, to serve as guards. The regular attack as described above always happens first. .SH ORDERS .PP .I A perennial feature of the highest level of command is its inherent complexity. Although the use of subordinates reduces the bewiderment somewhat, the commander-in-chief must still keep in mind hundreds of apparently unrelated facts; the state of the weather, the past performance of units, the current goals of the war, and many other things. It is very important that lower-level units be able to operate on their own as much as possible. .R .LP Although units have been said to "move", in actuality they follow orders, some kinds of which specify movement. When you are moving a unit hex-by-hex, it is following the order "Awake", which just means that every turn it asks what to do next. There are many kinds of orders. Some, such as movement in a given direction, or to a given place, take parameters, but all take a repetition, which tells for how many turns the unit will carry out the order. (For some orders, the repetition is not particularly meaningful, and is ignored.) Repetition is always specified as a prefix numeric argument to commands. .LP Orders that a unit can do include: .IP Awake 10 ask for a movement or other command. .IP Sentry 10 sit at the present location as long as the repetition says. .IP MoveDir 10 move in the given direction. .IP MoveTo 10 try to move to the given location. .IP FollowCoast 10 attempt to follow a coastline. .IP FollowLeader 10 move towards another given unit (which must be one of your own). .IP Patrol 10 go back and forth between two points. .LP Most movement commands just give these orders to the unit currently being prompted about. In addition, a unit may be given "standing orders", which will be passed to any unit of a particular type entering or produced in that unit. This is useful for a variety of purposes, such as staging fighter planes up to the front lines or sending ships out on standard patrols. .so xconq2.ms