This chapter would not be complete without some discussion of the traps awaiting the unwary hacker. The Absolute Number One Hazard in hacking Xconq is to introduce code that does not work for all game designs. It is all too easy to assume that, for instance, unit speeds are always less than 20, or airbases can only be built by infantry, or that worlds are always randomly-generated. These sorts of assumptions have caused no end of problems. Code should test preconditions, especially for dynamically-allocated game-specified objects, and it should be tested using the various test scripts in the test directory.
The number two pitfall is to not account for all the possible interfaces. Not all interfaces have a single "current unit" or map window, and some communicate with multiple players or over a network connection.
You should not assume that your hack is generally valid until you have tested it against everything in the library and test directories. The `test' directory contains scripts that will be useful for this, at least to Unix hackers. See the `README' in that directory for more information.
Another pitfall is to be sloppy about performance. An algorithm that works fine in a small world with two sides and 50 units may be painfully slow in a large game. Or, the algorithm may allocate too much working space and wind up exhausting memory (this has often happened). You should familiarize yourself with the algorithms already used in Xconq, since they have already been debugged and tuned, and many have been written as generically useful code (see the area-scanning functions in `world.c' for instance).
If your new feature is expensive, then define a global and compute its
value only once, either at the start of the game or when it becomes
relevant. Such a global should be named any_<feature>.
Similarly, complicated tests on unit types or sides should be calculated once and cached in a dynamically-allocated array.