Yes, you should write that small diagnostic.

A lot of times when I'm writing a text adventure, I think of how to write a test command a bit late. Part of that is that I still feel like I'm cheating to zip around the game, because it really is fun to poke holes in things, even my own. I recommend it to others, to have a "god mode" in your own game. Stuff you won't let the players do, or that you may only let trusted testers do.

The big problem is that I say, well, it'll only have so much impact. Part of the problem is me not planning ahead, but I've also found I was able to tweak a script or a player command to test other things as well. And even finding one bug it'd be a pain to track down again worked. It's nice that Inform allows a test command that lets you know there's a path through the game, but it's even nicer to be able to jump ahead or say "If this weren't broken..."

Because 90+% of the time, the small utilities I think up tend to grow or be cannibalized by other bigger ones, or they wind up being something I use without reservation.

It's just a lot of fun. And programmer testing often ISN'T. If you have powerful things to try, that bug that's driving you up the wall is less intimidating. And your testers and, down the line, your players will thank you for it. Spoilery examples for my IFComp 2012 game, Shuffling Around, follow.


Shuffling Around's mechanic is anagrams, and it has a hint device, which I'll address later. It has its own story. But one thing I didn't do, because I was so glad I had the device, was write a program to check it. This would've been tolerable, as well as a good investment at the start. It could've even helped me check my work later. Basically, you have two modes for your tagged gadget, certify and rectify. (See what I did there?) They aren't called that in release 1, but I think they work better.

CERTIFY finds all the letters that are correct. So STATIC to ATTICS would be -+----.
RECTIFY tells you the first and last letters. So STATIC to ATTICS would be RBGBBB, where blue=neutral, R=red=last letter of target (S in Static) and G=green=first letter of target (A in static).

This can be written programatically in PERL, but I passed at first. I figured I didn't have much to do, and it would be hard to make a mistake. I would be cautious enough. But every time I added in the data manually, it cost time and distracted me. Still, I was just pleased I'd thought of ANYTHING.

Then with a week left a new tester pointed out an obvious mistake in a short, and early, flip. I'd gotten all but 2 or 3 right, which is pretty good on a quiz, but it's not acceptable for a player who wants and needs a hint. This cost me more time and stress than I needed. Time I could've spent fixing bugs or making sure debug code didn't pop into the game, or even hammering a regression I caused after one tester made a good observation.

I learned my lesson a bit better, I thought, for the sequel, A Roiling Original, which had a more complex hint device and also used red-text clues (all letters wrong.) But I also neglected other diagnostics (like making sure anagrammed text actually anagrams) I didn't pursue aggressively for a while, because the mechanics had a new level of complexity. I really do think that adding these diagnostics, whether in-game or not, is a great break from the creative or programming grind. They turn up bugs, and you take them for granted, and it feels good.