Support for bundling old game files into a Blorb archive
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.
- 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.)
Andrew Plotkin commented
The problem still exists, but nobody has agitated for this particular solution.
Dannii's alternate solution seems viable. (That is: have the interpreter quietly cache a copy of the game file, so that it's always available even if the user discards the original or replaces it with an update.) That does not require I7 or Blorb spec support.
Given that, we can leave this lying around in a "not currently planned" state.
Adminemshort (Admin, Inform 7) commented
What in fact is the status of this problem at the moment? Should we still be concerned about it?
The Parchment library branch now saves storyfiles to IndexedDB/localStorage, so updates won't affect your saves. Eventually (and before it gets merged to master) it will give you the option to check for updates, and if you have savefiles, will keep the old version too. By the time this gets implemented the problem may have disappeared :)