GDL is intended to be an easily used, yet powerful, tool for people who have little programming experience, but who wish to design Xconq game modules. For those who have programmed in Lisp before, GDL uses a similar syntax, but knowledge of Lisp is not required to develop Xconq games. Elements of GDL include such things as numbers, lists, and tables.
Formally, GDL is a declarative, or nonprocedural, language, rather
than an imperative language. This means that most of the time, you can
declare lists, tables, and forms (which will be discussed later) in
any order you like. There are two significant, though not unreasonable,
restrictions however. The first is that any symbol, such as a variable
or the name of a type, must be defined before it is used. The second is
that a symbol must be used in an appropriate context or scope. This is
basically to say that you can only assign properties to things for
which those properties would make sense. Keep in mind that definitions
can be overwritten with the use of
add (which will
also be discussed later), and the order in which they are used is
The Xconq interpreter parses GDL declarations into various lexical elements, or tokens. These include numbers, strings, symbols, comment delimiters, and list/form/table delimiters.
Numbers are introduced by a decimal digit, plus, or minus signs. They
may contain only decimal digits, a decimal point, and be followed
(immediately, no whitespace allowed) by a percent sign. Numbers are
used where integer quantities, percentages (which may meaningfully
exceed 100% in many cases), or parts per 10,000 (0.01% increments) are
expected. Typically numbers are positive. Unless otherwise stated,
the default value for properties that take numeric values is
Also of interest is the fact that
-1 is often used to indicate
special behavior of a property or table element, such as "turning off"
the property, or inheriting a value set in another table. Examples of
numeric values include the following:
Strings are sequences of characters (letters, digits, punctuation marks,
etc...) enclosed by doublequotes (
They may contain any character except ASCII NUL (
include a doublequote, use backslash, as in
string". To include a nonprinting or eight-bit character (often
associated with international characters or ANSI graphics), use
backslash followed by three octal digits, which will be interpreted as
an eight-bit character code. (This is mostly the same syntax as in C.)
Note that game design files may be passed over networks and between
different kinds of computer systems, so non-ASCII characters should not
be inserted verbatim into strings. In places where string values are
expected, the default is
"", unless otherwise stated.
Symbols are sequences of characters that don't include any of the other
special characters. If you wish to include such characters in a symbol,
enclose it in vertical bars, for example
|foo bar|. (The bars
are not part of the symbol.) Symbols are case-sensitive, but this will
be changed eventually. Examples of symbols include:
|coastal waters|, and
Numbers, strings, and symbols all belong to a kind called an atom. There are other elements of GDL which are not atoms; these are comments and lists.
Comments are enclosed either within
#| |#, or else extend from a
; to the end of the line. A comment is equivalent to
a#|bcd|#e is the same as
a e, not
#| |# style comments can be nested (placed inside
one another) without trouble, and are allowed to extend across multiple
lines. Note that
# by itself is nothing special and can be used as
a normal character in, say, a symbol.
Lists are a sequence of atoms and/or other lists enclosed in parentheses.
Empty lists can either be represented by the symbol
nil or by the
(). There is nothing similar to the "dotted pairs" of Lisp;
if you don't know what dotted pairs are, then don't worry about it.
Tables and forms, both of which will be discussed in more detail later,
are delimited by parentheses in the same manner as lists. Indeed, forms
can be thought of as lists that start with a special symbol, or keyword.
Lists might look like
(100 90 0),
((10 0 10) (5 10 15)),
(cv bb dd),
("1 atom"), or
nil. Some examples of things which are not lists are
"1 atom", which, like it says, is one atom, and:
(10 20 ; This comment can cause problems. )
because everything past the semicolon is ignored. An acceptable alternative would be:
(10 20 #| This comment will not cause problems. |#)
All of the things mentioned above may range up to a very large size. In
particular, numbers can generally hold values up to 32767 (sometimes
referred to as TABHI or PROPHI in the documentation), though most
games use values such as
9999 for a value
which is too large to ever be reached.
Most tables are limited to be 127x127 at largest (which is really quite
large); this is due to Xconq's present internal constraints on the
number of unit types, terrain types, et cetera, that may be defined.
Although strings and symbols are allowed to be quite large, one should
exercise caution and keep them around a 100 characters or less in length,
lest bugs (or "unexpected features") be tempted to emerge.
True/false values are just numbers, with no special characteristics.
These constants are symbolic forms for
0. They are
identical to numbers, but more descriptive for parameters that are
Unit, material, and terrain types are distinct objects. However, they can be considered to have numeric "indices" assigned in order of the types' definition. These numbers are not directly visible in GDL, but they often affect sorting and ordering.
You may also supply numbers as dice specs, which are used in
several tables. The syntax is the familiar
nndmm[+oo], where nn is the number of
dice to throw, mm is the number of values on each die, and the
optional oo is an value to be added to the result. The die are
0-based, so for instance
3d6 yields values between 0 and 15,
3d6+3 is equivalent to the result of rolling 3 6-sided
dice. The range of each value is severely limited; nn may range
from 0 to 7, mm from 0 to 15, and oo from 0 to 127.
Internally, dice specs are normal integers, in the range 16384 to 32767.
Descriptions of values in this manual follow the conventions listed here.
For parameters described as t/f, both
false may be used. Parameters described as n
and n% are numbers. Parameters described as dist or
length are also numbers, but are in the unit of measure for
lengths. Parameters described as str or string are strings.
Parameters described as u or ui, m or mi, and t or ti, are values that must be unit, material, or terrain types, respectively.
Parameters described as utype-value-list match unit types with values. They can have several forms:
(n1 n2 ...)matches
n1with type 0, etc in order.
((u1 n1) (u2 n2) ...)evaluates
u1to get a unit type, then matches it with
u1etc may also be a list of types, in which case all the types get matched with
Other types of lists, such as those defined as side-value-list, are interpreted similarly. For all of these, multiple assignments to the same type etc will overwrite quietly.
List values described as interpolation-list are lists of pairs
used to derive numerical values by interpolating between the listed
values. The form of an interpolation list is always
(key2 val2) ...)), where keyi and vali are numbers. If the
input value inp to an interpolation matches keyi, the result
value is vali. If it is between keyi and keyi+1, then
the result is gotten by linear interpolation, with the result value
falling somewhere between vali and vali+1. Fractional
values always round down. The keyi must occur in non-decreasing
order; it is legitimate for two consecutive keys to be identical, in
which the result value will be the value associated with the first key.
If the input value is outside the domain specified by the keys, the
result depends on the particular parameter; some will extrapolate in
some appropriate fashion, while others will generate an error or
warning. To be safe, one should set up key-value pairs for the min and
max of the input domain.
One place where an interpolation list is used is the
acp-damage-effect property that may be assigned to unit types.
Suppose we have a unit type named
battleship, which has 30 hit
points and 6 action points when fully healthy. When the battleship
reaches various levels of damage, we want to affect its ability to
act to simulate such things as a gun turret or propeller being destroyed.
To do this, we can assign the
acp-damage-effect property in
perhaps the following way:
(unit-type battleship (acp-damage-effect ((0 0) (10 2) (20 4) (30 6))) )
Now how many action points will the battleship have when it has 15 hit points? The answer should be 3 action points. When it has 14 hit points? 2 action points (remember that fractional parts round down). When it has 16 hit points? Again, 3 action points. When it has 10 hit points? 2 action points (this can be read directly from the interpolation list). When it has 4 hit points? 0 action points.
Some values may be boolean expressions. Boolean expressions are lists
headed by the keywords
not, and may
nest recursively. For instance, the expression
(and (or false (not false)) true)
is always true. In some contexts, values other than
false may appear, in which case the interpretation of those
values depends on the context.
Some numeric values are stochastic, meaning that they are partly fixed and partly probabilistic in effect. The most common form of this is values where the part > 100 is divided by 100, while the value mod 100 is the probability to add 1 to the first part. Thus a value of 425 works out to a value of 4, 3/4 of the time, and to 5, 1/4 of the time, on average.
Unless otherwise stated, all numeric values default to
string values default to
"", and all form values default to
(). If one of these defaults has a notable consequence, such as
inability to perform some action, that will be mentioned.
A form is any single expression that appears in the file.
A GDL file consists of a sequence of forms. Most forms of interest will
be lists whose first element is a symbol identifying the form. For
instance, a form beginning with the symbol
side declares a side
object. When the file containing such a form is read, Xconq will
create a side object and fill in any properties as specified by the
form. (Properties are like properties or attributes - most GDL objects
In most contexts, Xconq will evaluate an expression before
using it, such as when filling in an object's property. Numbers and
strings evaluate to themselves, while symbols evaluate to their
bindings, as set by
define. Lists evaluate to a
list of the same length, but with all the elements evaluated, unless the
first element of the list is a function. In that case, the remaining
elements of the list are evaluated and given to the function, and its
result will be the result.
A table is a two-dimensional array of values indexed by types. Indices can be any pair of unit, material, or terrain type. The set of tables is fixed by Xconq, and all are described below.
table table-name items...
This is the general form to fill in a table. The table named by
table-name is filled in from the items. If an item is an
atom, then every position in the table is filled in with that item,
overwriting any previously-specified values. If an item is a list, it
must be a three-element list of the form
value). If both type1 and type2 are single types,
then value will be put into the table at the position indexed by
the two types. If one of type1 or type2 evaluates to a
list, Xconq will iterate over all members of the list while keeping
the other type constant, while if both type1 and type2 are
lists, then Xconq will iterate over all pairs from the two lists.
The values used during iteration depend on whether the value is a
list. If value is an atom, then that value will just be used on
every iteration. If a list, then Xconq will use successive elements
of the list while iterating.
If the first member of items is the symbol
add, then the
rest of the items will add to the existing contents of the table rather
than clearing to its default value first.
The following forms are all equivalent:
(table foo (a y 1) (b y 2) (c y 3) (a z 9) (b z 9) (c z 9)) (table foo ((a b c) y (1 2 3)) ((a b c) (z) 9)) (define v1 (a b c)) (table foo (v1 y (1 2 3)) (v1 z 9)) (table foo ((a b c) (y z) ((1 2 3) (9 9 9)))) (table foo (a y 1) (b y 2) (c y 3)) (table foo add ((a b c) z 9))
Since forms normally define or create new objects, GDL defines the
add form to modify existing objects.
add objects property new-values...
This form evaluates the atom or list objects to arrive at the set of objects to be modified. Then it uses the new-values to write new data into the property named property of those objects. The new-values may be a single number or string, or a list.
Most of the symbols used in a game module are the predefined ones described in this manual. Others are attached to types when the types are defined, and still others name objects like units and sides. You can also define and set your own symbols to arbitrary values.
define symbol value
This form defines the symbol symbol to be bound to the result of evaluating value. If symbol is already defined, Xconq will issue a warning, and ignore this form.
set symbol value
This form rebinds the already-bound symbol symbol to be bound to the result of evaluating value. If symbol is not bound already, then Xconq will issue a warning, but proceed anyway.
This form destroys any binding of the symbol. This is allowed for any symbol, including already-unbound symbols.
Some transformations can be performed on lists. All of these are transforms are non-destructive, which is to say that the original list is not altered, but a new list with the transformation applied is returned as a result.
This function prevents any evaluation of form. (This implies that the abovementioned evaluation of the argument list does not happen for this "function".)
This function makes a list out of all the form.
NOTE: If you are not a Lisp programmer, be cautious about inferring what this
function does based on its name.
This function "appends" all the form (which may be lists or not) into a single list. Another way to state the above is:
gathers everything following it into one list, "flattening out" any lists
it encounters, and returns the result.
remove item list
This function removes item from every place that it occurs in list, returning the resulting list. If item is not found in list, then list is returned.
remove-list list1 list2
This function removes each item of list list1 from every place that it occurs in list2, returning the resulting list. If no item in list1 is found in list2, then list2 is returned.
Some examples of the above commands:
The following three are all equivalent examples of quoting; they leave the
list contents unevaluated when the list is first read.
(quote not "independent")
Quoting is useful for things that should not be evaluated immediately, but
may be used Xconq later during run time (after the game has been read in).
These things include
Here is an example of appending:
(define light-sea-u* (destroyer frigate))
(define heavy-sea-u* (battleship carrier))
(define sea-u* (append light-sea-u* heavy-sea-u*))
In the above, two lists are defined. Then those two lists are joined into a single list,
sea-u*. Note that
be equivalent to the following definition:
(define sea-u* (destroyer frigate battleship carrier))
(define sea-u* ((destroyer frigate) (battleship carrier)))
because the lists were flattened.
Here is another example of appending:
(define wyrms (red-wyrms blue-wyrms green-wyrms))
(define dragons (append wyrms dragon-turtle))
In this case
wyrms is a list, while
dragon-turtle might be
an atom. The definition of
dragons would therefore be equivalent to:
(define dragons (red-wyrms blue-wyrms green-wyrms dragon-turtle))
Here is an example of removing a single item:
(define land-combat-u* (infantry mechinf cavalry armor))
(define motor-land-combat-u* (remove infantry land-combat-u*))
The definition of
motor-land-combat-u* would then be equivalent to:
(define motor-land-combat-u* (mechinf cavalry armor))
Here is an example of removing multiple items:
(define monsters (daleks sontarans cybermen ice-warriors))
(define bad-robots (remove-list (sontarans ice-warriors) monsters))
And here is a more sophisticated example of removing and appending:
(define nco-ranks (chief senior-chief master-chief))
(define low-ranks (ensign lieutenant-jg lieutenant commander))
(define high-ranks (captain commodore r-admiral v-admiral admiral))
(define rank-sets (nco-ranks low-ranks high-ranks))
(define com-ranks (append (remove nco-ranks rank-sets)))
which is equivalent to:
(define com-ranks (append low-ranks high-ranks))
which is equivalent to:
(define com-ranks (ensign lieutenant-jg lieutenant commander captain commodore r-admiral v-admiral admiral))
One should note that in the above example, a list,
treated as the item to remove.
The above example can also be done in terms of
(define all-ranks (append nco-ranks low-ranks high-ranks))
(define com-ranks (remove-list nco-ranks all-ranks))
GDL supports some basic mathematical operations. Addition, subtraction, multiplication, and division are all available. To use an operator, it must be at the start of a new form; everything after it until the end of that form will be interpreted as operands.
All four of the basic operators can operate on numbers, lists of numbers, and symbols which are bound to either numbers or lists of numbers, and any combination thereof. The only constraint is that all lists must be the same lengths as one another, with the exception that empty lists are allowed and will simply be skipped over. When a number is operated with a list, that number is operated with each item of the list. When a list is operated with a list, each item of the first operand list is operated with the item in the corresponding position of the second operand list. Thus, when a number is operated with a number, a number is always returned as the result. When a number is operated with a list or vice versa, a list is always returned as the result. When a list is operated with a list, then another list is always returned as the result.
Operators forms can be nested inside one another. Multiple operators within the same operator form are not allowed. Precedence is determined by evaluating the innermost (most deeply nested) operators first. Association is from left to right.
The results of operations are still subject to the same constraints as
numbers and lists produced without operations. Value limits, such as
-32768, still apply. Because of this, you should
be careful not to multiply, add, or subtract quantities that are too large
in numeric magnitude or you may end up with undesired results.
Another thing to note about numbers is that, to Xconq,
0.10 are all the same thing. Likewise for
4.00. Generally, when designing a
game, you should not have to worry about how these number representations
are handled internally; that is for the Xconq code writers to worry about.
However, if you are doing math on numbers, this knowledge does come into
play, unfortunately. For instance, if you use GDL to multiply a plain
integer by a percent, you will not get a result that is a percentage of the
integer. Some of the examples below will show you the correct way to deal
with this and other similar situations. Also note that dice specs are
treated as numbers internally in Xconq, and so there is a special way to
manipulate them as well. Again, this will be demonstrated in the examples
Sums all of the operands together. If only one operand is present,
then that operand is returned unaltered. If no operands are present, then
the additive identity,
0, is returned.
- operand1 operands...
Subtracts all of the operands from operand1. If only
operand1 is present, then
0 minus operand1 is
returned. If no operands are present, then it returns
Multiplies all the operands together. Must have at least two operands
to multiply, or else it returns
nil, except when no operands
are specified, in which case it returns the multiplicative identity,
/ operand1 operands...
Divides all of the operands into operand1. If less than
two operands are present, then it returns
NOTE: Unlike Common Lisp, GDL does not support rational numbers, and therefore it is not possible for division with a single operand to return the reciprocal of that operand as Common Lisp implementations do. Furthermore, since all arithmetic is integer arithmetic in GDL, values between integers cannot be represented; numbers between
1 will appear as
Here are some examples of addition:
(+ 1 1)
(+ 1 2 3 4 5)
(+ 1 (-1 2))
(+ (50% 75%) 25%)
(+ (0.33 0.67) (0.67 1.33))
(define FOOD_RATS_LOSS 20%)
(define FOOD_ROT_LOSS 10%)
(define FODD_LOSS (+ FOOD_RATS_LOSS FOOD_ROT_LOSS))
is the same as
(define FOOD_LOSS 30%)
(+ (10 20) (30 40) (50 60) (70 80) (90 0))
(+ 10 25 (+ 20 25))
Here are some examples of subtraction:
(- 10 5)
(- 15 5 4 3 2)
(- 10 (4 5))
(- (10 15) 10)
(- (1.00 1.50) (0.25 0.45))
(define burden 25%)
(define speed-effect (- burden))
is equivalent to
(define speed-effect -25%)
Here are some examples of multiplication:
(* 5 5)
(* 5 4 3 2 1)
(* -1 (5 10))
(* (25% 50%) 5)
(* (2.00 5.00) (10 5))
Here are some examples of division:
(/ 14 2)
(/ 15 2)
(/ 80 100)
(/ 12 (6 4 3 2))
(2 3 4 6)
(/ (15 10) 5)
(/ (100% 250%) (2 5))
To take a percentage of a number, you need to do something like the
(/ (* 4 50%) 100)
To properly multiply a number by a decimal factor, you must do something
like the following:
(/ (* 5 4.00) 100)
(/ (* 40 0.25) 100)
(/ (* 3.00 3.00) 100)
900 if you prefer to see it that way
To properly multiply a number by a fraction, try something like the
(/ (* full-speed 4) 5)
which returns four-fifths of
[ TODO: Write examples of dice spec manipulation. ]