Skunkware 5

home *** CD-ROM | disk | FTP | other *** search

/ Skunkware 5 / Skunkware 5.iso / man / cat.1 / xconq_custom.1 < prev next >

Wrap

Text File | 1995-07-26 | 71.6 KB | 1,717 lines

CCCCUUUUSSSSTTTTOOOOMMMMIIIIZZZZIIIINNNNGGGG XXXXCCCCOOOONNNNQQQQ ((((MMMMaaaaddddeeee SSSSoooommmmeeeewwwwhhhhaaaatttt SSSSiiiimmmmpppplllleeee)))) Stan Shebs Department of Computer Science University of Utah _A_B_S_T_R_A_C_T For advanced players who desire new chal- lenges, _x_c_o_n_q provides several customization mechanisms. It is possible to build new maps, scenarios, and historical periods. This document describes the customization process in excruciat- ing detail. The reader is assumed to be familiar with _x_c_o_n_q and its basic documentation. _I_N_T_R_O_D_U_C_T_I_O_N _X_c_o_n_q has been designed to facilitate the construction of new maps, scenarios, and historical periods. All these additions happen through a single mechanism, the _m_a_p_f_i_l_e, which comes in several parts, and may also load other map- files. Saved games are very detailed mapfiles; less detailed mapfiles are more suitable as scenarios. Maps and period descriptions are mapfiles with most sections missing. Mapfiles are created either by text editing, by _x_c_o_n_q, or by a combination of both. Since they are mostly read by varia- tions on C's _s_c_a_n_f function, the format is rather rigid; numbers may not be omitted, no blank lines are allowed (but whitespace between numbers on a line is OK), and mistakes will not always be recognized. The one general exception is the period description, which is read by a lexical analyzer, which allows free-format input. Other more specific excep- tions will be noted below. _M_A_P_F_I_L_E_S A mapfile is a normal ASCII text file. It begins with a header line of the form XXXXccccoooonnnnqqqq _n [+-][+-][+-][+-][+-][+-] _d_e_s_c_r_i_p_t_i_o_n[;] where _n is the number of additional mapfiles to be loaded (up to 16 or so in all), each + or - indicates the presence or absence of a particular section, and the _d_e_s_c_r_i_p_t_i_o_n is September 10, 1993 - 2 - free-form text (remainder of the line) describing the map- file. Note that that all reading/writing in the mapfile is case-sensitive, including the header words. The sections are for version, period, map, globals, sides, and units, in that order. Most sections vary in size, and some vary also in the detail of the information they contain. Most include extension flags, which are reserved for future expansion of mapfiles. Additional notes may be included by terminating the _d_e_s_c_r_i_p_- _t_i_o_n with a semicolon (with NO whitespace following). In such a case, the following text lines will skipped over until a period "." is seen by itself on a line. Following the header are the names of the _n mapfiles, one to a line. Each will be loaded into _x_c_o_n_q before the rest of the current mapfile. This process is recursive (at least in theory). Any conflicts are resolved by simple overwriting. Note that this presents the possibility of catastrophic con- flicts if the designer is not careful to, say, match units and periods. A file with a given name will be loaded only once; a second attempt will result in a warning message, and the program will continue on. The version section is quite simple, since it is one line; exactly the version string displayed when _x_c_o_n_q starts up. This is typically only needed for saved games, but might be convenient while _x_c_o_n_q versions are changing incompatibly. When this section is loaded, the version is merely compared with the internal version number, and _x_c_o_n_q fails if they do not match. The period section is a program in a simple postfix language, which when executed fills in the period descrip- tion. The map section includes the world dimensions and terrain. It may also include information about countries at some future date. The globals section includes any global values, such as the current turn, and also the win/lose conditions for a scenario. The sides section defines the sides in a game. Required info is little more than the name of the side, but a detailed section may also include the area of the map seen by that side, and other data. Finally, the units sections lists a number of units in the game. Again, detail can range from type, name, and position to complete details on its orders. Each of these sections is entirely optional - _x_c_o_n_q can September 10, 1993 - 3 - synthesize its own replacements for each. For instance, a mapfile could specify a map and two sides, or a period, or an entire game, by including the appropriate sections. The sections do interact somewhat, with dependencies as follows: Maps, win/lose conditions in globals, detailed sides, and units depend on period. Detailed and/or non-neutral units depend on sides. The following sections discuss each part of a mapfile in more detail. The version secton has already been covered sufficiently. Since the period defines what may appear in all the other sections, I shall begin with it. _P_E_R_I_O_D_S Historical periods are the most complicated way to customize xconq, and can be difficult to get right. There are many hundreds of numbers, each of which must be in balance with every other. At best, a mistake will result in a period whose winning strategies are quite simple; at worst, _x_c_o_n_q will hang or core dump. (_x_c_o_n_q will make some efforts to check the numbers.) Although most historical periods are defined in the period sections of mapfiles, one period is compiled into _x_c_o_n_q (usually a version of WW II, since it is most familiar). Compiling other periods (using the utility _p_e_r_2_c) is straightforward, and there is no problem with mak- ing unusual default periods for the program, but in prac- tice, periods do not take very long to read. The header of the period section has the form PPPPeeeerrrriiiioooodddd _e_x_t_e_n_s_i_o_n where _e_x_t_e_n_s_i_o_n is the currently-unused extension flag. The remainder of the description is in a postfix language similar to Forth or Postscript(tm), but even simpler. _x_c_o_n_q includes an interpreter for this language, and program exe- cution results in a filled-in period description. There is a compiler, called _p_e_r_2_c; it is used to produce a C version of the period definition which is then compiled into _x_c_o_n_q. The objects of this language are quite simple. There are only integers, strings, and vectors of integers. Integers and strings have direct representation as tokens, as do sym- bols, while integer vectors must be constructed using square brackets or one of the predefined vector-returning words. Tokens are always separated by whitespace, which means whi- tespace may _n_e_v_e_r be part of a token (backslash may be used for this purpose at some future date). Thus, the syntax for a token is fairly simple: September 10, 1993 - 4 - token -> [+-]*[0-9][0-9]*[%]* | "[~"]*" | [~"+-0-9].* In other words, numbers are digits optionally preceded by +/- and followed by %, while strings are anything enclosed in double quotes, and symbols are anything else that is not white space. A semicolon is the comment character; the characters from the semicolon to the end of the line are discarded. Numbers are limited to the typical range for signed shorts; -32768 to 32767. The percent sign % is just for readability (since many numbers are percentages), and its presence or omission has no effect on anything. Numbers and strings merely get pushed on the stack, while symbols are assumed to be defined words. The reader looks them up in the dictionary and executes the associated C function, if one is defined (otherwise, the symbol gets pushed). Nearly all words take a fixed number of arguments from the stack and push nothing, although there are some exceptions. The program is terminated by the word eeeennnndddd. Integer vectors are useful for filling in large parts of arrays. They are individual objects, built using the words [[[[ and ]]]]. Usage of these depends on the word, but typically words with two or more arguments may include two vectors among them. For instance, the line [[[[ 1111 1111 2222 8888 ]]]] [[[[ iiii aaaa bbbb BBBB ]]]] hhhhpppp sets the hit points for four types of units; 1111 for unit type iiii, 8888 for unit type BBBB, and so forth. The words below generally follow some extremely regular pat- terns. Most one-argument words define things for the entire period. Most two-argument words define attributes of units or resources, and may be thought of one-dimensional array operations, while three-argument words usually fill in two- dimensional arrays. In the two-argument and three-argument cases, the first argument (deepest in the stack) is the value, while second and third arguments are indices. At present, there are no words with four or more arguments. One-dimensional operations allow three cases of the four possibilities for vectors and scalars: scalar value and index(set), scalar value/vector index (fill), vector value and index (mapping). Two-dimensional operations offer six of the eight possible combinations (encoded here with S for scalar and V for vector, in the order value,index,index), disallowing only a vector value with either two scalar or two vector indices (VSS and VVV), since these combinations are not very meaningful. The six other combinations are SSS (element set), SVS and SSV (row fill), SVV (array fill), VVS and VSV (row mapping). All of these combinations are useful September 10, 1993 - 5 - - see existing periods for examples of their use. The following descriptions cover all the predefined words of the period language. Most words correspond to period attri- butes, and thus have an associated default value; when not explicitly mentioned, the default is 0000. For arguments of type _b_o_o_l, both 1111 and 0000 or ttttrrrruuuueeee and ffffaaaallllsssseeee are valid (an argument characterized as _b_o_o_l may still be a vector of 1s and 0s). Arguments of type _n, _n%, and _n._0_1% are all just integers. First, there are some useful words not specific to period definition. ttttrrrruuuueeee ffffaaaallllsssseeeePushes a 1111 and a 0000 on the stack, respectively. [[[[ Marks the beginning of a vector. The following objects must all evaluate to numbers only. ]]]] Marks the end of a vector. All numbers going back to the last [[[[ are popped and collected into a vector, which is pushed back on the stack. _v_a_l_u_e _n_a_m_e ddddeeeeffffiiiinnnneeeeDefine the string _n_a_m_e to be a word that pushes the object _v_a_l_u_e onto the stack. This is espe- cially useful for assigning names to vectors, for instance a vector of all cities or all ships. pppprrrriiiinnnnttttPrint the current contents of the stack onto standard output, surrounded by /* */. Very useful for debug- ging! The global period definition words. _s_t_r_i_n_g ppppeeeerrrriiiioooodddd----nnnnaaaammmmeeeeDefines the name of the period that will be displayed on startup. Defaults to """"uuuunnnnssssppppeeeecccciiiiffffiiiieeeedddd"""". _s_t_r_i_n_g ffffoooonnnntttt----nnnnaaaammmmeeeeDefines the name of the font that will be used. This is not needed if bitmaps are being used instead. Defaults to the name of the text font. See below for a discussion of bitmaps and fonts. _n ssssccccaaaalllleeeeSet the default scale of maps used with this period, in km. Defaults to 111100000000. (This value is unimportant, used only to compare with the map scale). The words to define new kinds of units, resources, and ter- rain all add new words that push the number of their unit, resource, or terrain type onto the stack. The numbering is in order; the first of each type will be numbered 0000. Most of the period definition words use these values as indices when filling up arrays of numbers. September 10, 1993 - 6 - _c_h_a_r _n_a_m_e _s_t_r_i_n_g uuuuttttyyyyppppeeeeDefine a type of unit. The arguments are unit character (a string of length one), full name, and a one-line help string. The unit may thereafter be referred to by either its character (as a one-char sym- bol) or by its name. Things will not work if a blank or any other special characters (such as plus and minus signs) are used as a unit character. Mixing terrain characters and unit characters is also a bad idea, since both may be used by a graphical display. At present, up to 30 or so unit types may be defined. _c_h_a_r _n_a_m_e _h_e_l_p rrrrttttyyyyppppeeeeDefine a type of resource, by both name and character, and supply a help string for it. The characters must be distinct from unit characters, oth- erwise this word is identical to uuuuttttyyyyppppeeee. _c_h_a_r _n_a_m_e _c_o_l_o_r ttttttttyyyyppppeeeeDefine a type of terrain. Unlike the other two definers, the terrain character does _n_o_t become a new word, although the name still does. The character should be defined in the basic _x_c_o_n_q font (the one named xxxxccccoooonnnnqqqq....oooonnnnxxxx, in the X10 interface), if the period is to be used with an interface that needs it (monochrome X only, at this writing). The color may be either approximate ("brown") or exact ("#334455"), but in any case, the interpretation is up to the interface. uuuu**** Push a vector of all unit types in order. rrrr**** Push a vector of all resource types in order. tttt**** Push a vector of all terrain types in order. nnnnooootttthhhhiiiinnnnggggPush the index of a non-unit onto the stack. This word cannot be used for unit attributes, but it is use- ful for certain attributes whose values are unit types (ffffiiiirrrrsssstttt----uuuunnnniiiitttt, ffffiiiirrrrsssstttt----pppprrrroooodddduuuucccctttt). Use of this as an index with any word that sets unit attributes is guaranteed to cause nasty coredumps... _s_t_r_i_n_g _u_n_i_t iiiiccccoooonnnn----nnnnaaaammmmeeeeSet the name of the icon for the given unit type. If undefined, then the unit's character will be used in whichever font is being used for unit icons (which may even be the text font - works but not too attractive). Definition of an icon overrides any character in any font. As with the terrain, the exact interpretation of this word is up to the graphics interface - for instance, the curses interface ignores both the ffffoooonnnntttt----nnnnaaaammmmeeee and iiiiccccoooonnnn----nnnnaaaammmmeeee words entirely. In X, the name is the name of a file in the usual bitmap for- mat, as produced by the _b_i_t_m_a_p program. The actual file name is produced by appending """"....bbbb"""" for X10 bitmaps and """"....bbbb11111111"""" for X11 bitmaps. The X11 interface will also look for X10 bitmap files. September 10, 1993 - 7 - _t_e_r_r_a_i_n ddddeeeeffffaaaauuuulllltttt----tttteeeerrrrrrrraaaaiiiinnnnSet the type of terrain to be substi- tuted while reading a map with incomprehensible terrain characters. Occasionally useful, if the set of terrain types is a subset of the standard set. Initialization characteristics of a period are used only during synthesis of maps, sides, and units, which happens when they are not supplied from a mapfile. Periods that are used only with complete scenarios need not use any of these words. _n% _t_e_r_r_a_i_n mmmmiiiinnnn----aaaallllttttSet the minimum percentile of terrain elevations that result in the given terrain type. Together with the other three words following, it is possible to subdivide all the possible altitudes and moisture levels into different kinds of terrain. For instance, desert in the standard period ranges from sea level (77770000 ddddeeeesssseeeerrrrtttt mmmmiiiinnnn----aaaalllltttt) to high elevations (99993333 ddddeeeesssseeeerrrrtttt mmmmaaaaxxxx----aaaalllltttt) but only in the lowest percentiles of moisture (0000 ddddeeeesssseeeerrrrtttt mmmmiiiinnnn----wwwweeeetttt, 22220000 ddddeeeesssseeeerrrrtttt mmmmaaaaxxxx----wwwweeeetttt). It is important that all percentiles be assigned to some terrain type, or the map generator will complain; when designing ter- rain combinations, it is helpful to make a graph with altitude percentiles 0-100 on one axis and moisture percentiles on the other. _n% _t_e_r_r_a_i_n mmmmaaaaxxxx----aaaallllttttAs for mmmmiiiinnnn----aaaalllltttt, but set the maximum alti- tude percentile. Defaults to 111100000000. _n% _t_e_r_r_a_i_n mmmmiiiinnnn----wwwweeeetttt _n% _t_e_r_r_a_i_n mmmmaaaaxxxx----wwwweeeettttSet the minimum and maximum percentiles of world moisture levels that result in the given terrain type. Deserts should range in the low percentiles (0- 20), while rain forests should be high (90-100). The minimum defaults to 0000, while the maximum is 111100000000. _n% aaaalllltttt----rrrroooouuuugggghhhhnnnneeeessssssssSet a rather mysterious number that controls whether a random map tends toward large continents or archipelagos of small islands. It must range between 0000 and 111100000000. Altitude roughness of 0000 will result in a map with one large continent, while 111100000000 produces dozens of tiny random islands, and drastic altitude variations from one hex to the next. Defaults to 88880000. _n% wwwweeeetttt----rrrroooouuuugggghhhhnnnneeeessssssssSet the "moisture roughness", which is like altitude roughness, but affects the distribution of wet and dry areas. Defaults to 77770000. _t_e_r_r_a_i_n eeeeddddggggeeee----tttteeeerrrrrrrraaaaiiiinnnnSet the type of terrain to fill in on the northern and southern edges of a map. Best user- friendliness is to have a type that is scarce else- where, so the edges are not mistaken for normal ter- rain. September 10, 1993 - 8 - _d_i_s_t_a_n_c_e ccccoooouuuunnnnttttrrrryyyy----ssssiiiizzzzeeeeSet the radius of a randomly-placed country, in hexes. The country is always hexagonal in shape, and the center hex is not counted in the radius. The radius should be sufficient to accommodate all the initial units, without crowding them. For radius r, the number of hexes is 3/4*(2r+1)**2. Keep in mind that terrain may reduce the number of available hexes even further. If one type of unit can occupy another, then they are free to be placed in the same hex. Defaults to 3333. _d_i_s_t_a_n_c_e ccccoooouuuunnnnttttrrrryyyy----mmmmiiiinnnn----ddddiiiissssttttaaaannnncccceeee _d_i_s_t_a_n_c_e ccccoooouuuunnnnttttrrrryyyy----mmmmaaaaxxxx----ddddiiiissssttttaaaannnncccceeeeSet the minimum and maximum distances of country centers from each other, in hexes. These values are sometimes tricky to set properly. If too small, countries will mostly overlap; if too large, then attempts to use small maps will fail; if too close to each other, placements can also fail. Default to 7777 and 66660000 hexes, respectively. _u_n_i_t ffffiiiirrrrsssstttt----uuuunnnniiiittttSet the type of unit that player will be started off in. Setting this to nnnnooootttthhhhiiiinnnngggg has the effect of giving every unit in the country to the player at the outset. Production will not be set automatically, so this is not recommended for novices, who tend to find large numbers of units confusing at the outset. Defaults to nnnnooootttthhhhiiiinnnngggg. _u_n_i_t ffffiiiirrrrsssstttt----pppprrrroooodddduuuuccccttttSet the type of unit that will be built automatically first. A "cheap" (quick to build) type is usually best, although interesting situations could result from, say, the automatic production of one atomic bomb at the outset (note that all sides start out in exactly the same way). Defaults to nnnnooootttthhhhiiiinnnngggg. _n _u_n_i_t iiiinnnn----ccccoooouuuunnnnttttrrrryyyySet the number of units of the given type in a player's country. These units are randomly scat- tered, with some bias towards the middle of the coun- try, and subject to terrain limitations via the ffffaaaavvvvoooorrrreeeedddd parameter (see below). _n _u_n_i_t ddddeeeennnnssssiiiittttyyyySet the total number of units appearing throughout the map, at the rate of one per ten thousand hexes. The numbers of units appearing in countries is subtracted first, so that the final density of units is independent of the number of players. If this value is nonzero, then at least one unit will appear on the map, even if the map is very small (i.e. the calculation of numbers rounds up not down). Units not assigned to countries to meet the quota set by iiiinnnn----ccccoooouuuunnnnttttrrrryyyy always become neutral. September 10, 1993 - 9 - _b_o_o_l _u_n_i_t nnnnaaaammmmeeeeddddSet a type of unit to get a random name dur- ing initialization. The names are usually the names of towns, so this flag should be used judiciously (A bat- tleship named "Wankers Corner" is only briefly amus- ing!). The value can also be set to 2222, in which case the unit name will be displayed by itself, without side name or unit type name. _n_a_m_e uuuunnnnaaaammmmeeeeDefine the string _n_a_m_e to be a plausible name for random assignment to an initial named unit. The name will be included with any previously defined, including possibly ones in the compiled-in period. This behavior, which is unlike any other period word except for ssssnnnnaaaammmmeeee, is intended to ensure that each period need not define its own list of names. cccclllleeeeaaaarrrr----uuuunnnniiiitttt----nnnnaaaammmmeeeessssReset the list of unit names. This is appropriate if the compiled-in list is completely wrong for the period. _n% _t_e_r_r_a_i_n _u_n_i_t ffffaaaavvvvoooorrrreeeeddddSet the probability of the unit being on the given type of terrain at the outset. The default of 0000 is an absolute prohibition against placing the unit on that type of terrain, thus every period must specify at least one non-zero value for some ter- rain type and some initial unit type. (Note that this does not preclude a unit type with no favored terrain, but it must be able to occupy some other unit already placed. In fact, this is a useful way to force one initial unit to start out inside another.) This parameter is tricky to use properly, and not very flexible. The problem is a widely differing favored terrains for initial units may be too constraining to work with the typical random map. For instance, very few small countries will include both ice and open sea, or deserts and forests and swamps. Failure to find such combinations will result in games exiting while still initializing, thus frustrating erstwhile players of the period. Best results will be had if the favored terrains are the same for all initial types of units, and the terrain types are common on random maps. (At present, the most-favored, or the lowest-numbered type among equally-favored terrains should be plentiful on the map; this is to get around a bug.) _n kkkknnnnoooowwwwnnnn----rrrraaaaddddiiiiuuuussssSet the area of the world known about, in those cases where the world is not already known. _n is measured in hexes, and represents a radius which will be seen around each of the starting units. _b_o_o_l _u_n_i_t aaaallllrrrreeeeaaaaddddyyyy----sssseeeeeeeennnnSet the type of unit that is or is not seen at the outset. This should usually be true of things like cities, independently of their aaaallllwwwwaaaayyyyssss----sssseeeeeeeennnn September 10, 1993 - 10 - setting. _n% _r_e_s_o_u_r_c_e _u_n_i_t ssssttttoooocccckkkkppppiiiilllleeeeSet the percentage of capacity for the given resource that each unit will start out with. Defaults to 111100000000. _n_a_m_e ssssnnnnaaaammmmeeeeDeclare the string _n_a_m_e to be a plausible name for random assignment to a side. The name will be added to the others already defined, including ones from the compiled-in period. cccclllleeeeaaaarrrr----ssssiiiiddddeeee----nnnnaaaammmmeeeessssReset the list of side names. This is appropriate if the compiled-in list is completely wrong for the period, but if used, you must supply at least as many side names as there are possible sides (7 or so). _n _t_e_r_r_a_i_n iiiinnnnhhhhaaaabbbbiiiittttaaaannnnttttssssSet the number of inhabitants in each hex of a country with the given type of terrain. The number is relative, and at present is only treated as a boolean value. _n _t_e_r_r_a_i_n iiiinnnnddddeeeeppppeeeennnnddddeeeennnncccceeeeSet the "independence" of the inhabi- tants in the given type of terrain; how they react to enemy units in terms in attrition, supply, etc. [NIY] The first phase in a turn is devoted to spying. This is the revealing of all or part of a side's unit positions to another randomly-selected side. It is controlled by only two parameters. _n% ssssppppyyyy----cccchhhhaaaannnncccceeeeSet the percentage chance of spying occurring on this turn. If the chance is low, then the player doing the spying will get a message, otherwise the display will be silently updated. The player spied upon is never informed. Defaults to 1111. _n% ssssppppyyyy----qqqquuuuaaaalllliiiittttyyyySet the percentage of enemy units that will be seen when spying is successful. Defaults to 55550000 (i.e. on the average about half of the side's units will be seen). The second phase in a turn determines any revolts or surrenders, attrition, and disasters. Since these are (usu- ally) rare events, the probabilities are set in one- hundredth percent increments. Revolts happen anywhere, while surrender happens only if enemy units are nearby. Attrition is the loss of single hit points, without actually destroying a unit, while disaster is the complete destruc- tion of the unit (both of these depend on terrain). Note that with 100 units in play, the lowest possible nonzero chance of 1 for a value still results in an occurence of that sort of disaster every 100 turns or so, so September 10, 1993 - 11 - these parameters require a "light touch". _n._0_1% _u_n_i_t rrrreeeevvvvoooollllttttSet the base chance for the unit to revolt spontaneously in that turn. This chance is reduced by better morale and maybe other things. _n._0_1% _u_n_i_t ssssuuuurrrrrrrreeeennnnddddeeeerrrrSet the base chance for surrender to some adjacent enemy unit. Each enemy unit present adds to the chance by this amount. _n._0_1% _u_n_i_t ssssiiiieeeeggggeeeeSet the additional chance for surrender when the unit is completely surrounded by enemy units. This is added to the basic surrender chance. _n._0_1% _t_e_r_r_a_i_n _u_n_i_t aaaattttttttrrrriiiittttiiiioooonnnnSet the chance of a unit losing a single hit point while in the given terrain. _n _u_n_i_t aaaattttttttrrrriiiittttiiiioooonnnn----ddddaaaammmmaaaaggggeeeeNumber of hit points lost when attri- tion happens. Defaults to 1111. Note that repair is in the following phase, and 1 hp of attrition damage might be repaired immediately, and appear not to have hap- pened. _s_t_r_i_n_g _u_n_i_t aaaattttttttrrrriiiittttiiiioooonnnn----mmmmeeeessssssssaaaaggggeeeeSet what to say when unit is hit by attrition. Defaults to """"ssssuuuuffffffffeeeerrrrssss aaaattttttttrrrriiiittttiiiioooonnnn"""". If the string is """""""", then the message will be suppressed entirely. _n._0_1% _t_e_r_r_a_i_n _u_n_i_t ddddiiiissssaaaasssstttteeeerrrrSet the chance of completely los- ing the unit while in the given terrain. Accidents should be restricted to definite hazardous situations, to go along with movement constraints - for instance, carriers in shallow water should move more slowly and have a nonzero accident rate. See random movement for another way to achieve similar effects. _s_t_r_i_n_g _u_n_i_t ddddiiiissssaaaasssstttteeeerrrr----mmmmeeeessssssssaaaaggggeeeeSet what to say when unit is lost in a disaster. Defaults to """"hhhhaaaassss mmmmeeeetttt wwwwiiiitttthhhh ddddiiiissssaaaassss---- tttteeeerrrr"""". The next phase of a turn handles creation of new units and repair of damaged units. Units can only be created by cer- tain other kinds of units, limited both by time and raw materials. Also there are startup and research times. _n _u_n_i_t_2 _u_n_i_t mmmmaaaakkkkeeeeSet the time in turns needed for a unit of type _u_n_i_t to build one unit of type _u_n_i_t_2, assuming sufficient resources to do so. _b_o_o_l _u_n_i_t mmmmaaaakkkkeeeerrrrSet the unit type to be a "maker". Makers always build unless explicitly idled, and may move while building. If a period starts with no movers, then it needs at least one maker in the country, who will prompt for a unit type at the beginning of a game. September 10, 1993 - 12 - _n% _u_n_i_t ssssttttaaaarrrrttttuuuuppppSet the extra time needed to build the first unit, if the maker was producing something else before. Startup time should be higher for high-tech or large units, for instance to represent tooling or production pipeline startup. _n% _u_n_i_t rrrreeeesssseeeeaaaarrrrcccchhhhSet the extra time needed for a side to build the very first unit of that type. This time is in addition to the startup time for the first unit. Long research time is a good way to keep a unit type out of play for awhile. _n _r_e_s_o_u_r_c_e _u_n_i_t ttttoooo----mmmmaaaakkkkeeeeSet the total amount of a resource type needed to build a unit. This amount is amortized over the normal construction schedule, which means that extra resources are consumed by startup or research times (representing mistakes and experiments). _n _u_n_i_t_2 _u_n_i_t rrrreeeeppppaaaaiiiirrrrSet the time needed for the unit type _u_n_i_t to repair one hit point of damage to unit type _u_n_i_t_2. One of the two units must be able to occupy the other; It is also legitimate for a unit to repair itself. Resources used to build units are also used at the same rate to accomplish repairs. The supply phase of a turn handles both the production of resources and their distribution via supply lines. Resource production involves a three-dimensional array indexing unit type, resource type, and terrain type, but supply lines are measured only by length and resource type. Supply lines are always interrupted by enemy presence. _n _r_e_s_o_u_r_c_e _u_n_i_t pppprrrroooodddduuuucccceeeeSet the basic amount of each resource produced by each unit in one turn. _n _t_e_r_r_a_i_n _u_n_i_t pppprrrroooodddduuuuccccttttiiiivvvviiiittttyyyySet the percentage productivity of a unit on a type of terrain. This is multiplied with the basic production rate to get actual produc- tion, so productivity of 0000 completely disables produc- tion on that terrain type, and productivity of 111100000000 is yields the maximum rate specified by pppprrrroooodddduuuucccceeee. _n _r_e_s_o_u_r_c_e _u_n_i_t ssssttttoooorrrraaaaggggeeeeSet the unit's capacity to carry each sort of resource. Amount carried does not affect unit's performance. When the value is 0000, displays for that type of unit will not mention this resource type at all. _n _r_e_s_o_u_r_c_e _u_n_i_t ccccoooonnnnssssuuuummmmeeeeSet the amount of resources consumed by the unit in a turn, even if it doesn't move or do anything else. This includes riding as a passenger. This only comes into play if the unit has used less than its base consumption while moving. In other words, the total supply usage for one unit in one turn September 10, 1993 - 13 - is max(#moves * to-move, consume). If the unit runs out of a resource that it must consume, it dies due to starvation. _n _r_e_s_o_u_r_c_e _u_n_i_t iiiinnnn----lllleeeennnnggggtttthhhh _n _r_e_s_o_u_r_c_e _u_n_i_t oooouuuutttt----lllleeeennnnggggtttthhhhThese two are used together to determine the length (in hexes) of supply lines between units. The given type of resource can only be transferred from unit type A to unit type B if the dis- tance is less than the minimum of the in-length of B and the out-length of A. For instance, the in-length for a fighter's fuel might be 3 hexes, while the out- length of fuel from a city is 4 hexes. If the fighter's out-length is 0, then it will be constantly supplied with fuel when within 3 hexes of a city, but will never transfer any fuel to the city unless it actually lands there. An in- or out-length of 0000 means that the two units must be in the same hex, while a negative length disables the automatic transfer com- pletely. Long out-length lines should be used spar- ingly, since the algorithm uses the out-length to define the radius of search for units to be resupplied. Supply lines are not affected by terrain at present. _n% _u_n_i_t ssssuuuurrrrvvvviiiivvvvaaaallllChance that a unit type can survive on no supplies. The test is made once per turn. _s_t_r_i_n_g _u_n_i_t ssssttttaaaarrrrvvvveeee----mmmmeeeessssssssaaaaggggeeeeSet what to say when unit has no more of some supply to consume. Defaults to """"rrrruuuunnnnssss oooouuuutttt ooooffff ssssuuuupppppppplllliiiieeeessss aaaannnndddd ddddiiiieeeessss"""". The movement phase is the main part of a turn in _x_c_o_n_q, and the only part involving interaction with players. All com- bat happens during the movement phase. _n _u_n_i_t ssssppppeeeeeeeeddddSet the maximum theoretical speed of a unit, in hexes/turn. If the unit cannot move on any sort of terrain, it will never be prompted about - thus every period should define at least one type of moving unit. _n _t_e_r_r_a_i_n _u_n_i_t mmmmoooovvvveeeessssSet extra moves used up on each type of terrain. 0000 indicates no decrease from theoretical max, 2222 indicates a move into that type of terrain uses up 3 moves instead of 1, and ----1111 indicates that movement on that type of terrain is not possible. Defaults to ----1111. _n._0_1% _t_e_r_r_a_i_n _u_n_i_t rrrraaaannnnddddoooommmm----mmmmoooovvvveeeeSet the randomness of movement of a unit on the terrain. This is different from disaster and attrition, since it is not always fatal, and happens only during attempts to move. However, collisions with other units or with impassable terrain, due to random moves, are always fatal. September 10, 1993 - 14 - _b_o_o_l _u_n_i_t ffffrrrreeeeeeee----mmmmoooovvvveeeeSet whether the unit can move even if there is insufficient movement allowance remaining in this turn. Defaults to ttttrrrruuuueeee. (Most board wargames make this false - if you don't have enough movement points to meet the entry requirement for a hex, that's too bad.) Can be useful to make "double movement phases", if attack time is equal to movement allowance; a unit can only attack units that it is adjacent to at the start of the movement phase. _b_o_o_l _u_n_i_t oooonnnneeee----mmmmoooovvvveeeeSet whether the unit can make exactly one move before dying (appropriate for rockets and other automatic equipment). [NIY] _b_o_o_l _u_n_i_t jjjjuuuummmmpppp----mmmmoooovvvveeeeSet whether a unit can jump over another unit to get somewhere. [NIY] _n _r_e_s_o_u_r_c_e _u_n_i_t ttttoooo----mmmmoooovvvveeeeSet the amount of resource used by a unit to move one hex. The amount taken is independent of the terrain in the hex. If the unit is out of any movement resource, it is immobilized until it gets more. Transportation-related parameters. Capacity is measured both by number and volume of occupants. For instance, if you wanted a transport to carry up to 8 infantry and/or armor, but no more than 4 armor units, then capacity for infantry should be 8 and capacity for armor 4, the volumes for each should be 1, while the transport hold-volume should be 8. _n _u_n_i_t_2 _u_n_i_t ccccaaaappppaaaacccciiiittttyyyySet the basic carrying capability of a transport type _u_n_i_t for its occupants of type _u_n_i_t_2. _n _u_n_i_t hhhhoooolllldddd----vvvvoooolllluuuummmmeeeeSet the volume capacity of a transport. Volume measure is quite arbitrary, and is used only for comparison. The default value of 0000 implies infinite capacity, volume-wise. _n _u_n_i_t vvvvoooolllluuuummmmeeeeSet the volume of a unit. The volume of a unit may be smaller than its hold-volume, the code will not care about this. _n _u_n_i_t_2 _u_n_i_t eeeennnntttteeeerrrr----ttttiiiimmmmeeeeNumber of moves needed to enter a transport. This is a time measure; extra supplies are not used up. _n _u_n_i_t_2 _u_n_i_t lllleeeeaaaavvvveeee----ttttiiiimmmmeeeeNumber of moves needed to leave a transport; similar to eeeennnntttteeeerrrr----ttttiiiimmmmeeee. _n% _u_n_i_t_2 _u_n_i_t aaaalllltttteeeerrrr----mmmmoooobbbbiiiilllliiiittttyyyySet the effect of an occupant on the transport's speed as a ratio of the transport's usual speed. Defaults to 111100000000; smaller values slow the transport, and 0000 prevents it from moving entirely. To September 10, 1993 - 15 - simplify the code, only the effect of one (randomly chosen) type of occupant has this effect. If a tran- sport has two types of occupants each of which alter its speed differently, the resulting transport speed will be unpredictable. The total slowdown is multi- plied by the number of occupants of all types. Seeing is an important part of _x_c_o_n_q, and needs parameters to accommodate submarines, radar installations, and Indians hiding in the woods. The visibility of a unit and the intensity of viewing are computed separately, and compared to get the final decision on seeing something. This doesn't allow for much differential between two types of units view- ing a third, but that's life. For units seeing things at a distance, the chances are interpolated linearly, from the best conditions (adjacent hex) to worst (maximum range). _b_o_o_l aaaallllllll----sssseeeeeeeennnnIf true, then all sides see all of each other's units. If secrecy unneeded (as in a board game), this will speed up the display process somewhat. _n% _u_n_i_t sssseeeeeeee----bbbbeeeessssttttSet the basic chance of one unit seeing any other, under best possible conditions. Defaults to 111100000000. _n _u_n_i_t sssseeeeeeee----rrrraaaannnnggggeeeeSet the maximum distance in hexes at which the unit can see anything. Defaults to 1111 (adjacent hexes only). _n% _u_n_i_t sssseeeeeeee----wwwwoooorrrrssssttttSet the chance of seeing a unit at the max- imum range. Defaults to 111100000000. _n _u_n_i_t vvvviiiissssiiiibbbbiiiilllliiiittttyyyySet the basic chance of a unit to be seen. Crippled unit is more visible, in proportion to hp loss. Defaults to 111100000000. _n% _t_e_r_r_a_i_n _u_n_i_t ccccoooonnnncccceeeeaaaallllSet the percent effect of terrain on seeing the unit. This is subtracted from the basic chance, since it is a "concealment factor". _b_o_o_l _u_n_i_t aaaallllwwwwaaaayyyyssss----sssseeeeeeeennnnDeclare the unit to be of a type that is always seen and up-to-date. This applies only to units whose underlying hexes have been seen. This is useful for units like towns, which are unlikely to disappear secretly. Combat is part of movement, and has its own large set of parameters. The basic plan of combat is for attackers and defenders to hit each other, then attackers to attempt to capture. Success of a hit attempt depends on a number of attributes, including chances, terrain, and the availability of the correct sort of ammo. September 10, 1993 - 16 - _b_o_o_l _u_n_i_t mmmmuuuullllttttiiii----ppppaaaarrrrttttSet a unit to be treated as an aggregate of smaller identical units. Affects various things. [NIY] _n _u_n_i_t hhhhppppSet the maximum number of hit points for each part of a unit. Defaults to 1111, may never be set any lower. _n _u_n_i_t ccccrrrriiiipppppppplllleeeeddddSet the hit point level below which the unit is considered to be crippled. Below this level, repair and construction ceases, supply production is reduced, maximum speed starts to decrease, and the bridging capability is disabled. _n% _u_n_i_t_2 _u_n_i_t hhhhiiiittttBase chance of a single attack by the type _u_n_i_t hitting the defender _u_n_i_t_2, assuming the resources are available. If chance to hit is 0000, attacker cannot attack or defend itself. _n% _t_e_r_r_a_i_n _u_n_i_t ddddeeeeffffeeeennnnsssseeeeSet the decreased chance of hitting if the defending type _u_n_i_t is in that terrain type. Percentage is subtracted from base chance. _n% nnnneeeeuuuuttttrrrraaaalllliiiittttyyyySet the change in defense for neutral units. This is subtracted from chances to hit and capture, but the _n% can be negative, which would make it harder to hit/capture. _n _u_n_i_t_2 _u_n_i_t ddddaaaammmmaaaaggggeeeeNumber of hit points that the defender _u_n_i_t_2 loses when hit by its attacker _u_n_i_t. _n nnnnuuuukkkkeeee----hhhhiiiittttMinimum damage for a hit to qualify as a nuclear blast and be displayed appropriately. Default value is 55550000. _b_o_o_l _u_n_i_t sssseeeellllffff----ddddeeeessssttttrrrruuuuccccttttDeclare that unit self-destructs when it attacks. This eliminates some weird messages and hit chances. _b_o_o_l ccccoooouuuunnnntttteeeerrrraaaattttttttaaaacccckkkkWhen true, combat is two-way; the initia- tor of an attack is also hit by a counterattack. Oth- erwise, the defender must wait to get its revenge. Defaults to ttttrrrruuuueeee. _b_o_o_l _u_n_i_t ccccaaaannnn----ccccoooouuuunnnntttteeeerrrrLike ccccoooouuuunnnntttteeeerrrraaaattttttttaaaacccckkkk, but applies only to particular unit types being attacked. Defaults to ttttrrrruuuueeee. _n% _u_n_i_t_2 _u_n_i_t ccccaaaappppttttuuuurrrreeeeSet the base chance of the type _u_n_i_t capturing the defender type _u_n_i_t_2. This is conditional on both attacker and defender surviving initial hits, and is modified by morale and quality of both sides. September 10, 1993 - 17 - _b_o_o_l _u_n_i_t_2 _u_n_i_t bbbbrrrriiiiddddggggeeeeTrue if the unit type _u_n_i_t_2 can be captured by another unit _u_n_i_t, even across impassable terrain. _n% _u_n_i_t cccchhhhaaaannnnggggeeeessss----ssssiiiiddddeeeeSet chance that the given unit will change sides if captured. This is appropriate for units that are primarily hardware or otherwise indif- ferent to their fate. Units that are captured and do not change sides become prisoners (prisoners are not implemented yet). _n _u_n_i_t_2 _u_n_i_t gggguuuuaaaarrrrddddSet the number of unit hit points required to garrison or guard a captured type _u_n_i_t_2, whether or not the captured unit has changed sides (at present, it always does). The hit point loss is permanent. _n% _u_n_i_t rrrreeeettttrrrreeeeaaaattttSet the base chance that a unit will retreat rather than be hit. This choice depends on ability to move into an adjacent hex and on morale, quality, and fatigue. _n _r_e_s_o_u_r_c_e _u_n_i_t hhhhiiiittttssss----wwwwiiiitttthhhhSet the amounts of each resource used as ammo by the unit. _n _r_e_s_o_u_r_c_e _u_n_i_t hhhhiiiitttt----bbbbyyyySet the amounts of each resource necessary to score a hit on the unit. This is corre- lated with the previous parameter to decide if right sort of ammo is available for an attack. _n _u_n_i_t_2 _u_n_i_t pppprrrrooootttteeeeccccttttSet the level of protection that _u_n_i_t offers to _u_n_i_t_2. Transports protect their occupants by only letting a percentage of hits get through. Occu- pants protect their transports by reducing the chance of a hit and increasing chance of a counterattack. (The default of 0000 implies terrible carnage if a full transport is hit.) _n _u_n_i_t ccccoooommmmbbbbaaaatttt----ttttiiiimmmmeeeeSet the extra number of moves used by an attack. _s_t_r_i_n_g _u_n_i_t ddddeeeessssttttrrrrooooyyyy----mmmmeeeessssssssaaaaggggeeeeSet what to say when a unit is killed in combat, as an active verb for what the des- troying unit has done to its victim. Defaults to """"ddddeeeessss---- ttttrrrrooooyyyyssss"""". General characteristics are not really classifiable anywhere else. _n _u_n_i_t tttteeeerrrrrrrriiiittttoooorrrryyyySet the territorial value of a unit. Pri- marily used by machine players and win/lose conditions. _n _u_n_i_t mmmmaaaaxxxx----qqqquuuuaaaalllliiiittttyyyySet the maximum quality achievable by a unit. September 10, 1993 - 18 - _n% _u_n_i_t vvvveeeetttteeeerrrraaaannnnSet the effect of one point of quality on hit and capture chances. _n _u_n_i_t mmmmaaaaxxxx----mmmmoooorrrraaaalllleeeeSet the maximum morale to which a unit can rise. _n% _u_n_i_t ccccoooonnnnttttrrrroooollllSet the chance of a unit obeying its orders. Defaults to 111100000000. When the unit does not obey orders, it makes a decision using the machine players' algo- rithm. _b_o_o_l _u_n_i_t ccccaaaannnn----ddddiiiissssbbbbaaaannnnddddSet whether a 'D' disband command can be used to get rid of a unit. It should not be possi- ble to disband a city, for instance, to eliminate it as a strategic target. Note that the default of 0000 effec- tively disables the disbanding command entirely. _n% eeeeffffffffiiiicccciiiieeeennnnccccyyyyUnits disbanded in a transport can have the resources used to build them reclaimed - this parameter sets the percentage that is actually obtained. _b_o_o_l _u_n_i_t nnnneeeeuuuuttttrrrraaaallllSet to ttttrrrruuuueeee if unit can exist as a neutral. If ffffaaaallllsssseeee, then anything that would cause the unit to become neutral (revolt, surrender of owner) has the effect of removing it instead. Defaults to ffffaaaallllsssseeee. Miscellaneous words. _n hhhhoooossssttttiiiilllliiiittttyyyySet the level of hostility exhibited by a popula- tion toward a unit from some other side. [NIY] bbbbeeeeggggiiiinnnn{{{{nnnnooootttteeeessss}}}}Declare the beginning of the designer's notes. This word kicks in a special reader that absorbs all lines until it sees the line "eeeennnndddd{{{{nnnnooootttteeeessss}}}}". The inter- vening lines are saved as period notes and listed out in """"ppppaaaarrrrmmmmssss....xxxxccccoooonnnnqqqq"""". The notes should rationalize the design and discuss features of special interest to the player. eeeennnndddd Marks the end of the period description. Nearly all the elementary programming errors are checked, such as stack over/underflow, and as many of the period parameters as possible will be checked, although there is plenty of room for subtle loopholes. You should think care- fully about the consequences of each parameter, being par- ticularly sensitive to degenerate winning strategies. Most common are units that are too powerful, or that are built so quickly that they overwhelm any opposition. The players should always be a little "hungry"; not able to get quite as much of units or resources as they would really like. Although there are many interesting possibilities inherent in this period description language, you should avoid making September 10, 1993 - 19 - the period too complex to be humanly playable. The compiled form of the period description can involve over 16,000 indi- vidually settable numbers, each with an expected range of perhaps 100 distinct values. It is clearly possible to spend many years exploring a single set of these numbers. For more playable and enjoyable games, either pick a single aspect to treat in detail, or else do all aspects in a sim- plified way. Aspects could include exploration, logistics, naval operations, "shoot-em-up", renditions of familiar board games or even some team sports (rugby for instance). Another thing to keep in mind is that the introduction of a new type may have far-reaching consequences - a new unit type will need its interactions with _a_l_l other unit types defined. One approach is to introduce a new type as a slight modification of an existing type, then to share most of the definitions. Something else to keep in mind is that the period parameters have been chosen for their ability to combine in interesting ways, rather than for obvious usefulness. For example, past startup, the production rate for units is constant and unending. But suppose you want to put a limit on the numbers of that type of unit? One way is to define a resource that is essential for construction of that type, let the builder have an initial supply, but provide no way to get more of that resource. When it runs out, no more units! Another trick is to motivate an activity by making it a prerequisite to the basic builtin goal of defeating the other player. The age of discovery worked this way. The kings of that time weren't interested in new lands per se; they wanted exploitable possessions that could be used to get gold to buy armies big enough to defeat their neighbors. The period language could describe this situation almost exactly, by making gold a resource obtainable only by the capture of neutral mines thinly scattered over the map. Be inventive! Studying the predefined periods should reveal a number of tricks. Completely new periods usually have a number of bugs. The tools are rather limited, but then most of the bugs are fairly obvious. The pppprrrriiiinnnntttt word is useful for examining the stack, and a number of errors (such as stack overflow/underflow) have messages. Finding out where the problem occurred requires the use of the _x_c_o_n_q debugging flag ----DDDD, which has the effect of listing out each period token as it is read. This can also be used with the period compiler, which starts up faster; invoke it as """"ppppeeeerrrr2222cccc ----DDDD <<<<nnnneeeewwwwppppeeeerrrriiiioooodddd....ppppeeeerrrr"""". The most serious problems with periods are play balance issues. Some can be found out by watching a machine player, since its decisions are based on perceived values of the units. The most subtle bugs can only be uncovered by extensive play interspersed with judicious alteration of parameters. I find it useful to play for a while, then go over all the period parameters, thus avoiding September 10, 1993 - 20 - tweaking one parameter only to find that it results in another being inconsistent. Parameters interact in many ways - you should keep this in mind when experimenting. _M_A_P_S Maps alone are the easiest thing to customize. You can either do ordinary text editing to acquire the map data, then add the headers, or use the online terrain editing capability of _x_c_o_n_q and save the terrain alone. The map header has the form MMMMaaaapppp _w_i_d_t_h _h_e_i_g_h_t _s_c_a_l_e _s_e_e_n _e_x_t_e_n_s_i_o_n where _w_i_d_t_h and _h_e_i_g_h_t are the size of the map, while the _s_c_a_l_e is the width of a single hex in km (measured between parallel faces). The _s_e_e_n flag is 0000 if the map is not known to the players, and 1111 if it is (this is like using """"----vvvv"""" on the command line). The _e_x_t_e_n_s_i_o_n is an extension flag, with a value of 0000 for the normal map. Other values are reserved for extensions. The preferred way to build a map is to use the """"----BBBB"""" option of _x_c_o_n_q. This enables the space bar to "paint" terrain onto the map. The "brush" is defined by using the terrain characters as commands (they will override any normal com- mands on the same letters). The argument is also useful - if positive, it is the radius of the area to be painted with the given terrain type, if negative, it is the length of a horizontal bar. Thus, in the standard period, the sequence """"999999999999.... """" will convert all but the largest maps into open sea. To save the map by itself, answer with the string "m" when "saving the game" (described in more detail below). The other way to build is by using a text editor and follow- ing the format exactly. The terrain data is a number of long lines of characters. The length of the lines must be exactly the width of the map. The characters for terrain types are defined by the period. The coordinate system is Cartesian oblique, with the y axis tilted to form a 60- degree angle with the x axis. Thus, landforms in the map- file should appear to be leaning to the left, if they are to appear upright during play. Maps should have some distinguishing terrain on the northern and southern edges; also, remember that the default map shape wraps around in the east-west direction, so landforms should match up. If the wraparound is undesirable, a verti- cal stripe of some otherwise-unused type (such as outer space) is useful to block movement. Run-length encoding is also available. It is flagged by a numeric digit, followed by any number of digits, followed by September 10, 1993 - 21 - a terrain character. The terrain character will be repli- cated the number of times specified by the digit string. The encoding may be freely intermixed with normal terrain, but cannot extend over line boundaries. _G_L_O_B_A_L_S Globals include a number of values affecting an entire game. The header is in the following form: GGGGlllloooobbbbaaaallllssss _g_a_m_e_t_i_m_e _e_n_d_t_i_m_e _s_e_t_p_r_o_d_u_c_t _l_e_a_v_e_m_a_p _n_u_m_c_o_n_d_s _e_x_t_e_n_s_i_o_n where _g_a_m_e_t_i_m_e is the elapsed turns, _e_n_d_t_i_m_e is the last turn of the game, _s_e_t_p_r_o_d_u_c_t controls whether unit construc- tion is changeable, _l_e_a_v_e_m_a_p allows units to leave by the map edges, and _e_x_t_e_n_s_i_o_n is reserved for extensions (is nor- mally 0000). _n_u_m_c_o_n_d_s specifies the number of winning/losing conditions. Conditions are evaluated at the end of each turn (along with other ways to lose, such as losing all of one's units). A win condition results in the side achieving it winning while all others lose. A losing condition knocks the side out of the game, and the other sides continue normally. Multiple win and lose conditions act as disjunctions - when one is satisfied, something will happen. There is a limit of about 10 conditions or so. All conditions include a starting and ending time for when they are in effect, as well as the number of a side to which it applies, or ----1111 it is to be applied to all sides equally. The first line of a condition is the same for all types: _w_i_n/_l_o_s_e _t_y_p_e _s_t_a_r_t _e_n_d _s_i_d_e(_s) where _w_i_n/_l_o_s_e is 1111 if the condition is for winning and 0000 for losing, _s_t_a_r_t and _e_n_d are the starting and ending turns for testing the condition, _s_i_d_e(_s) is the number of a side to which the condition applies (or ----1111 if it applies to any side), and _t_y_p_e is the type of condition: 0000 Territory; next line is one number, the amount of ter- ritory (above if to win, below if to lose). 1111 Number of units; next line is list of numbers, one for each unit type. To win, must possess at least that many of each type. To lose, must be at or below that many for _a_l_l unit types simultaneously (the default losing condition is this one, with all zeros). To make this condition apply to only one unit type, set all the other numbers to very low (for win condition) or very high (for lose condition) values, outside the range normally occurring during a game. September 10, 1993 - 22 - 2222 Quantity of resources; next line is a list of numbers, one for each resource type. Winning and losing is same as for unit types. 3333 Possession; next line is three numbers, the first two representing the coordinates of a hex, and the third the number of a unit type (or ----1111 to indicate all unit types). To win, must have a unit of the specified type on the hex. To lose, do not have a unit on that hex. Each condition has a sort of dual identity, since it is interpreted slightly differently, depending on whether it is flagged for winning or losing. The logic is a little twisted perhaps - special conditions should have all cases tested carefully before a scenario is released. _S_I_D_E_S Sides need relatively little information stored about them, particularly for a scenario. The header is simple: SSSSiiiiddddeeeessss _n_u_m_s_i_d_e_s _d_e_t_a_i_l _e_x_t_e_n_s_i_o_n where _n_u_m_s_i_d_e_s is the number of sides recorded, and _d_e_t_a_i_l is the level of detail that was recorded. The side's name can be set using the naming or CCCCall command, when the cursor is not over a unit, or if an argument is supplied (this will be the number of a side, and can be used in build mode to change the names of other sides). The exact contents of each level of detail are as follows: 1111 Name of side only is saved. This is sufficient for many scenarios. 2222 Name, attributes, and political status and production counts (used for numbering unnamed units) saved. 3333 All of above, plus view of explored part of world. 4444 All of above, plus hosts and player types, plus statis- tics if used. 9999 All possible data. This is the level used for saved games. (At the moment, this is equivalent to level 4, but may include more data in the future.) The data for each level begins on a new line, and some lev- els need several lines (such as the view data). The best way to study the layout is to examine a saved game. September 10, 1993 - 23 - _U_N_I_T_S Units have quite a few attributes, nearly all of which must be saved. The header is as simple as for sides: UUUUnnnniiiittttssss _n_u_m_u_n_i_t_s _d_e_t_a_i_l _e_x_t_e_n_s_i_o_n where _n_u_m_u_n_i_t_s is the number of units saved, _d_e_t_a_i_l is the level of detail that was recorded, and of course _e_x_t_e_n_s_i_o_n is the usual extension with only a value of 0000. There are several levels of detail: 1111 Type, name, and position, and side. The re-created units will be fully supplied and awake. Neutral units have a side of -1. Units capable of construction will be idled, so there should be at least one movable unit present. 2222 All of above, plus scalar attributes and supply amounts, all on one line. (Look at a saved game or the source code to interpret the numbers.) 3333 All of above, plus orders and standing orders if defined. 9999 All possible data. This is the level used for saved games. (Same as level 3 at present.) Build mode offers a number of way to manipulate units on any side, as described in the next section. _S_C_E_N_A_R_I_O_S The ----BBBB command line option starts up _x_c_o_n_q in _b_u_i_l_d _m_o_d_e, where many additional actions are possible, all oriented towards the editing of game state. All commands can be per- formed on any side's units, and none of the machine players will move (this can be toggled by using the quit command 'Q', then saying 'n' to the confirmation question). Build mode allows some other acts: Move any unit anywhere instantly, using the moveto com- mand 'm'. Create any unit anywhere, using '\' (prompts for unit type, argument specifies side, defaults to neutral). Modify terrain anywhere, as described under the map section. See all units everywhere, using 'V' September 10, 1993 - 24 - Do anything to any unit as if it were your own, using the usual commands. Once all desired changes have been made, you may wish to allow machine players to move a little, just to randomize things a bit. Then use the normal game save command. In build mode, you will be asked to enter a string indicating sections and levels of detail. The string should contain a character for each section you want written out - 'g' for globals, 'u' for units, and so forth. The letters 'u' and 's' must each be followed by a digit indicating the level of detail desired, as described earlier. The default string is """"mmmmssss1111uuuu1111"""", which will write a mapfile with the map, side names, and unit types/names/positions/sides, which is suffi- cient for many interesting scenarios. The file that will be written is always called """"rrrraaaannnnddddoooommmm....ssssccccnnnn"""", is written into the current directory, and should be renamed as desired. After sufficient playtesting, it may be added to the scenario menu, just by adding its name to the file """"mmmmaaaappppffffiiiilllleeeessss"""" in the library directory. Scenario construction is not for everybody. Since the processes are semi-internal, the error-checking is not as extensive. For instance, you can load a submarine with bat- tleships as passengers. There are also more subtle ques- tions of balance, which are usually revealed by repeated play of the scenario. As a rule, the lower levels of detail are safer to use - level 1 details for sides and units are often simple enough to be typed in or edited by hand. _E_X_A_M_P_L_E_S A period description with only infantry and cities: September 10, 1993 - 25 - Xconq 0 -+---- Very simple test period Period 0 "generic" period-name "standard" font "i" "infantry" "moves around" utype "@" "city" "makes infantry units" utype "+" "land" "green" ttype ; must always have at least one terrain type 1 @ in-country 100 land @ favored @ first-unit i first-product 1 i @ make true @ maker 1 i @ capacity ; makers need to be able to hold or be held by products 1 i speed 0 t* i moves begin{notes} This is just a test. Kids, don't try this at home! end{notes} end A tiny map with two cities, including an "empire" period description to ensure meaningful city definitions: Xconq 1 --+--+ Tiny map; just an example... empire.per Map 9 5 100 1 0 :........ :.+++++.. :..+^^^.. :...+~~.. :........ Units 2 1 0 @ New Cork 2,3 -1 @ Old York 4,1 -1 September 10, 1993 - 26 - _L_O_S_S_A_G_E_S Several words are marked NIY, meaning that although they can be used, the code does not actually take them into account. September 10, 1993