How large is too large?

I played the zcode version and is large and difficult.

Gimme gimme gimme!

I love big games, but I’m not good at playing. If you want me to test yours I need two things: An understanding of the general outline, and ways to jump around.

I’m debating that with myself. The outline part is fine, but jumping around, as I know from past experience, can cause apparent bugs that are not real. This makes it harder to process bug reports. But yes, given the sheer size of the game, I will probably do that. Maybe not until the second round of testing. I’m hoping to have a couple of people tackle it head-on, exactly the way a player would encounter the released version, as their experience will give me important information.

Of course there is going to be a built-in hint system, so testers should be able to power-walk through the early stages in order to get to later ones.

A set of carefully designed testing commands that would allow a tester to jump forward to a specific spot in the game could be a good solution. These would not just be ‘goto’ and ‘purloin’ commands but something more comprehensive, so as to manage in the background anything that would have occurred prior to that point in the game.

I’m still weeks away from having anything ready to test, though. I’m close to finishing all of the basic puzzle and object code, but I still have to work on the hints, the NPC conversations, and the scenery in various locations. Plus conducting my own alpha-testing of all sorts of things.

Yes, that’s a big concern–I have a problem where I try to allow for warp commands, and I forget to flip one truth state.

I don’t think “test x with n/e/take all/etc” syntax is allowed in release mode, but I think one viable option is just to have a warp command that has the player complete, say, 20 of the 40 total point-scoring activities e.g.

understand "warp [number]" as warping.

carry out warping:
    repeat through table of walkthrough actions:
        increment count;
        try the this-act entry;
        if count > number understood, break;

table of walkthrough actions
this-act entry
going east
going north
examining the player
going east

This is obviously rickety as-is, as it can only be used at the start of the game, but you could also define ways to say, okay, we start at warp entry x, or we could have an index entry (e.g. 1, 2, 3 for big points in the story) so you could say “warpto (#)” and you’d go through the table until the index entry was that number. And stuff like going east/north/etc that doesn’t gain points would have a blank entry. Of course, you could have a “description” entry that tells the player the puzzles they passed by running this script. They may have to push the space bar a bunch of times to pass up text, but spoilers can be avoided with clear the screen;

I’ve put this in a module with, say “Very Vile Fairy File Beta.i7x” so it will be available for beta testers but gone in release. (you can write a pre-release script to make sure such a line is commented out in

ETA: this isn’t perfect, though. If a “before” or “after” rule would have been triggered by playing with a parser, it will be ignored. So all critical rules would have to go in “check” or “report” rulebooks.

It’s not comprehensive, but I do have a little hack in my debug code for handling this in my current WIP. When the game starts, it looks to see where the PC first starts and equips them with goodies they would normally have to scrounge for in the earlier stages of the game.

In adv3Lite, I use the Scene class to do this in a declarative way. Something like this:

#ifdef __DEBUG

  startsWhen = gPlayerChar.isIn(levelThreeRegion)

  whenStarting() {


Then, if the player jumps or starts in that section of the map, they’re instantly rewarded with those items. Other state switches (unlocked doors, etc.) can also be set.

You can use “Release for testing” in the OSX IDE, I don’t know for the others.

No need for a script, Inform can do it for you:

Section 1 - Testing extension - Not for release

Include Very Vile Fairy File Beta by XYZ.

Despite the name, it still included if you use “Release for testing”.

1 Like

Good point–I have to admit, I’m not sure what “release for testing” should do, so I avoided it. “Release for Testing” in the Windows IDE doesn’t seem to be documented. Searching for the phrase in the Windows docs turns up nothing related to it, and neither does Help:Windows Inform notes. So I’m not sure who would be responsible for implementing it.

I should have clarified, though, that I like to have 3 levels of release. I don’t know if this is still doable with Release For Testing, which seems to allow PURLOIN, etc. But I want to have

  1. the binary with PURLOIN, etc. that I use for running Zarf’s scripts. Sometimes this is just to save time e.g. PURLOIN X, GONEAR Y, (test a case), UNDO * 3. I’d rather not give the tester the opportunity to do odd stuff with PURLOIN, but I’m glad to give them specific cheats. It also does stuff like allow you to skip “wait for any key” and questions asked at the start, e.g. using a screen reader.
  2. a beta with testing commands I don’t want to expose to the player. This includes warps to certain parts of the game. I’m open to beta testers saying “Wait! Did you check this case?” But I also want to make sure that any cases checked are realistic. Also, I want to avoid printing some debug testing that’s helpful to me as the player e.g. every turn: if debug-state is true, say "[my-hinted-item]" is currently being hinted."; Another case for having specific test commands would be, say, to recharge/restore a one-time-use hint item. We wouldn’t want to PURLOIN everything, but a conscientious tester might say “Hey! I bet this hint item might go haywire in this complex world state.” I also think having a narrower set of test commands or switches to flip would help the tester focus on stuff to beat up and not feel they have to play mad-scientist or be overwhelmed by being able to do everything. Those who really want to adventure will say “Could you add a command to toggle/drop/pick up item X?” And others may say, okay, I’ll lean heavily on testing command Z and see what I can find.
  3. the actual release version. This is generally used to make sure no text leaks out. I go through programmer testing with it, but I know a testers is very likely to point out something I missed/took for granted.

And in general, I think having an extra level of testing (programmer, beta with minor testing commands, release-only) is a good idea for large games – having scriptable testing helps, big time, and you want to give your testers flexibility and ability to hit things quickly, but allowing PURLOIN etc. seems to open up too many temptations.

1 Like

“Release for Testing” is documented at 24.5. Adding new testing verbs and Release for Testing :

Just occasionally, we might also want to build a version of a story that will allow beta-testers access to the debugging commands. This is especially relevant for long stories: if we’re testing a story with a lot of playtime and the testers have already thoroughly reviewed the first portion of the story, we might want to let them have access to testing commands that fast-forward to later sections.

To do this, we can use the “Release for Testing” feature. Release for testing builds a version of the story that does include testing commands and any sections labeled “Not for release”.

But as you say, it allows PURLOIN etc., so if you want more fine-grained control for the reasons you mentioned, then it’s probably not exactly the right tool.

1 Like

Thanks for nailing things down for me! This part of the docs wasn’t in 6G, and I thought I checked 6L. I now remember hacking through Tests.i6t to see what testing commands there were besides PURLOIN. But I see they are now covered well in Chapter 24.

The basic native testing commands cover a whole lot. So I recommend to anyone making a large game to get acquainted with them, so the game doesn’t feel too large to program.

I found a good deal of mental fatigue thinking “boy, if this is hard for me to keep track of, how hard must it be for the player?”

This sort of relates to the original “how large is too large” question in that I sort of worried my own game had gotten too large, and having good testing tools (native, or ones I built) alleviated these worries a lot.

1 Like

While I’m not doing one for a competition, my current size is about 194 rooms - and I’ve tried to make them unique rather than have 50 near-identical rooms. (While there is a maze, it’s only one room). I’ve tried to section off areas so that players can comfortably explore around and (hopefully) not be overwhelmed, but I am a little worried it might still be a bit much. I’m also trying to make it a little more open-ended.


My game is of a similar size if not a little bigger, so you’ve at least got me for an audience… I’m more of a settle in-for-the-long-haul player than the one-or-two-hour-experience kind…