This is where I justify what I've done, and not done.
Please note that although Xconq has considerable power, its design was expressly limited to a particular class of two-dimensional board-like strategy games, and that playability is emphasized over generality. For instance, I avoided the temptation to include a general-purpose language, since it opens up many difficult issues and makes it much harder for game designers to produce a desired game (after all, if game designers wanted to use a general-purpose programming language, they could just write C code!). Similarly, full 3D, realtime maneuvering, continuous terrain, and other such goodies must await the truly ultimate game system.
The real problem with a general-purpose language is that although everything is possible, nothing is easy. Many "adventure game writing systems" have fallen into this trap; they end up being poor reimplementations of standard programming languages, and the sole support for adventure gaming amounts to a small program skeleton and a few library functions. It would have been easier just to start with a pre-existing language and just write the skeleton and libraries!
Xconq, on the other hand, provides extensive optimized support for random game setup, large numbers of units, game save/restore, computer opponents, and many other facets of a game. Game designers don't have to deal with the subleties of fractal terrain synthesis, or the ordering of terrain effects on units, or how to tell the computer opponents that airbases are sometimes good for refueling but never any good for transportation, or the myriad of other details that are wired into Xconq. In fact, a complete working game can be set up with less than a half-page of GDL.
Even so, the current Xconq design allows for several layers of extensibility, as was described earlier in this chapter.
There are also several major areas in which Xconq could be improved.
Tables should be supplemented with general formulae, although such formulae will complicate AIs' analyses considerably, since tables are much easier to scan. Formula-based game definition would work much better with AIs that are coded specifically for the game and compiled in; this is more-or-less possible now, but there is not yet a good way to keep AIs from being used in games where they would be inappropriate (it might be amusing to have a panzer general AI attempting to play Gettysburg, but the coding would have to be careful not to try to index nonexistent unit types).
Currently everything is based on a single area of a single world. This could be extended to multiple areas in the world, perhaps at different scales, as well as to multiple worlds. The coding implications are severe, since much of the code mentions x,y alone, with the area implicit. One intermediate solution is to have one area be "active" and shift areas as needed (multiple-level dungeon games work this way).
Also see section GDL Design Decisions.
However, even with its limitations, Xconq has provided, and will continue to provide, many years of enjoyable playing, designing, and hacking. Go to it!