Designing Games with Xconq - Debugging Designs

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

## Debugging Designs

Completely new game designs usually have a number of bugs. There are several stages of trouble that you may encounter. First, the Xconq may fail to read a game module completely. It will try to report what happened, but if for instance you left out a closing parenthesis, you may get some strange error messages. This is just plain old syntax error trouble.

Once you've successfuly read in your new game, bring up the online help and scan through to see if the values present are what you thought. Sometimes the reader does not interpret a module in the way you thought it would. The `print` form is useful for debugging at this point; it can show you whether a defined symbol has the value you thought it did.

However, the most serious problems with games are play balance issues. Some can be found out by watching a machine player attached to a display, since its decisions are based on perceived values of the units. The most subtle bugs can only be uncovered by extensive play interspersed with judicious alteration of parameters. I find it useful to play for a while, then review and adjust the game parameters all at once, thus avoiding tweaking one parameter only to find that it results in another being inconsistent. Parameters interact in many ways - you should keep this in mind when experimenting.

Something else to keep in mind at this point is that playability should outweigh realism. For example, real-life airplanes can travel 1,000 times faster than a person walking on the ground, but airplanes that could move 1,000 cells in a turn would be ridiculous (try it out, Xconq will let you do this!).

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