The tools given to authors for debugging Inform 7 code is rather limited right now. Pinpointing a bug that doesn't generate a compiler or run-time error usually requires a big mess of conditionals and 'say' phrases being thrown into what might otherwise be perfectly sound code to try and pinpoint the bug from it's side effects, and then, when the bug is resolved, those phrases need to be removed. This is hazardous and unnecessary, an avenue for introducing new bugs because you deleted one too many phrases.

I suggest adding formal 'assertion testing' and 'trace' features to Inform 7.

An assertion would basically test the game's logic, checking to ensure the result of a truth statement evaluates true or throws an error otherwise.

----
To foo (bar - an object):
Assert that bar is not nothing and bar is a thing;
if bar is lit:
now the player carries bar.
----

If the above assertion failed, it might produce an error like "The assertion 'bar is not nothing and bar is a thing' was false at line 2 of 'example.ni'." The IDE could use the error details to highlight the assertion that failed.

A trace would replace the usage of 'say' in tracking the program's execution.

----
Dominoes Console is a debug console. It is enabled.

To simulate the dominoes:
trace "simulating step [simulation step count]" to the Dominoes Console;
trace "all dominoes have fallen" to the Dominoes Console when dominoes fallen is total dominoes.
----

In this mockup implementation, multiple traces are grouped together by their debug console. The console might be presented by the IDE to the author as a seperate text area from the game's output during execution. To keep the code clear and readable, all the lines containing traces corresponding to a disabled debug console could be hidden. This is the reason behind the second version of the trace: if a trace used an 'if' statement to decide if it should be evaluated, it could produce awkward looking code where an 'if' statement has no apparent body.

Naturally, these debug functions should work similarly to headings marked 'Not for Release' and disappear in the release build of the game to ensure the release build is not bogged down by debug code.

A long-running complaint about IF systems is that every new release of a game breaks compatibility with old save files. This is a manageable nuisance with old-fashioned native interpreters -- you can keep your old game files, or delay upgrading until a convenient time. A web interpreter gives the player no control: the author installs an upgraded release, and players find that their save files have effectively disappeared.

True backwards compatibility of save files is a very difficult problem (which is why this is a *long-running* complaint). It requires much more game file introspection than Zcode/Glulx currently provide, and that only hands a hellish data management problem to the game author. So I will not address it here.

A possible end-run around the abyss: allow a Blorb archive to contain *both* the old release and the new release of the game file. This allows the player to keep using old save files, albeit without the benefit of the game's bug fixes.

There are three parts to this plan:

- Add a new (optional) chunk usage identifier to Blorb, for old game files. The usage ID would be 'Exed', for the past tense of 'Exec' (and a dim L'Engle pun). The format is exactly the same as 'Exec'. There can be multiple 'Exed' chunks, for multiple old releases; their order and index number doesn't matter.

(This could conflict with the hypothetical use of multiple 'Exec' chunks for a single game. But I don't believe anybody's using that option.)

- Add an I7 statement, such as the following

Release along with previous release "old.blorb".
Release along with previous releases "old.blorb", "older.blorb", and "oldest.z5".

The named files would have to be provided in the Materials folder. The I7 toolchain would then find these files, extract the 'Exec' chunks (if necessary), and pack them in as 'Exed' chunks.

- To support this feature, an interpreter would notice the 'Exed' chunks. When the player types "restore", the interpreter would offer a list of save files that match *any* of the available game files ('Exec' and 'Exed'). (Quetzal game-file fingerprints are sufficient for this task.) Obsolete (Exed-matching) game files would be listed with a footnote: "This save file is for an old release of the game. You may encounter bugs that are fixed in the current release." If the player selects one anyway, the interpreter switches to the matching obsolete game file to play.

Also, when the player types "restart", the interpreter would jump to the current (Exec) game file, if an older one was in play.

I-crossing details:

- In Glulx, when the interpreter jumps between game file releases, it should close all Glk windows and streams and so on. (Normally the interpreter does *not* close these at restore/restart time.) This may cause some ugly display-flicker, but better to be safe about window and stream assumptions. (A hard enough problem within a single release.)

- We're packaging the old game file, but *not* old suites of sounds and images. So the author will have to handle that aspect of backwards compatibility. Simple rule: don't rearrange or delete sound and image resources, if you plan to use this system. Only add new ones.

- Using this system means that your blorb file will grow with every release. I think this is a cheap price, even for the half-assed solution I am proposing. Disk space is cheap even on mobile devices. (Memory is not, but in this system, the interpreter only needs to keep one copy of the game file in memory at a time.)

The word "ever" seems to be implied in the syntax for looking backward. Although the semantics of "has been x" and "has ever been x" are the same, if you consider having "for x turns" added to the condition, then the use of "ever" would provide a useful semantic difference. "Ever" releases the end point of the counted consecutive turns so that it need not be the current turn. "Has been x for y turns" can go away. "Has ever been x for y turns" can not.

Example:
Instead of drinking the milk:
if the milk has ever been unrefrigerated for 60 turns, say "Pfffft!!!!".

Re-refrigerating the milk doesn't help. It's already too late.

This is a way of looking into the past that is not currently provided, yet it feels quite natural and intuitive.

I'm not sure if to implement this you'd have to steal a bit from the trips or consecutives counter, repurpose the trips counter, or use an additional whole 15-bit state tracker, but I think the mechanics might not be too tough.

As a final note: this thinking also suggests that the true syntax of the non-counted condition should be "has ever been x". Indeed, the documentation uses the word "ever" in describing the effect of the "has been x" syntax. "Has been x" thus becomes an acceptable abbreviation of "has ever been x".

There are several common mistake patterns for erroneous Glk calls:

- Calling a window function (e.g. glk_window_clear) with a window argument of zero, or a window argument that doesn't refer to a real window

- Ditto for stream and sound-channel function.

- Printing to a text window which is awaiting line input.

These are fatal errors on some Glk libraries, but are ignored on others. (Or they're ignored by default, with a "strict mode" preference.) This leads authors into a trap, like the "vile zero" situation on the Z-machine a decade ago.

To avoid this, the IDE interpreter's Glk library should be strict about these errors, and always bring them to the author's notice.