Hacking Xconq

The School for Strategy

Version 7.3

June 2000

Stanley T. Shebs Copyright (C) 1987-1989, 1991-2000 Stanley T. Shebs

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled "GNU General Public License" is included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the section entitled "GNU General Public License", and this permission notice, may be included in translations approved by the Free Software Foundation instead of in the original English.

Introduction

This manual describes the internal architecture of Xconq, and provides information and guidelines for modifying the sources. You should know what you are doing; Xconq is designed to be modifiable, but it is not simple code. In the past, people have found it easy to make changes, but much harder to make them correctly!

First, the overall goals of Xconq. Xconq cannot and does not attempt to be all things to all people; instead it focusses on a very particular class of game, namely map/overhead-view strategy games. This has become a rather well-worn genre of game, but the field is still open for innovation; Xconq's main contribution is that it allows the construction of many different games in this genre, without requiring low-level programming.

These are the specific goals for Xconq:

@bullet{Portability.}

Xconq should be able to run on a wide variety of machines. However, new versions need not restricted by the limits of old systems.

@bullet{AI}

It should be possible for a game AI to play any side in any game.

@bullet{Networking}

It should be possible for any player on the net to play any side.

@bullet{Scale}

Xconq should work well for games of strategic and operational maneuver based on a 2D surface. It does not need to work well for tactical games, adventure games, space games, or anything requiring full 3D. Xconq should be able to handle very large games.

@bullet{Game Design}

The designer should be able to use GDL to build any strategic-level game desired. There should be multiple computational models available to the designer, such as different algorithms combat resolution.

@bullet{Graphics}

It should be possible to use graphics of a high quality, but it should not be required to produce a playable game. The designer should be able to adjust all aspects of a game's appearance.

@bullet{Play Action}

It should be possible to design both turn-based and real-time games, the choice being left to the game designer. It should also be possible to design both simple easy-to-play games and complex detailed games.

Xconq is designed to be portable to different types of user interfaces. It is based on a kernel-interface architecture, where the semantics of the game, as documented in the preceding chapters, is part of the kernel, while the main program and player interaction are specific to each system.

Xconq is also designed to allow the addition of new AIs. The default "mplayer" AI, while it is flexible and will attempt to play any side in any game, does not have the depth that is often important to success in a game. Its position is that of a generic AI program that can learn to play any game, given only the rules; while such a program might figure out how to win at tic-tac-toe or checkers, it is not going to be particularly good at the subtleties of go or chess.

The Xconq GDL is also extensible. This is useful when the basic GDL does not provide some feature that is essential to a game.