Go to the first, previous, next, last section, table of contents.

## Pitfalls

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.

You may have noticed that Xconq sources have been liberally sprinkled with debugging code, and you may desire to add some yourself. In this modern age of computing, powerful source-level debuggers are widely available, so there is no good reason to add debugging code to do a job that would be better done by the debugger. Xconq debugging output is generally designed to be useful for understanding average behavior, changes over time, and "high-level transients" such as thrashing in plan or task execution; information that is difficult to collect using only a debugger. When adding new debug output, you should keep this principle in mind. Also, be aware that some of the automated testing scripts enable debug output, so if you add something that is uselessly voluminous, testing output may fill your disk prematurely!

Go to the first, previous, next, last section, table of contents.