Chapter 24: Testing and Debugging
§24.1. Checking against the Index; §24.2. Debugging features to use in source; §24.3. High-level debugging commands; §24.4. Low-level debugging commands; §24.5. Adding new testing verbs and Release for Testing; §24.6. Testing for thoroughness; §24.7. Commands for beta-testers; §24.8. Help from the user community
|Contents of Writing with Inform|
|Chapter 23: Figures, Sounds and Files|
|Chapter 25: Releasing|
|Indexes of the examples|
§24.1. Checking against the Index
Testing a game -- and indeed writing a game so that it is easy to test consistently -- is an art in itself. We should expect that we'll do some preliminary testing, both by running test commands and by playing through the game ourselves, and that we'll then hand on the game to beta-testers who will tell us about faults in the play experience that we haven't been able to see.
Every time Inform builds a new story file, it assembles a vast amount of information about that world, in the form of the Index. Often a visit to the Index is all that's needed to explain a piece of undesired behavior.
Is travel not working as it should? Check the World index and see whether the map shows the rooms arranged the way you thought.
Are objects not showing the behavior you'd expect based on their kind? Check the Kinds index and make sure they've been defined as the kind of thing you expected. For instance, we might find that we've written
The red door is west of Foo and east of Bar.
The red door is a door.
A human reader wouldn't make this mistake, but Inform hasn't actually registered the red door as belonging to the door kind, and consequently has treated it as a room instead. All we need to do is add the kind declaration. The Kinds index will make that obvious.
When an error appears in the Index, there is often a link back to the source text that defined that room or object. If not, there's often at least some information about what rule or phrase might be responsible for it.