This is the sort of Inform 6 dabbling that I think helps you understand what's going on without getting overwhelmed. Below is code cut from the Trivial Niceties extension I use for testing.
volume yes-no substitutesLet's go over what this does. First, YesOrNo() is the standard Inform function for getting a yes or no from the player and moving on. If you want to see its details, it's in Parser.i6t in the reserved folder. It's worth a look to see that it's not terribly intimidating.
[this lets the programmer skip over yes/no decides]
debug-state is a truth state that varies.
to decide whether the player yes-consents:
(- YesOrNoExt(1) -).
to decide whether the player no-consents:
(- YesOrNoExt(0) -).
[ YesOrNoExt yn;
if ( (+ debug-state +) == 1)
{
return yn;
}
return YesOrNo();
];
-)
YesOrNo is pretty straightforward, and you can change the 'Please answer yes or no' message if you want. In fact, I did so in Threediopolis. You can search for EdBlab here in its source, though I may not detail it here. You can also see how to insert Inform 6 source into Inform 7 code. Not that I did a brilliant job of it, but yeah. It's not THAT esoteric if you want to change the default message or cut the player off after X tries.
So what do yes-consent and no-consent mean? Well, yes-consents goes to YesOrNoExt with a parameter of 1. If debug-state is on, it returns 1. If it isn't, it returns YesOrNo--which is 1 for yes and 0 for no.
I also defined a function called switch-consents which means the user can set a flag to decide whether or not to make yes or no the default. And I suppose the yes-no automation variable could be separated from debug-state.
Because I've actually defined debug-state earlier in the extension, and it's useful for other things, such as
to d (x - text):
if debug-state is true:
say "DEBUG: [x][line break]";
This is handy for, well, printing debug values when something doesn't quite work, or just making sure you have the right row in a table when the text is constantly changeing. It also is a great way to be sure that the end-player won't see these commands. After a while, typing d has become second nature for me when I've wanted to include diagnostic stuff. As long as we have this sort of section:
chapter debug setting - not for releaseWe're okay. The point is that, well, the programmer can toggle debug-state, but the user never can.
when play begins:
now debug-state is true;
dbting is an action out of world.
understand the command "dbt" as something new.
understand "dbt" as dbting.
carry out dbting:
now debug-state is whether or not debug-state is false;
say "Now debug-state is [debug-state].";
the rule succeeds;
This is only the surface of debugging, but I think it's a good start, and it helped me worry less about "what if it slips into the game text" or other issues. I've had it so long I've almost forgotten about it, but...a little I6 can go a long way, so it's good not to be scared, and to explore (if you haven't already) the Standard Rules.i7x file or even the Parser.i6t file.
I felt pretty clever making my first I6 edit to make Inform do what I wanted, and once you have a bit more you want to do, you will, too. Just remember to use the "include" syntax instead of editing the core files.
This can similarly be applied to skipping over narrative breaks, which I did so that the "test" commands wouldn't freeze. Emily Short's Basic Screen Effects needs to be included, but once you do, you can replace wait for any key with wait-key-d, or something even shorter, if you want.
include Basic Screen Effects by Emily Short
volume regression test - not for release
when play begins:
now debug-state is true;
volume regression test stubs
debug-state is a truth state that varies.
to say wait-key:
if debug-state is false:
wait for any key;
to wait-key-d:
if debug-state is false:
wait for any key;
