debugging/toggling truth states and numbers

In a game I’m writing there are currently 3 critical flags that change the story line. I’d like to be able to unit-test them without actually going through the game, to give a semblance of focus.

Here is my code right now. I know there are debug modules for objects, but I’m worried I’ve missed one that allows the player to actually tinker with numerical values/truth states. I also suspect that my code below is awkward because I am missing something fundamental–among other things. (Yes, arrays would work better for the flags, but I’ll tackle that on my own.)

I know Inform 6 has #ifdef DEBUG/#endif, but that doesn’t work in I7, and obviously it’d be easy to forget to reset the debug-flag when I release things.

What modules/definitions/ideas am I missing that I should be using? Thanks for any help that can be given, specific or general, and hope the code chunk isn’t too long…I only included 2 flags to show the pattern.

Anything you put in a section titled “Not For Release” will, well, not be released (so it will exist in the version you play in the IDE, but not in anything you export to send to testers/players). See section 2.9, “Material not for release,” in the documentation for an example.

Which means you can do[code]

Section 1 - normal

debug-flag is a truth state that varies. debug-flag is usually false. [release]

Section 2 - not for release

debug-flag is true.

Section 3 - foo
The “is usually” sets up a default, while the sometimes-included “is true” overrides.

Thanks very much, Ron. I have to admit that after my first couple of days with Inform 7, I don’t know if I looked at chapter 2 of the docs ever again. I sort of dismissed it as introductory fluff.

I think I’ll go back and reread it now, as I probably missed some other big-picture stuff that might be more useful with experience, stuff programming intuition says should be in a robust programming language but I can’t find off the bat.

If you’re interested in doing unit-testing, may I humbly suggest that you try out my Automated Testing extension, available from: … index.html

Note that this extension (ironically) hasn’t received a lot of user-testing out in the real world, so I do have a bit of an ulterior motive here. I’d very much appreciate any feedback that you (or anyone else) might have on it.


Wow! That looks really powerful and simple, just tinkering for an hour. Being able to test with regular expressions is really handy. I was thinking of just creating a transcript and weeding out key words in the right place, but this is easier.

It’s also really cool that I can put variables in a command, or in expected text.

My immediate impression of stuff to add–whether in the docs or in the program–would be a way to weed out certain responses. For instance, I have a debug command that goes to a specific location, then tries each possible basic direction, then returns to that location. Its purpose is to make sure there are no generic “You can’t go that way.” messages.

One way to do this would be a test with

Table of steps for verify no generic directions
order command response
1 “everydir” “.You can’t go that way.

With the stipulation that you don’t WANT a test to pass. But this gets into thinking yes means no and no means yes and eventually fooling myself.

Is there any way to add some variable–flags, text, etc. in a fourth column of the table? It might be useful to have grep-style flags like -i (case insensitive,) -v (don’t search for something) or such–those are the two big ones I use.

Or am I missing something relatively big-picture with regular expressions and/or your extension that could do this? That might be something to put as an advanced example. Obviously you don’t want to reinvent the wheel in that case, since there are plenty of RegEx tutorials out there. But knowing/seeing what to do could help people get their feet wet. The examples you already have certainly worked for me.

I also have some (even more) fiddly questions better dealt with outside of the forum. But in the big picture, I’m definitely very interested, very quickly, and this has immediate applications.

Thanks for your comments – I’m glad you’re finding it useful.

Hmmmm. I can think of a couple of different ways to do that, but also some reasons not to. I appreciate the suggestion, in any case, even if I don’t implement it.

I think what I might do is make it clearer in the documentation where to find the section on regular expressions in the Writing with Inform manual. If I start providing examples of, for example, setting case insensitivity, pretty soon I’ll have that whole chapter replicated.

I’ll start another thread here for chatter about this extension, as it’s valuable stuff that I don’t want to lose.


Good idea with the new thread. I’ll go there now, since this one’s probably served its purpose from my original question and well beyond.

But this is as good a place as any to mention I have learned something unexpected from a lot of other question-threads on this sub-board, even if I don’t post much. Hooray for people helping people, and stuff!