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.)

I6 offers the debugging commands "record on" to start recording only player commands to an external file, "record off" to negate "record on", and "replay" to play back a series of commands saved to an external file.

While this is very similar in functionality to the built-in (and generally superior) skein, and the skein offers many features that "replay" did not, this feature is missed when beta-testing a work.

Since saved games are not transferable between compilations of a work, and since interpreters do not provide a skein like the IDE does, playtesters must retype all commands to get back to a certain point. For a longer work, this can be tiresome.

I am proposing extending the idea mentioned here:

https://inform7.uservoice.com/forums/57320-general/suggestions/751240--adaptive-text-first-time-only

...so that instead of displaying text the first time only (which was implemented) OR displaying text NOT the first time (not implemented), we can choose either/or/both. Example (at game start):

Grubby Cell
You wake up on the floor of a dirty prison cell.

> look
Grubby Cell
You are standing in a dirty prison cell.

...the code for which could be something along the lines of:

Grubby Cell is a room. "You [first time]wake up on the floor of[subsequently]are standing in[end] a dirty prison cell."

Using [first time]...[subsequently]...[end] construction would I think be a useful addition.

Having auto-save enabled all the time is dangerous because temporary source changes designed for testing can become accidentally permanent. Also, using Save As to try to keep different revisions or backups is not very graceful because it save it as an entirely new project, and not just a revision of the same project.

I've almost lost an entire project when my computer lost power. The file was still there, and was the right size, but it was entirely blank. I suspect this is because Inform keeps the file permanently open and only writes to it after closing the program or during an auto-save.

Can we at least have an auto-backup feature where one former revision is stored as a .bak file? This would be some kind of "insurance" cache against faulty saves, power loss, or losing your undo history to fix unintended mistakes.

Currently it's tricky/annoying writing new accessibility rules because one has to separately check the requirements on noun and second noun, as shown in the "Electrified" example:

if the action requires a touchable noun and the noun is electrified, say "You fear touching [the noun]." instead;
if the action requires a touchable second noun and the second noun is electrified, say "You fear touching [the second noun]." instead.

But internally I6 does have the information about which object-that-needs-touching we're looking at. We just need to expose it to I7, with something like

To decide what object is the touching goal: (or some much better term)
(- (untouchable_object) -).

Make the template layer available for browsing from within the IDE. Minimally, this might mean making the Reserved extensions folder available from within the Extensions menu (probably with a different name, e.g. Templates). More useful would be an Index pane or special documentation page listing the templates and the order in which they are compiled (if this is straightforward). Links from this index could take us to the i6t file and to each template file's documentation (i.e. the docs currently available only in the Appendix A and B pdfs). If the goal is to hide the template layer from most users, perhaps an option in the preferences would be appropriate?

Currently the only way to define a kind of action is to give an example of it; e.g. "Looking is acting fast."

It would be convenient to allow a kind of action to be defined directly, by "Acting fast is a kind of action." This would be especially convenient for extensions that define a kind that may or may not be populated by the authors that use it--for instance, an extension might want to write rules for "acting fast" in case the author wanted to define any actions as acting fast, without forcing any particular action to count as acting fast.

As the author of a number of multimedia extensions for I7, I've heard from a couple of users asking whether there is a briefer way to assign figure names to image files. As I'm working on a WIP that currently has well more than 100 defined figures, I understand why they'd want that. The standard syntax works well for a handful of figures, but there is a lot of extraneous typing when the number of figures goes beyond that. Would it be possible to allow figures (and perhaps sounds) to be defined using special-purpose tables? A simple Table of Figures or Table of Sound Files, with just 2 columns to fill in (figure/sound name and file reference), would be efficient and simple to fill in. A dollop of whipped cream on top of this would be if it were unnecessary to write "Figure of" for each figure-name, this instead being added by Inform when the table is processed.

The current game banner looks like

Release 1 / Serial number 160227 / Inform 7 build 6M62 (I6/v6.33 lib 6/12N) SD

The parenthesized part is boilerplate and conveys nothing useful even for deep I6-hacker types (like me).

- The I6 compiler is packaged with I7 and will not change, unless someone deliberately upgrades it in place -- which is likely to be a bug-fix update that does not change the "6.33" version label. (Yes, I've done this, and no, I didn't touch the label.)

- "6/12N" is hardcoded in the template layer and dates from the era when we thought that the I6 library would be updated in parallel with I7 as a separate project. That never happened, so the "6/12N" is a fossil.

If we knock that stuff out, we're left with

Release 1 / Serial number 160227 / Inform 7 build 6M62 SD

...which is all we want. (Release and SN belong to the game; "Inform 7" is the language; "6M62" is critical info for any I7 bug report; "SD" indicates that it's a debug build, which should always be visible.)