games@tekred.TEK.COM (06/29/88)
Submitted by: "Stanley T. Shebs" <shebs%defun@cs.utah.edu>
Comp.sources.games: Volume 4, Issue 89
Archive-name: xconq5/Part01
[I have compiled and played this under X10 on a Sun-3/60 and it
works as advertised. The following note is from the author. -br]
[[This is considerably expanded from the first release last year, and there
have been some major changes - it uses hexes rather than squares, there is
a postfix language for defining historical periods, and there are interfaces
for X10, X11, and curses. You heard that right; the curses version is
not very pretty, and only allows for one human player, but it *is* usable!
There are a lot of smaller improvements as well.]]
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 1 (of 18)."
# Contents: README MANIFEST lib lib/standard.onx.u period.ms
# Wrapped by billr@saab on Wed Jun 29 08:55:28 1988
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f README -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"README\"
else
echo shar: Extracting \"README\" \(5916 characters\)
sed "s/^X//" >README <<'END_OF_README'
XThis is the source directory for XCONQ, a multi-player strategy game.
XThe code herein includes interfaces for curses, X V10R4, and X V11R2.
X
X(Note to sites with earlier release - this release is INCOMPATIBLE.
XIf you wish to have both, name one or the other differently!)
X
X1. Look at config.h and edit as desired. The most important item is
Xthe system you're using. There are also some noncritical options, which
Xneed be changed only for special needs. Config.h does *not* specify whether
Xcurses or X will be used - that is decided at link time.
X
X2. Edit the makefile's definitions for library and other directories,
Xas appropriate for local customs.
X
X3. Select the versions that you want to build by editing the VERSIONS macro
Xin the makefile. "cconq" is curses only (should work on almost anything),
X"xconq" and "x11conq" are X10 and X11 programs, respectively. Check the
Xmakefile to make sure that the correct libraries are being linked. Also,
Xsome systems may have the X include files in strange places - if compilation
Xfails, check the interface file source code (X10.c, and so forth).
X
X4. Do "make all" to build the versions selected.
X
X5. Do extra things needed by some of the versions:
X
X5a. The curses version needs no special setup.
X
X5b. X10 fonts *.onx are binary and need to be uudecoded; do "make X10fonts".
XDecide what to do about the fonts. If your X can load from an absolute
Xpathname, then make sure they're in the xconq library directory. They can
Xalso live in the default X font directory - xconq will always look in both
Xplaces for a font. Finally, it may be possible to use the X defaults to
Xspecify a path somewhere - look at the file "Xdefaults" for an example.
XIn any case, the fonts must be present on the *server* machine, since the
XX library just passes the fonts' pathnames on to the server. xconq will
Xstill function without these fonts, but the display is almost impossible
Xto comprehend.
X
X5c. X11 fonts *.bdf are text and need to be compiled; do "make X11fonts",
Xwhich will produce fonts *.snf. These can be handled much as for the X10
Xfonts - put in library directory, standard X font directory, or someplace
Xmentioned in your .Xdefaults.
X
X6. If you set things to run in the current dir, just say "cconq" or "xconq"
X(or whatever) and play. If you want the executables in standard places,
Xuse "make install" (this action may need modification, depending on which
Xinterfaces are in use). There is also a "make rinstall" for remote
Xinstallation, which may be desirable in some workstation environments;
Xstudy the makefile for more details.
X
X7. The man pages just tell how to start up the programs; xconq.doc has
Xcomplete details on every aspect of play. A lot of behavior can be figured
Xout by experimentation and by using the extensive online help ('?' should
Xalways provide something).
X
X8. 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.
X
X9. If you get bored with the standard game, look at "custom.doc", which
Xtells how to build your own historical periods, maps, and scenarios.
XMany have already been defined; all are in the library directory.
X
XIf you have any maps created by version 1.0, they can be converted to
Xan approximate equivalent using the program "hexify". This program is
Xnot made by default; "make hexify" should create it. Hexify takes an old
Xmap on standard input and writes a new one to standard output. The new
Xmap is somewhat different, and may need some hand-editing.
X
XThe program has been tested on HP9000/300 running HP-UX and BSD, Suns, and
XVaxen running BSD 4.3 and Ultrix, and probably other systems as well.
XMoving to other graphics environments should not be too difficult, since
Xall the user interface goes through about 50 abstract functions. (Suntools,
XMacintosh, and Atari ST would be good candidates.) Non-Un*x should be
Xstraightforward also, since there are only a handful of Un*x system calls,
Xand none of those are absolutely required. Please contact me about any
Xportability problems.
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 shebs@utah-cs.uucp
X
X
XVERSION 5 CHANGES
X
XThis version is quite different from version 1 (versions 2-4 were interim
Xonly, never released). Best approach is to treat this as a new program,
Xand not assume that things will be the same as previously. I can only list
Xthe most sweeping changes here:
X
X* merger of units and cities into one kind of object.
X* maps based on hexes instead of squares.
X* new types of orders for patrolling and following.
X* smarter machine players.
X* postfix interpreter for period descriptions.
X* many more parameters in a period.
X* period-definable terrain types.
X* generalized and flexible map file format.
X* online editing of maps and scenarios.
X* rearranged display, including a status window for units.
X* survey mode for players while another player is moving.
X* "chess clock" for timing games.
X* interactive game setup.
X* better attempts to handle unusual X implementations.
X* interfaces for X10, X11, and curses.
X
XThere are a host of smaller changes as well, for instance input of unit
Xtype (as for production) is case-sensitive now. Many commands have been
Xassigned to different characters, or have different (hopefully more logical)
Xbehavior.
X
XAlso, I want to thank the many XCONQ players around the net who have sent
Xin literally hundreds of suggestions, fixes, and improvements. The manual
Xincludes more detailed acknowledgments.
END_OF_README
if test 5916 -ne `wc -c <README`; then
echo shar: \"README\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f MANIFEST -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"MANIFEST\"
else
echo shar: Extracting \"MANIFEST\" \(5334 characters\)
sed "s/^X//" >MANIFEST <<'END_OF_MANIFEST'
X File Name Archive # Description
X-----------------------------------------------------------
X MANIFEST 1 This shipping list
X Makefile 16
X README 1
X ToDo 17
X X10.c 9
X X11.c 2
X Xdefaults 17
X attack.c 13
X cconq.6 15
X config.h 15
X curses.c 14
X custom.ms 10
X dir.h 14
X do.c 5
X draw.c 3
X ginit.c 15
X global.h 17
X help.c 12
X hexify.c 17
X init.c 2
X input.c 7
X lib 1
X lib/1800.map 17
X lib/1942.scn 4
X lib/1987.map 9
X lib/1e.b 18
X lib/2planets.map 12
X lib/45.b 18
X lib/4e.b 18
X lib/README 11
X lib/airbase.b 18
X lib/ap.b 18
X lib/archer.b 18
X lib/armor.b 18
X lib/auto.b 18
X lib/balloon.b 18
X lib/bb.b 18
X lib/beirut.map 17
X lib/beirut.per 17
X lib/beirut.scn 17
X lib/beirut2.scn 14
X lib/bireme.b 18
X lib/bomb.b 18
X lib/brig.b 18
X lib/builder.b 18
X lib/ca.b 18
X lib/camp.b 18
X lib/cannon.b 18
X lib/catapult.b 18
X lib/cavalry.b 18
X lib/city18.b 18
X lib/city20.b 18
X lib/city22.b 18
X lib/city30.b 10
X lib/conquist.per 8
X lib/crater.map 17
X lib/crater2.map 17
X lib/crown.b 18
X lib/cv.b 18
X lib/dd.b 18
X lib/deathray.b 17
X lib/deathstar.b 17
X lib/delta.b 18
X lib/earth1.map 10
X lib/earth2.map 16
X lib/eastmed.map 16
X lib/elephant.b 18
X lib/empire.per 17
X lib/europe.map 12
X lib/europe42.scn 15
X lib/flag.b 18
X lib/flattop.map 18
X lib/flattop.per 16
X lib/fortress.b 17
X lib/four.map 3
X lib/fred.map 17
X lib/fred.per 16
X lib/frigate.b 18
X lib/future.per 15
X lib/globe.map 17
X lib/greece.map 16
X lib/greek.per 16
X lib/hard.map 17
X lib/harder.map 17
X lib/hill.per 17
X lib/hill.scn 17
X lib/hoplite.b 18
X lib/hovcraft.b 17
X lib/icbm.b 18
X lib/icos.map 17
X lib/impcruisr.b 17
X lib/infantry.b 18
X lib/jets.b 18
X lib/man.b 18
X lib/mapfiles 13
X lib/maze.map 17
X lib/mormon.per 17
X lib/mothrship.b 18
X lib/napoleon.per 16
X lib/oldeur.map 16
X lib/paccity.map 5
X lib/pacific.map 16
X lib/parthenon.b 18
X lib/pby.b 18
X lib/pelops.scn 16
X lib/peltast.b 18
X lib/person.b 18
X lib/pyramid.b 18
X lib/relief.per 17
X lib/ringworld.map 17
X lib/rocket.b 18
X lib/rome.map 16
X lib/saucer.b 18
X lib/saucerpad.b 18
X lib/sea.map 18
X lib/simplest.per 17
X lib/soldiers.b 18
X lib/standard.bdf 4
X lib/standard.onx.u 1
X lib/standard.per 11
X lib/starwars.per 16
X lib/step.map 18
X lib/steppes.map 18
X lib/sub.b 18
X lib/t1.map 17
X lib/t2.map 17
X lib/t3.map 17
X lib/t6.map 17
X lib/t8.map 17
X lib/tank.b 18
X lib/three.map 17
X lib/tiefightr.b 18
X lib/torpbombr.b 17
X lib/town20.b 18
X lib/town22.b 18
X lib/trireme.b 18
X lib/trooper.b 15
X lib/two.map 17
X lib/twodecker.b 18
X lib/utah.map 16
X lib/v2.b 18
X lib/walker.b 18
X lib/walltown.b 18
X lib/xconq.bdf 7
X lib/xconq.news 6
X lib/xconq.onx.u 14
X lib/xwing.b 18
X lib/ywing.b 18
X map.c 8
X map.h 7
X misc.h 17
X mkmap.c 13
X move.c 6
X mplay.c 3
X order.c 12
X output.c 12
X per2c.c 14
X period.c 4
X period.h 13
X period.ms 1
X phases.c 9
X side.c 13
X side.h 14
X standard.c 6
X unit.c 5
X unit.h 15
X util.c 15
X uudfont.sh 18
X uuefont.sh 18
X version.h 18
X xconq.6 15
X xconq.c 8
X xconq.ms 10
X xconq2.ms 11
END_OF_MANIFEST
if test 5334 -ne `wc -c <MANIFEST`; then
echo shar: \"MANIFEST\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test ! -d lib ; then
echo shar: Creating directory \"lib\"
mkdir lib
fi
if test -f lib/standard.onx.u -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"lib/standard.onx.u\"
else
echo shar: Extracting \"lib/standard.onx.u\" \(5969 characters\)
sed "s/^X//" >lib/standard.onx.u <<'END_OF_lib/standard.onx.u'
Xbegin 644 standard.onx
XM&````.`'$``!````?0#8#P``"P`"`!``__\`````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM````````__\`````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM```````````````3``````````````````````````````````````````#`
XM`0```````@``````````````````````````````````````````````````
XM`````````````````````````````$``````````````````````````````
XM`````````````````````````````````````````````\``````````````
XM````````````````````````````````````````````````````````````
XM```````````````````````````````````````````````````+````````
XM``````````````````````````````````!.`0`````@````````````````
XM````````````````````````````````````````````````````````````
XM`````&``````````````````(```````````````````````````````````
XM`````````````````````\``````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM```````````````````````````'````````````````````````````````
XM``````````#*`0`````$````````````````````````````````````````
XM`````````````````````````````````````````'````````````8`````
XM%````````````````````````````````````````````````````````\``
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM```#``````````````````````````````````````````!.!P``0``@````
XM````````````````````````````````````````````````````````````
XM`````````````````&``````````^`,`````#@$`````````````````````
XM`````````````````````````````````\``````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````"``````````````'````````````````````
XM``````````````````````#*!0``0@(`````````````````````````````
XM`#```````````````````````````````````````````````````'!`````
XM````_@<`````K@``````````````````````````````````````````````
XM`````````\``````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM"````````````(`&``````````````````````````````````````````!.
XM#P``;"/``0``````````````````````````^"L`````````````````````
XM``````````````````````````#``V!@````````X```````?@@`````````
XM`````````````````&`&`````````````````````````\``````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````"````````````$`&````````
XM``````````````````````````````````#*:P``^!___P``````````````
XM````````````_#\`````````````````````````````````````````````
XM``#_#_Y_``"@````````````=`4```````````````````````!@`/`/````
XM`````````````````````\``````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````''P``````````"`&````````````````````````````````
XM``````````!^;P``___^?P``````````````````````````_#\`````````
XM``````````````````````````````````````#@?_Y_``#P`P```&``````
XM]$,```````````````````````!@`/P_`````````````````````````\``
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````U%<`````````
XM`#X&``````````````````````````````````````````#J?0``_G\`````
XM````````````````````````^"L`````````````````````````````````
XM``````````````#^/V!@``#X'P```#@`````H"L`````````````````````
XM``#\/_@?`````````````````````````\``````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````7'T``````````.@/````````````````````
XM``````````````````````!^7P``````````````````````````````````
XM`#````````````````````````````````````````````````#\'W!`````
XM````\#\`````H!\`````````````````````````````````````````````
XM`````````\``````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XMW%<```````````0\``````````````````````````````````````````"J
XM=0``````````````````````````````````````````````````````````
XM`````````````````````````````&``````````_'\``````!T`````````
XM`````````````````````````````````````````````\``````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````_O\````````````,````````
XM``````````````````````````````````#__P``````````````````````
XM````````````````````````````````````````````````````````````
XM`````'``````````@`<``````!T`````````````````````````````````
XM`````````````````````\``````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM```````````````````````````,````````````````````````````````
XM````````````````````````````````````````````````````````````
XM`````````````````````````````````````````&````````````X`````
XM``@`````````````````````````````````````````````````````__\`
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM```,````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM`````````````````$````````````````````@`````````````````````
XM````````````````````````````````__\`````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM````````````````````````````````````````````````````````````
XM```````````0`"``,`!``%``8`!P`(``D`"@`+``P`#0`.``\````1`!(`$P
XM`4`!4`%@`7`!@`&0`:`!L`'``=`!X`'P`0`"$`(@`C`"0`)0`F`"<`*``I`"
XMH`*P`L`"T`+@`O`"``,0`R`#,`-``U`#8`-P`X`#D`.@`[`#P`/0`^`#\`,`
XM!!`$(`0P!$`$4`1@!'`$@`20!*`$L`3`!-`$X`3P!``%$`4@!3`%0`50!6`%
XM<`6`!9`%H`6P!<`%T`7@!?`%``80!B`&,`9`!E`&8`9P!H`&D`:@!K`&P`;0
XC!N`&\`8`!Q`'(`<P!T`'4`=@!W`'@`>0!Z`'L`?`!]`'X`<&
X`
Xend
END_OF_lib/standard.onx.u
if test 5969 -ne `wc -c <lib/standard.onx.u`; then
echo shar: \"lib/standard.onx.u\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f period.ms -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"period.ms\"
else
echo shar: Extracting \"period.ms\" \(40667 characters\)
sed "s/^X//" >period.ms <<'END_OF_period.ms'
X.SH
XPERIODS
X.LP
XHistorical periods are the most complicated way to customize xconq,
Xand can be difficult to get right.
XThere are many hundreds of numbers,
Xeach of which must be in balance with every other. At best, a mistake will
Xresult in a period whose winning strategies are quite simple; at worst,
X\fIxconq\fP will hang or core dump.
X(\fIxconq\fP will make some efforts to check the numbers.)
XAlthough most historical periods are defined
Xin the period sections of mapfiles,
Xone period is compiled into \fIxconq\fP
X(usually a version of WW II, since it is most familiar).
XCompiling other periods (using the utility \fIper2c\fP) is straightforward,
Xand there is no problem with making unusual default periods for the
Xprogram, but in practice, periods do not take very long to read.
X.LP
XThe header of the period section has the form
X.IP
X\fBPeriod \fIextension\fR
X.LP
Xwhere \fIextension\fP is the currently-unused extension flag.
X.LP
XThe remainder of the description is in a postfix language similar
Xto Forth or Postscript(tm), but even simpler.
X\fIxconq\fP includes an interpreter
Xfor this language, and program execution results in a filled-in period
Xdescription. There is a compiler, called \fIper2c\fP; it is used
Xto produce a C version of the period definition which is then
Xcompiled into \fIxconq\fP.
X.LP
XThe objects of this language are quite simple. There are only integers,
Xstrings, and vectors of integers. Integers and strings have direct
Xrepresentation as tokens, as do symbols, while integer vectors must be
Xconstructed using square brackets or one of the predefined vector-returning
Xwords. Tokens are always separated by whitespace, which means whitespace
Xmay \fInever\fP be part of a token (backslash may be used for this purpose
Xat some future date).
XThus, the syntax for a token is fairly simple:
X.IP
Xtoken -> [+-]*[0-9][0-9]*[%]* | "[~"]*" | [~"+\-0-9].*
X.LP
XIn other words,
Xnumbers are digits optionally preceded by +/- and followed by %,
Xwhile strings are anything enclosed in double quotes, and symbols are
Xanything else that is not white space. A semicolon is the comment character;
Xthe characters from the semicolon to the end of the line are discarded.
XNumbers are limited to the typical range for signed shorts; -32768 to 32767.
XThe percent sign % is just for readability (since many numbers are
Xpercentages), and its presence or omission has no effect on anything.
X.LP
XNumbers and strings merely get pushed on the stack, while symbols are
Xassumed to be defined words. The reader looks them up in the dictionary
Xand executes the associated C function, if one is defined (otherwise, the
Xsymbol gets pushed). Nearly all words take a fixed number of arguments
Xfrom the stack and push nothing, although there are some exceptions.
XThe program is terminated by the word \fBend\fP.
X.LP
XInteger vectors are useful for filling in large parts of arrays.
XThey are individual objects, built using the words \fB[\fP and \fB]\fP.
X.LP
XUsage of these depends on the word, but typically words with two or more
Xarguments may include two vectors among them. For instance, the line
X.IP
X\fB [ 1 1 2 8 ] [ i a b B ] hp \fP
X.LP
Xsets the hit points for four types of units;
X\fB1\fP for unit type \fBi\fP, \fB8\fP for unit type \fBB\fP, and so forth.
X.LP
XThe words below generally follow some extremely regular patterns.
XMost one-argument words define things for the entire period.
XMost two-argument words define attributes of units or resources, and
Xmay be thought of one-dimensional array operations, while three-argument
Xwords usually fill in two-dimensional arrays.
XIn the two-argument and
Xthree-argument cases, the first argument (deepest in the stack) is the
Xvalue, while second and third arguments are indices.
XAt present, there are no words with four or more arguments.
X.LP
XOne-dimensional operations allow three cases of the four possibilities for
Xvectors and scalars: scalar value and index(set),
Xscalar value/vector index (fill), vector value and index (mapping).
XTwo-dimensional operations offer six of the eight possible combinations
X(encoded here with S for scalar and V for vector,
Xin the order value,index,index),
Xdisallowing only a vector value with either two scalar or two vector
Xindices (VSS and VVV), since these combinations are not very meaningful.
XThe six other combinations are SSS (element set), SVS and SSV (row fill),
XSVV (array fill), VVS and VSV (row mapping). All of these combinations
Xare useful - see existing periods for examples of their use.
X.LP
XThe following descriptions cover all the predefined words of the period
Xlanguage. Most words correspond to period attributes, and
Xthus have an associated default value; when not explicitly mentioned, the
Xdefault is \fB0\fP.
XFor arguments of type \fIbool\fP, both \fB1\fP and \fB0\fP or \fBtrue\fP
Xand \fBfalse\fP are valid (an argument characterized as \fIbool\fP may
Xstill be a vector of 1s and 0s). Arguments of type \fIn\fP, \fIn%\fP,
Xand \fIn.01%\fP are all just integers.
X.LP
XFirst, there are some useful words not specific to period
Xdefinition.
X.IP \fBtrue\fR 5
X.IP \fBfalse\fR 5
XPushes a \fB1\fP and a \fB0\fP on the stack, respectively.
X.IP \fB[\fR 5
XMarks the beginning of a vector. The following objects must all evaluate
Xto numbers only.
X.IP \fB]\fR 5
XMarks the end of a vector. All numbers going back to the last \fB[\fP
Xare popped and collected into a vector, which is pushed back on the stack.
X.IP \fIvalue\ name\ \fBdefine\fR 5
XDefine the string \fIname\fP to be a word
Xthat pushes the object \fIvalue\fP onto the
Xstack. This is especially useful for assigning names to vectors, for
Xinstance a vector of all cities or all ships.
X.IP \fBprint\fP 5
XPrint the current contents of the stack onto standard output, surrounded
Xby /* */. Very useful for debugging!
X.LP
XThe global period definition words.
X.IP \fIstring\ \fBperiod-name\fR 5
XDefines the name of the period that will be displayed on startup.
XDefaults to \fB"unspecified"\fP.
X.IP \fIstring\ \fBfont-name\fR 5
XDefines the name of the font that will be used. This is not needed
Xif bitmaps are being used instead. Defaults to the name of the text font.
XSee below for a discussion of bitmaps and fonts.
X.IP \fIn\ \fBscale\fR 5
XSet the default scale of maps used with this period, in km.
XDefaults to \fB100\fP.
X(This value is unimportant, used only to compare with the map scale).
X.LP
XThe words to define new kinds of units, resources, and terrain all add
Xnew words that push the number of their unit,
Xresource, or terrain type onto the stack. The numbering is in order;
Xthe first of each type will be numbered \fB0\fP. Most of the period
Xdefinition words use these values as indices when filling up arrays
Xof numbers.
X.IP \fIchar\ name\ string\ \fButype\fR 5
XDefine a type of unit.
XThe arguments are unit character (a string of length one),
Xfull name, and a
Xone-line help string. The unit may thereafter be referred to by either
Xits character (as a one-char symbol) or by its name.
XThings will not work if a blank or any other special characters (such as plus
Xand minus signs) are used as a unit character. Mixing terrain characters
Xand unit characters is also a bad idea, since both may be used by a
Xgraphical display.
XAt present, up to 30 or so unit types may be defined.
X.IP \fIchar\ name\ help\ \fBrtype\fR 5
XDefine a type of resource, by both name and character, and supply a help
Xstring for it. The characters must be distinct from unit characters,
Xotherwise this word is identical to \fButype\fP.
X.IP \fIchar\ name\ color\ \fBrtype\fR 5
XDefine a type of terrain. Unlike the other two definers, the terrain
Xcharacter does \fInot\fP become a new word, although the name still does.
XThe character should be defined in the basic \fIxconq\fP font (the one named
X\fBxconq.onx\fP, in the X10 interface), if the
Xperiod is to be used with an interface that needs it (monochrome X only,
Xat this writing). The color may be either approximate ("brown") or exact
X("#334455"), but in any case, the interpretation is up to the interface.
X.IP \fBu*\fR 5
XPush a vector of all unit types in order.
X.IP \fBr*\fR 5
XPush a vector of all resource types in order.
X.IP \fBt*\fR 5
XPush a vector of all terrain types in order.
X.IP \fBnothing\fR 5
XPush the index of a non-unit onto the stack. This word cannot be used for
Xunit attributes, but it is useful for certain attributes whose values are
Xunit types (\fBfirst-unit\fP, \fBfirst-product\fP).
XUse of this as an index with any word that sets unit attributes is
Xguaranteed to cause nasty coredumps...
X.IP \fIstring\ unit\ \fBicon-name\fR 5
XSet the name of the icon for the given unit type. If undefined, then
Xthe unit's character will be used in whichever font is being used for
Xunit icons (which may even be the text font - works but not too attractive).
XDefinition of an icon overrides any character in any font.
XAs with the terrain, the exact interpretation of this word is up to
Xthe graphics interface - for instance, the curses interface ignores
Xboth the \fBfont-name\fP and \fBicon-name\fP words entirely.
XIn X, the name is the name of a file in the usual bitmap format, as
Xproduced by the \fIbitmap\fP program. The actual file name is produced
Xby appending \fB".b"\fP for X10 bitmaps and \fB".b11"\fP
Xfor X11 bitmaps. The X11 interface will also look for X10 bitmap files.
X.IP \fIterrain\ \fBdefault-terrain\fR 5
XSet the type of terrain to be substituted while reading a map
Xwith incomprehensible terrain characters. Occasionally useful,
Xif the set of terrain types is a subset of the standard set.
X.LP
XInitialization characteristics of a period are used only during synthesis
Xof maps, sides, and units,
Xwhich happens when they are not supplied from a mapfile.
XPeriods that are used only with complete scenarios
Xneed not use any of these words.
X.IP \fIn%\ terrain\ \fBmin-alt\fR 5
XSet the minimum percentile of terrain elevations that result in the given
Xterrain type. Together with the other three words following, it is possible
Xto subdivide all the possible altitudes and moisture levels into different
Xkinds of terrain. For instance, desert in the standard period ranges from
Xsea level (\fB70 desert min-alt\fP)
Xto high elevations (\fB93 desert max-alt\fP) but only
Xin the lowest percentiles of moisture (\fB0 desert min-wet\fP,
X\fB20 desert max-wet\fP). It is important that all percentiles be assigned
Xto some terrain type, or the map generator will complain; when designing
Xterrain combinations, it is helpful to make a graph with altitude percentiles
X0-100 on one axis and moisture percentiles on the other.
X.IP \fIn%\ terrain\ \fBmax-alt\fR 5
XAs for \fBmin-alt\fP, but set the maximum altitude percentile.
XDefaults to \fB100\fP.
X.IP \fIn%\ terrain\ \fBmin-wet\fR 5
X.IP \fIn%\ terrain\ \fBmax-wet\fR 5
XSet the minimum and maximum percentiles
Xof world moisture levels that result in the given
Xterrain type. Deserts should range in the low percentiles (0-20), while
Xrain forests should be high (90-100).
XThe minimum defaults to \fB0\fP, while the maximum is \fB100\fP.
X.IP \fIn%\ \fBalt-roughness\fR 5
XSet a rather mysterious number that controls whether a random map tends
Xtoward large continents or archipelagos of small islands. It must range
Xbetween \fB0\fP and \fB100\fP. Altitude roughness of \fB0\fP will result
Xin a map with one large continent, while \fB100\fP produces dozens of tiny
Xrandom islands, and drastic altitude variations from one hex to the next.
XDefaults to \fB80\fP.
X.IP \fIn%\ \fBwet-roughness\fR 5
XSet the "moisture roughness", which is like altitude roughness, but affects
Xthe distribution of wet and dry areas. Defaults to \fB70\fP.
X.IP \fIterrain\ \fBedge-terrain\fR 5
XSet the type of terrain to fill in on the northern and southern edges of
Xa map. Best user-friendliness is to have a type that is scarce elsewhere,
Xso the edges are not mistaken for normal terrain.
X.IP \fIdistance\ \fBcountry-size\fR 5
XSet the radius of a randomly-placed country, in hexes.
XThe country is always hexagonal in shape, and the center hex is not counted
Xin the radius. The radius should be sufficient to accommodate all the
Xinitial units, without crowding them. For radius r, the number of hexes
Xis 3/4*(2r+1)**2. Keep in mind that terrain may reduce
Xthe number of available hexes even further.
XIf one type of unit can occupy another, then they are free to be placed in
Xthe same hex.
XDefaults to \fB3\fP.
X.IP \fIdistance\ \fBcountry-min-distance\fR 5
X.IP \fIdistance\ \fBcountry-max-distance\fR 5
XSet the minimum and maximum
Xdistances of country centers from each other, in hexes.
XThese values are sometimes tricky to set properly.
XIf too small, countries will mostly overlap;
Xif too large, then attempts to use
Xsmall maps will fail; if too close to each other, placements can also fail.
XDefault to \fB7\fP and \fB60\fP hexes, respectively.
X.IP \fIunit\ \fBfirst-unit\fR 5
XSet the type of unit that player will be started off in.
XSetting this to \fBnothing\fP has the effect of giving every unit in
Xthe country to the player at the outset. Production will not be
Xset automatically, so this is not recommended for novices, who tend
Xto find large numbers of units confusing at the outset.
XDefaults to \fBnothing\fP.
X.IP \fIunit\ \fBfirst-product\fR 5
XSet the type of unit that will be built automatically first.
XA "cheap" (quick to build) type is usually best,
Xalthough interesting situations could result from, say, the
Xautomatic production of one atomic bomb at the outset (note that all sides
Xstart out in exactly the same way).
XDefaults to \fBnothing\fP.
X.IP \fIn\ unit\ \fBin-country\fR 5
XSet the number of units of the given type in a player's country. These
Xunits are randomly scattered, with some bias towards the middle of the
Xcountry, and subject to terrain limitations via the \fBfavored\fP parameter
X(see below).
X.IP \fIn\ unit\ \fBdensity\fR 5
XSet the total number of units appearing throughout the map, at the rate
Xof one per ten thousand hexes. The numbers of units appearing in countries
Xis subtracted first,
Xso that the final density of units is independent of the
Xnumber of players. If this value is nonzero, then at least one unit will
Xappear on the map, even if the map is very small (i.e. the calculation of
Xnumbers rounds up not down). Units not assigned to countries to meet
Xthe quota set by \fBin-country\fP always become neutral.
X.IP \fIbool\ unit\ \fBnamed\fR 5
XSet the type of unit to get a random name during initialization. The
Xnames are usually the names of towns,
Xso this flag should be used judiciously
X(A battleship named "Wankers Corner" is only briefly amusing!).
X.IP \fIname\ \fBuname\fR 5
XDefine the string \fIname\fP to be a plausible name for random assignment
Xto an initial named unit. The name will be included with any previously
Xdefined, including possibly ones in the compiled-in period.
XThis behavior, which is unlike any other period word except for \fBsname\fP,
Xis intended to ensure that each period need not define its own list of
Xnames.
X.IP \fBclear-unit-names\fR 5
XReset the list of unit names. This is appropriate if the compiled-in list
Xis completely wrong for the period.
X.IP \fIn%\ terrain\ unit\ \fBfavored\fR 5
XSet the probability of the unit being on the given type of terrain at the
Xoutset. The default of \fB0\fP is an absolute prohibition against placing
Xthe unit on that type of terrain, thus every period must specify at least
Xone non-zero value for some terrain type and some initial unit type.
X(Note that this does not preclude a unit type with no favored terrain,
Xbut it must be able to occupy some other unit already placed. In fact,
Xthis is a useful way to force one initial unit to start out inside another.)
X.IP
XThis parameter is tricky to use properly, and not very flexible. The problem
Xis a widely differing favored terrains for initial units may be too
Xconstraining to work with the typical random map. For instance, very few
Xsmall countries will include both ice and open sea, or deserts and forests
Xand swamps. Failure to find such combinations will result in games exiting
Xwhile still initializing, thus frustrating erstwhile players of the period.
XBest results will be had if the favored terrains are the same for all initial
Xtypes of units, and the terrain types are common on random maps.
X(At present, the most-favored, or the lowest-numbered type among
Xequally-favored terrains should be plentiful on the map;
Xthis is to get around a bug.)
X.IP \fIn\ \fBknown-radius\fR 5
XSet the area of the world known about, in those cases where the world is not
Xalready known. \fIn\fP is measured in hexes,
Xand represents a radius which will be seen around each of the starting units.
X.IP \fIbool\ unit\ \fBalready-seen\fR 5
XSet the type of unit that is or is not seen at the outset.
XThis should usually be true of things like cities, independently of their
X\fBalways-seen\fP setting.
X.IP \fIn%\ resource\ unit\ \fBstockpile\fR 5
XSet the percentage of capacity for the given resource that each unit will
Xstart out with. Defaults to \fB100\fP.
X.IP \fIname\ \fBsname\fR 5
XDeclare the string \fIname\fP to be a plausible name for random assignment
Xto a side. The name will be added to the others already defined, including
Xones from the compiled-in period.
X.IP \fBclear-side-names\fR 5
XReset the list of side names. This is appropriate if the compiled-in list
Xis completely wrong for the period, but if used, you must supply at least
Xas many side names as there are possible sides (7 or so).
X.IP \fIn\ terrain\ \fBinhabitants\fR
XSet the number of inhabitants in each hex of a country with the given type
Xof terrain. The number is relative, and at present is only treated as a
Xboolean value.
X.IP \fIn\ terrain\ \fBindependence\fR
XSet the "independence" of the inhabitants in the given type of terrain;
Xhow they react to enemy units in terms in attrition, supply, etc. [NIY]
X.LP
XThe first phase in a turn is devoted to spying. This is the revealing of
Xall or part of a side's unit positions to another randomly-selected side.
XIt is controlled by only two parameters.
X.IP \fIn%\ \fBspy-chance\fR 5
XSet the percentage chance of spying occurring on this turn. If the chance
Xis low, then the player doing the spying will get a message, otherwise the
Xdisplay will be silently updated. The player spied upon is never informed.
XDefaults to \fB1\fP.
X.IP \fIn%\ \fBspy-quality\fR 5
XSet the percentage of enemy units that will be seen when spying is
Xsuccessful. Defaults to \fB50\fP (i.e. on the average about half of the
Xside's units will be seen).
X.LP
XThe second phase in a turn determines any revolts or surrenders, attrition,
Xand disasters. Since these are (usually) rare events, the probabilities
Xare set in one-hundredth percent increments. Revolts happen anywhere, while
Xsurrender happens only if enemy units are nearby. Attrition is the loss
Xof single hit points, without actually destroying a unit, while disaster
Xis the complete destruction of the unit (both of these depend on terrain).
X.LP
XNote that
Xwith 100 units in play, the lowest possible nonzero chance of 1 for a value
Xstill results in an occurence of that sort of
Xdisaster every 100 turns or so, so these parameters require a "light touch".
X.IP \fIn.01%\ unit\ \fBrevolt\fR 5
XSet the base chance for the unit to revolt spontaneously in that turn.
XThis chance is reduced by better morale and maybe other things.
X.IP \fIn.01%\ unit\ \fBsurrender\fR 5
XSet the base chance for surrender to some adjacent enemy unit.
XEach enemy unit present adds to the chance by this amount.
X.IP \fIn.01%\ unit\ \fBsiege\fR 5
XSet the additional chance for surrender when the unit is completely
Xsurrounded by enemy units. This is added to the basic surrender chance.
X.IP \fIn.01%\ terrain\ unit\ \fBattrition\fR 5
XSet the chance of a unit losing a single hit point while in the given
Xterrain.
X.IP \fIn\ unit\ \fBattrition-damage\fR 5
XNumber of hit points lost when attrition happens. Defaults to \fB1\fP.
XNote that repair is in the following phase, and 1 hp of attrition damage
Xmight be repaired immediately, and appear not to have happened.
X.IP \fIstring\ unit\ \fBattrition-message\fR 5
XSet what to say when unit is hit by attrition.
XDefaults to \fB"suffers attrition"\fP.
X.IP \fIn.01%\ terrain\ unit\ \fBdisaster\fR 5
XSet the chance of completely losing the unit while in the given terrain.
XAccidents should be restricted to definite hazardous situations, to go along
Xwith movement constraints - for instance, carriers in shallow water should
Xmove more slowly and have a nonzero accident rate.
XSee random movement for another way to achieve similar effects.
X.IP \fIstring\ unit\ \fBdisaster-message\fR 5
XSet what to say when unit is lost in a disaster.
XDefaults to \fB"has met with disaster"\fP.
X.LP
XThe next phase of a turn handles creation of new units and repair of damaged
Xunits.
XUnits can only be created by certain other
Xkinds of units, limited both by time and raw materials. Also there are
Xstartup and research times.
X.IP \fIn\ unit2\ unit\ \fBmake\fR 5
XSet the time in turns needed for a unit of type \fIunit\fP
Xto build one unit of type \fIunit2\fP,
Xassuming sufficient resources to do so.
X.IP \fIbool\ unit\ \fBmaker\fR 5
XSet the unit type to be a "maker". Makers always build unless
Xexplicitly idled, and may move while building. If a period starts with
Xno movers, then it needs at least one maker in the country, who will prompt
Xfor a unit type at the beginning of a game.
X.IP \fIn%\ unit\ \fBstartup\fR 5
XSet the extra time needed to build the first unit, if the maker was
Xproducing something else before. Startup time should be higher for
Xhigh-tech or large units, for instance to represent tooling or production
Xpipeline startup.
X.IP \fIn%\ unit\ \fBresearch\fR 5
XSet the extra time needed for a side to build the very first unit of
Xthat type. This time is in addition to the startup time for the first unit.
XLong research time is a good way to keep a unit type out of play for awhile.
X.IP \fIn\ resource\ unit\ \fBto-make\fR 5
XSet the total amount of a resource type needed to build a unit.
XThis amount is [should be] amortized over the total construction schedule.
X.IP \fIn\ unit2\ unit\ \fBrepair\fR 5
XSet the time needed for the unit type \fIunit\fP
Xto repair one hit point of damage to unit type \fIunit2\fP.
XOne of the two units must be able to occupy the other;
XIt is also legitimate for a unit to repair itself.
XResources used to build units are also used
Xat the same rate to accomplish repairs.
X.LP
XThe supply phase of a turn handles both the production of resources and
Xtheir distribution via supply lines. Resource production involves a
Xthree-dimensional array indexing unit type, resource type, and terrain
Xtype, but supply lines are measured only by length and resource type.
XSupply lines are always interrupted by enemy presence.
X.IP \fIn\ resource\ unit\ \fBproduce\fR 5
XSet the basic amount of each resource produced by each unit in one turn.
X.IP \fIn\ terrain\ unit\ \fBproductivity\fR 5
XSet the percentage productivity of a unit on a type of terrain.
XThis is multiplied with the basic production rate to get actual
Xproduction, so productivity of \fB0\fP completely disables production on
Xthat terrain type, and productivity of \fB100\fP is yields the maximum rate
Xspecified by \fBproduce\fP.
X.IP \fIn\ resource\ unit\ \fBstorage\fR 5
XSet the unit's capacity to carry each sort of resource.
XAmount carried does not affect unit's performance.
XWhen the value is \fB0\fP, displays for that type of unit will not mention
Xthis resource type at all.
X.IP \fIn\ resource\ unit\ \fBconsume\fR 5
XSet the amount of resources consumed by the unit in a turn, even if it
Xdoesn't move or do anything else. This includes riding as a passenger.
XThis only comes into play if the unit has used less than its base
Xconsumption while moving. In other words, the total supply usage for
Xone unit in one turn is max(#moves * to-move, consume).
X.IP \fIn\ resource\ unit\ \fBin-length\fR 5
X.IP \fIn\ resource\ unit\ \fBout-length\fR 5
XThese two are used together to determine the length (in hexes) of supply lines
Xbetween units. The given type of resource can only be transferred from
Xunit type A to unit type B if the distance is less than the minimum of
Xthe in-length of B and the out-length of A.
XFor instance, the in-length
Xfor a fighter's fuel might be 3 hexes, while the out-length of fuel from
Xa city is 4 hexes. If the fighter's out-length is 0, then it will be
Xconstantly supplied with fuel when within 3 hexes of a city, but will never
Xtransfer any fuel to the city unless it actually lands there.
XAn in- or out-length of \fB0\fP
Xmeans that the two units must be in the same hex,
Xwhile a negative length disables the automatic transfer completely.
XLong out-length
Xlines should be used sparingly, since the algorithm uses the out-length to
Xdefine the radius of search for units to be resupplied. Supply lines are
Xnot affected by terrain at present.
X.IP \fIn%\ unit\ \fBsurvival\fR 5
XChance that a unit type can survive on no supplies. The test is made once
Xper turn.
X.IP \fIstring\ unit\ \fBstarve-message\fR 5
XSet what to say when unit has no more of some supply to consume.
XDefaults to \fB"runs out of supplies and dies"\fP.
X.LP
XThe movement phase is the main part of a turn in \fIxconq\fP, and the only part
Xinvolving interaction with players. All combat happens during the movement
Xphase.
X.IP \fIn\ unit\ \fBspeed\fR 5
XSet the maximum theoretical speed of a unit, in hexes/turn.
XIf the unit cannot move on any sort of terrain, it will never be prompted
Xabout - thus every period should define at least one type of moving unit.
X.IP \fIn\ terrain\ unit\ \fBmoves\fR 5
XSet extra moves used up on each type of terrain. \fB0\fP indicates no
Xdecrease from theoretical max, \fB2\fP indicates a move into that type
Xof terrain uses up 3 moves instead of 1, and \fB-1\fP indicates that
Xmovement on that type of terrain is not possible.
XDefaults to \fB-1\fP.
X.IP \fIn.01%\ terrain\ unit\ \fBrandom-move\fR 5
XSet the randomness of movement of a unit on the terrain. This is different
Xfrom disaster and attrition, since it is not always fatal, and happens only
Xduring attempts to move. However, collisions with other units or with
Ximpassable terrain, due to random moves, are always fatal.
X.IP \fIbool\ unit\ \fBfree-move\fR 5
XSet whether the unit can move even if there is insufficient movement
Xallowance remaining in this turn. Defaults to \fBtrue\fP.
X(Most board wargames make this false - if you don't have enough movement
Xpoints to meet the entry requirement for a hex, that's too bad.)
XCan be useful to make "double movement phases", if
Xattack time is equal to movement allowance; a unit can only attack units
Xthat it is adjacent to at the start of the movement phase.
X.IP \fIbool\ unit\ \fBone-move\fR 5
XSet whether the unit can make exactly one move before dying (appropriate
Xfor rockets and other automatic equipment). [NIY]
X.IP \fIbool\ unit\ \fBjump-move\fR 5
XSet whether a unit can jump over another unit to get somewhere. [NIY]
X.IP \fIn\ resource\ unit\ \fBto-move\fR 5
XSet the amount of resource used by a unit to move one hex.
XThe amount taken is independent of the terrain in the hex.
X.LP
XTransportation-related parameters. Capacity is measured both by number
Xand volume of occupants. For instance, if you wanted a transport to carry
Xup to 8 infantry and/or armor, but no more than 4 armor units, then capacity
Xfor infantry should be 8 and capacity for armor 4, the volumes for each
Xshould be 1, while the transport hold-volume should be 8.
X.IP \fIn\ unit2\ unit\ \fBcapacity\fR 5
XSet the basic carrying capability of a transport type \fIunit\fP
Xfor its occupants of type \fIunit2\fP.
X.IP \fIn\ unit\ \fBhold-volume\fR 5
XSet the volume capacity of a transport. Volume measure is quite arbitrary,
Xand is used only
Xfor comparison.
XThe default value of \fB0\fP implies infinite capacity, volume-wise.
X.IP \fIn\ unit\ \fBvolume\fR 5
XSet the volume of a unit. The volume of a unit may be smaller than its
Xhold-volume, the code will not care about this.
X.IP \fIn\ unit2\ unit\ \fBenter-time\fR 5
XNumber of moves needed to enter a transport. This is a time measure;
Xextra supplies are not used up.
X.IP \fIn\ unit2\ unit\ \fBleave-time\fR 5
XNumber of moves needed to leave a transport; similar to \fBenter-time\fP.
X.IP \fIn%\ unit2\ unit\ \fBalter-mobility\fR 5
XSet the effect of an occupant on the transport's speed as a ratio of the
Xtransport's usual speed. Defaults to \fB100\fP; smaller values slow the
Xtransport, and \fB0\fP prevents it from moving entirely. To simplify the code,
Xonly the effect of one (randomly chosen) type of occupant has this effect.
XIf a transport has two types of
Xoccupants each of which alter its speed differently, the resulting transport
Xspeed will be unpredictable.
XThe total slowdown is multiplied by the number of occupants of all types.
X.LP
XSeeing is an important part of \fIxconq\fP, and needs parameters to accommodate
Xsubmarines, radar installations, and Indians hiding in the woods.
XThe visibility of a unit and the intensity of viewing are computed separately,
Xand compared to get the final decision on seeing something. This doesn't
Xallow for much differential between two types of units viewing a third,
Xbut that's life. For units seeing things at a distance, the chances are
Xinterpolated linearly, from the best conditions (adjacent hex) to worst
X(maximum range).
X.IP \fIbool\ \fBall-seen\fR 5
XIf true, then all sides see all of each other's units. If secrecy unneeded
X(as in a board game), this will speed up the display process somewhat.
X.IP \fIn%\ unit\ \fBsee-best\fR 5
XSet the basic chance of one unit seeing any other,
Xunder best possible conditions. Defaults to \fB100\fP.
X.IP \fIn\ unit\ \fBsee-range\fR 5
XSet the maximum distance in hexes at which the unit can see anything.
XDefaults to \fB1\fP (adjacent hexes only).
X.IP \fIn%\ unit\ \fBsee-worst\fR 5
XSet the chance of seeing a unit at the maximum range.
XDefaults to \fB100\fP.
X.IP \fIn\ unit\ \fBvisibility\fR 5
XSet the basic chance of a unit to be seen.
XCrippled unit is more visible, in proportion to hp loss.
XDefaults to \fB100\fP.
X.IP \fIn%\ terrain\ unit\ \fBconceal\fR 5
XSet the percent effect of terrain on seeing the unit. This is subtracted
Xfrom the basic chance, since it is a "concealment factor".
X.IP \fIbool\ unit\ \fBalways-seen\fR 5
XDeclare the unit to be of a type that is always seen and up-to-date.
XThis applies only to units whose underlying hexes have been seen.
XThis is useful for units like towns,
Xwhich are unlikely to disappear secretly.
X.LP
XCombat is part of movement, and has its own large set of parameters.
XThe basic plan of combat is for attackers and defenders to hit each other,
Xthen attackers to attempt to capture.
XSuccess of a hit attempt depends on a number of attributes, including
Xchances, terrain, and the availability of the correct sort of ammo.
X.IP \fIbool\ unit\ \fBmulti-part\fR 5
XSet a unit to be treated as an aggregate of smaller identical units.
XAffects various things. [NIY]
X.IP \fIn\ unit\ \fBhp\fR 5
XSet the maximum number of hit points for each part of a unit.
XDefaults to \fB1\fP, may never be set any lower.
X.IP \fIn\ unit\ \fBcrippled\fR 5
XSet the hit point level below which the unit is considered to be crippled.
XBelow this level, repair and construction ceases, supply production is
Xreduced, maximum speed starts to decrease,
Xand the bridging capability is disabled.
X.IP \fIn%\ unit2\ unit\ \fBhit\fR 5
XBase chance of a single attack by the type \fIunit\fP
Xhitting the defender \fIunit2\fP, assuming the resources are available.
XIf chance to hit is \fB0\fP, attacker cannot attack or defend itself.
X.IP \fIn%\ terrain\ unit\ \fBdefense\fR 5
XSet the decreased chance of hitting if the defending type
X\fIunit\fP is in that terrain type.
XPercentage is subtracted from base chance.
X.IP \fIn%\ \fBneutrality\fR 5
XSet the change in defense for neutral units.
XThis is subtracted from chances to hit and capture, but the \fIn%\fP
Xcan be negative, which would make it harder to hit/capture.
X.IP \fIn\ unit2\ unit\ \fBdamage\fR 5
XNumber of hit points that the defender \fIunit2\fP loses when hit by
Xits attacker \fIunit\fP.
X.IP \fIn\ \fBnuke-hit\fR 5
XMinimum damage for a hit to qualify as a nuclear blast and be displayed
Xappropriately. Default value is \fB50\fP.
X.IP \fIbool\ unit\ \fBself-destruct\fR 5
XDeclare that unit self-destructs when it attacks. This eliminates some
Xweird messages and hit chances.
X.IP \fIbool\ \fBcounterattack\fR 5
XWhen true, combat is two-way; the initiator of an attack is also hit by
Xa counterattack. Otherwise, the defender must wait to get its revenge.
XDefaults to \fBtrue\fP.
X.IP \fIbool\ unit\ \fBcan-counter\fR 5
XLike \fBcounterattack\fP, but applies only to particular unit types
Xbeing attacked.
XDefaults to \fBtrue\fP.
X.IP \fIn%\ unit2\ unit\ \fBcapture\fR 5
XSet the base chance of the type \fIunit\fP capturing the defender
Xtype \fIunit2\fP. This is conditional
Xon both attacker and defender surviving initial hits, and is modified
Xby morale and quality of both sides.
X.IP \fIbool\ unit2\ unit\ \fBbridge\fR 5
XTrue if the unit type \fIunit2\fP can be captured by another unit
X\fIunit\fP, even across
Ximpassable terrain.
X.IP \fIn%\ unit\ \fBchanges-side\fR 5
XSet chance that the given unit will change sides if captured.
XThis is appropriate for units that are primarily hardware or
Xotherwise indifferent to their fate. Units that are captured and
Xdo not change sides become prisoners (prisoners are not implemented yet).
X.IP \fIn\ unit2\ unit\ \fBguard\fR 5
XSet the number of unit hit points required to garrison or guard a captured
Xtype \fIunit2\fP, whether or not the captured unit has changed sides
X(at present, it always does).
XThe hit point loss is permanent.
X.IP \fIn%\ unit\ \fBretreat\fR 5
XSet the base chance that a unit will retreat rather than be hit.
XThis choice depends on ability to move into an adjacent hex and on
Xmorale, quality, and fatigue.
X.IP \fIn\ resource\ unit\ \fBhits-with\fR 5
XSet the amounts of each resource used as ammo by the unit.
X.IP \fIn\ resource\ unit\ \fBhit-by\fR 5
XSet the amounts of each resource necessary to score a hit on the unit.
XThis is correlated with the previous parameter to decide if right sort
Xof ammo is available for an attack.
X.IP \fIn\ unit2\ unit\ \fBprotect\fR 5
XSet the level of protection that \fIunit\fP offers to \fIunit2\fP.
XTransports protect their occupants by only letting a percentage of
Xhits get through. Occupants protect their transports by reducing the
Xchance of a hit and increasing chance of a counterattack.
X(The default of \fB0\fP implies terrible carnage if a full transport is hit.)
X.IP \fIn\ unit\ \fBcombat-time\fR 5
XSet the extra number of moves used by an attack.
X.IP \fIstring\ unit\ \fBdestroy-message\fR 5
XSet what to say when a unit is killed in combat,
Xas an active verb for what the destroying unit has done to its victim.
XDefaults to \fB"destroys"\fP.
X.LP
XGeneral characteristics are not really classifiable anywhere else.
X.IP \fIn\ unit\ \fBterritory\fR 5
XSet the territorial value of a unit. Primarily used by machine players
Xand win/lose conditions.
X.IP \fIn\ unit\ \fBmax-quality\fR 5
XSet the maximum quality achievable by a unit.
X.IP \fIn%\ unit\ \fBveteran\fR 5
XSet the effect of one point of quality on hit and capture chances.
X.IP \fIn\ unit\ \fBmax-morale\fR 5
XSet the maximum morale to which a unit can rise.
X.IP \fIn%\ unit\ \fBcontrol\fR 5
XSet the chance of a unit obeying its orders. Defaults to \fB100\fP.
XWhen the unit does not obey orders, it makes a decision using the machine
Xplayers' algorithm.
X.IP \fIbool\ unit\ \fBcan-disband\fR 5
XSet whether a 'D' disband command can be used to get rid of a unit.
XIt should not be possible to disband a city, for instance, to eliminate
Xit as a strategic target. Note that the default of \fB0\fP effectively
Xdisables the disbanding command entirely.
X.IP \fIn%\ \fBefficiency\fR 5
XUnits disbanded in a transport can have the resources used to build them
Xreclaimed - this parameter sets the percentage that is actually obtained.
X.IP \fIbool\ unit\ \fBneutral\fR 5
XSet to \fBtrue\fP if unit can exist as a neutral.
XIf \fBfalse\fP, then anything that
Xwould cause the unit to become neutral (revolt, surrender of owner)
Xhas the effect of removing it instead. Defaults to \fBfalse\fP.
X.LP
XMiscellaneous words.
X.IP \fIn\ \fBhostility\fR 5
XSet the level of hostility exhibited by a population toward a unit
Xfrom some other side. [NIY]
X.IP \fBbegin{notes}\fR 5
XDeclare the beginning of the designer's notes. This word kicks in a
Xspecial reader that absorbs all lines until it sees the line
X"\fBend{notes}\fP". The intervening lines are saved as period notes and
Xlisted out in \fB"parms.xconq"\fP.
XThe notes should rationalize the design and discuss features
Xof special interest to the player.
X.IP \fBend\fR 5
XMarks the end of the period description.
X.LP
XNearly all the elementary programming errors are checked, such as stack
Xover/underflow, and
Xas many of the period parameters as possible will be checked, although
Xthere is plenty of room for subtle loopholes. You should think carefully
Xabout the consequences of each parameter, being particularly sensitive to
Xdegenerate winning strategies. Most common are units that are too powerful,
Xor that are built so quickly that they overwhelm any opposition. The
Xplayers should always be a little "hungry"; not able to get quite as much
Xof units or resources as they would really like.
X.LP
XAlthough there are many interesting possibilities inherent in this
Xperiod description language, you should avoid making the period too
Xcomplex to be humanly playable. The compiled form of the period description
Xcan involve over 16,000 individually settable numbers, each with an expected
Xrange of perhaps 100 distinct values. It is clearly possible to spend many
Xyears exploring a single set of these numbers. For more playable and
Xenjoyable games, either pick a single aspect to treat in detail, or else
Xdo all aspects in a simplified way. Aspects could include exploration,
Xlogistics, naval operations, "shoot-em-up", renditions of familiar board
Xgames or even some team sports (rugby for instance). Another thing to
Xkeep in mind is that the introduction of a new type may have far-reaching
Xconsequences - a new unit type will need its interactions with \fIall\fP
Xother unit types defined. One approach is to introduce a new type as a
Xslight modification of an existing type, then to share most of the
Xdefinitions.
X.LP
XSomething else to keep in mind is that the period parameters have been
Xchosen for their ability to combine in interesting ways, rather than for
Xobvious usefulness. For example, past startup, the production rate for
Xunits is constant and unending. But suppose you want to put a limit on
Xthe numbers of that type of unit? One way is to define a resource that
Xis essential for construction of that type, let the builder have an initial
Xsupply, but provide no way to get more of that resource. When it runs out,
Xno more units! Another trick is to motivate an activity by making it a
Xprerequisite to the basic builtin goal of defeating the other player.
XThe age of discovery worked this way. The kings of that time weren't
Xinterested in new lands per se; they wanted exploitable possessions that
Xcould be used to get gold to buy armies big enough to defeat their neighbors.
XThe period language could describe this situation almost exactly, by making
Xgold a resource obtainable only by the capture of neutral mines thinly
Xscattered over the map. Be inventive!
XStudying the predefined periods should reveal a number of tricks.
X.LP
XCompletely new periods usually have a number of bugs. The tools are
Xrather limited, but then most of the bugs are fairly obvious.
XThe \fBprint\fP word is useful for examining the stack, and a number of
Xerrors (such as stack overflow/underflow) have messages. Finding out
Xwhere the problem occurred requires the use of the \fIxconq\fP debugging
Xflag \fB-D\fP, which has the effect of listing out each period token as
Xit is read. This can also be used with the period compiler, which starts
Xup faster; invoke it as \fB"per2c -D <newperiod.per"\fP. The most serious
Xproblems with periods are play balance issues. Some can be found out by
Xwatching a machine player, since its decisions are based on perceived values
Xof the units. The most subtle bugs can only be uncovered by extensive play
Xinterspersed with judicious alteration of parameters. I find it useful to
Xplay for a while, then go over all the period parameters, thus avoiding
Xtweaking one parameter only to find that it results in another being
Xinconsistent. Parameters interact in many ways - you should keep this in
Xmind when experimenting.
END_OF_period.ms
if test 40667 -ne `wc -c <period.ms`; then
echo shar: \"period.ms\" unpacked with wrong size!
fi
# end of overwriting check
fi
echo shar: End of archive 1 \(of 18\).
cp /dev/null ark1isdone
MISSING=""
for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ; do
if test ! -f ark${I}isdone ; then
MISSING="${MISSING} ${I}"
fi
done
if test "${MISSING}" = "" ; then
echo You have unpacked all 18 archives.
rm -f ark[1-9]isdone ark[1-9][0-9]isdone
else
echo You still need to unpack the following archives:
echo " " ${MISSING}
fi
## End of shell archive.
exit 0