More on Zarf's testing scripts: automating yes-no, and debugging

One problem with Zarf's scripts is that they hit a loop if there's a pause without a > for a cursor. This isn't unique to them. The IDE can trip up, too. Or maybe you just don't want to remember when to say yes or no.

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 substitutes

[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();
];

-)

Let'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.

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 release

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;

We're okay. The point is that, well, the programmer can toggle debug-state, but the user never can.

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;

 

Applying Zarf's automated testing scripts for Inform

Zarf's script is something I wish I'd tried much earlier. It had the added bonus of helping me learn python. As wonderful as the Inform IDE's "test" command is, it has limitations:

* no undo, which is sort of a problem if you get killed
* only one test run, with restarts being awkward
* can't check the content


I've been tinkering with this in my own games, but I think I've found a sub-script that's flexible enough to share with others. Eventually I'd like to do a whole post on using Zarf's framework from Windows, but for now, here's an idea of how to get things rolling if you have the framework up.

It's one of my favorite axes to grind, fixing the "You can't go that way" generic command. It's always meant restriction more than exploration to me, and changing it helps me develop my world, and I look for it in games I test. So here is my Python script:


https://github.com/andrewschultz/miscellany/blob/master/python/noway.py

This needs a text file in the same directory, labeled reg-noway.txt, to start. I ran this test on The Problems Compound, which had a test file at https://github.com/andrewschultz/the-problems-compound/blob/master/testing/reg-pc-noway.txt converted from https://github.com/andrewschultz/the-problems-compound/blob/master/testing/roomlist.txt.

You can see the general syntax--just list the name of the rooms, and adjust the binary names accordingly. Obviously, this can be more flexible as I build the script, but the main thing is that it will take a text file full of rooms and spit out a bunch of tests. I like this because insta-death movements are neutralized, and the "undo" means you can try a different direction right away.

I also disabled diagonal directions in some games, which means a lot fewer tests need to be run.


But this only does so much. You want a working walkthrough, with the right clues. So I spruced up https://github.com/andrewschultz/the-problems-compound/blob/master/testing/reg-pc-thru.txt and just made sure everything worked okay...and it turned out I had a few typos to look through.

Thus my fears of just doing-over work I already did, and not really getting anything, were misplaced. I even tuned up some double-text I should've seen before. I think just the process of sitting down and creating the test cases switches the focus from "I should've tested this, I think" to "I'm going to make sure I tested this." And if I cheated with some GOTO commands, well, I was able to cover the major walkthrough and check off on more than just "you won."

It's already helped me fix a few trivial annoying bugs, because I could just slip in a test and say "OK, does this work? I'd hate for this to break." And so I've gotten a lot of mileage. And I suspect it'll help you, too, but I'll write more later.

Still, the short take-away is: do it on a game you want to re-release. Or a WIP. It provides a lot of security that stuff you fixed will stay fixed. Or you'll know when it broke.