GDL has been designed so as to be relatively easily extensible. I say "relatively" because although it is quite easy to define a new keyword or table, it is not always so easy to integrate the implementation code into the kernel correctly.
Instead of actually changing GDL, you can experiment with an addition
by using the extensions
property of unit, material, and terrain types.
In the code, you call get_u_extension
, pass it the type, name
of the property, and a default to return if the value was not given.
In the game definition, the designer would say
(unit town (extensions (my-ext xxx)))
.
[show examples for global, property, table, event, task]
The file gvar.def
defines all the global variables.
The file utype.def
defines all the unit type properties.
From time to time, it may be worthwhile to extend unit objects.
This should be rare, because games may have thousands of units,
and each unit requires at least 100 bytes of storage already,
so you should avoid making them any larger.
Properties of an individual unit are scattered through keyword.def
.
Once the structure slot is added, you just need to add reading and
writing of the value, using the K_xxx
enum that was
defined with the keyword. You should attempt to make a reasonable
default and use it to avoid writing out the value, so as to save
time when Xconq reads a game in.
GDL symbols beginning with zz-
should be reserved for the use
of AI code. You may want to add some of these, either to serve as a
convenient place for AIs to cache the results of their analyis of a
game, or else as a way for game designers to add "hints" for AIs
that know to look at them.
Note that all the `*.def' files together are to define the exact set of symbols defined by GDL. You should not add any expedient matching on symbols or searching for particular symbols without adding them to an appropriate `.def' file.