Unit types define what the players get to play with. Unit types can include almost anything; people, buildings, airplanes, monsters, arrows, boulders, you name it.
The basic form of a unit type definition is so:
(unit-type type-name (property-name property-value) ...)
The appearance of this form in a file means you are adding a new and
distinct type, which has no relation to any other types defined before
and after this one. The type-name must be a unique symbol,
such as building
or |fire truck|
. (Note that you can set
things up so that players never see the type-name anywhere,
so don't worry if your preferred name conflicts with something else,
just choose another name.)
The property-name and property-value pairs are entirely optional.
They can always be defined or changed later in the file.
There is little advantage one way or another.
This particular syntax - keyword followed by name or other identifier followed by property/value pairs - will be used for most GDL definitions.
The number of unit types is limited. The exact limit depends on the implementation, but is guaranteed to be at least 127. This is a huge number of types in practice; the only situations where this might be needed would be a fantasy-type game with many types of items and monsters. For empire-building games, 8-16 unit types is far more reasonable. Keep in mind that with lots of types, players have more to keep track of, internal data structures will be larger and take longer to work with, and designing the game will take more time and energy. Consider also that Xconq gives you a lot of properties that you can set individually for each unit type, so that when other game systems might require a distinct types, Xconq lets you use the same type with different propertys. For instance, in a fantasy game you wouldn't need to define "young dragons" and "old dragons" as distinct types, instead you can vary the hit points or experience of a generic "dragon" type.