Trying out Gun Mute on itch (and a few other games) I get this error:
Error: dialog_storage_version is newer than this library supports
When I check the value in the console, it’s 2:
> localStorage.getItem('dialog_storage_version')
"2"
It doesn’t happen with a new Firefox profile, or on Chrome.
So this is bad: Itch just doesn’t have any subdomain isolation for different games. Everyone’s HTML games are run off html-classic.itch.zone, meaning they all share one single localStorage instance. So there can only ever be 5 million characters stored, and anyone’s game can touch any others’ data.
https://itch.io/t/3099694/notice-for-html-game-devs-upcoming-change-to-cdn-domain
I didn’t design Parchment for this situation, so any older Parchment games on Itch are at the mercy of other games not to upgrade their shared Dialog file system. But other Parchment games won’t know they’re breaking older games.
Itch just isn’t a good host for the long term hosting of HTML games.
Now moving forward, I can make Parchment isolate its storage for each storyfile. There will still be the same storage capacity limit as now, but at least they’d be insulated from other games corrupting their storage.
A question for everyone: should I do this just when Parchment is on Itch, or for any single game setup (whether that’s from the Inform 7 template, or the sitegen, etc)? Because some authors do like uploading their stories one at a time, like Ryan Veeder. Such an author could easily upload a new game using a newer Parchment, not realising it would break storage for all the older games. So I’m inclined to say it should be for all single game Parchment options.
Regarding the global limit for localStorage, does parchment compress save files for storage?
Looking at a random save files on my disk, I see a gzip compression ratio between 30% for Infocom games, and 60% for modern ones.
It doesn’t, yet. I’d been intending to add an IndexedDB implementation which would eliminate space concerns, but that’s a medium sized project and I haven’t got around to it yet. Adding compression would be very simple, so I’ll do it.
While this is not completely insulated, I have found that using IndexedDB for save/load game state is much less fragile. It is still affected by the domain name change but to a far lesser degree.
edit - I’m happy to share my IndexedDB strategy and JavaScript code. I don’t use public GitHub so it is not something I can post a URL for review.
Sigh. All this time, I thought the “html-classic.itch.zone” name implied they were transitioning to isolated subdomains.
The Glk era has used a general rule that save files should be namespaced so that each game is isolated, but datafiles and transcripts are not namespaced so that (e.g.) different games in a series could share a preference file if the author really wanted them to. Obviously, very few authors have used this capability. I haven’t tried to find examples; the number might be zero.
A more common case (but still rare) is for a game to write a preference or achievements file that is shared among different versions of the game. (Same IFID, different checksum.) I believe Counterfeit Monkey relies on this.
IndexedDB has an async API, which is a headache given the way IF VMs are usually implemented. (It basically forces you to redesign how every single part of the system works.) I know Dannii has worked on an AsyncGlk API, but I don’t know the status of it.
I’m pretty sure they mentioned plans to do that around the same time, but then they never did…
While this is a valid approach (though also not typically supported by Parchment either, as it also puts datafiles in separate folders), it’s a tangential from the issue of the whole file system itself being versioned. That’s the issue here. Game A uses file system version 1. Game B upgrades it to version 2, and then Game A can’t use the file system any more because it’s too old to read it.
My plan is to prefix all localStorage entries with a game-specific code (probably just the filename, or maybe the IFID?). So Parchment will know not to touch any files that don’t have its prefix.
The GlkApi part of AsyncGlk is semi-done. I haven’t put it through rigorous enough testing. But its AsyncDialog works great. This is why Parchment now only uses the Emglken VMs (no Quixe or ZVM), as it needs RemGlk-rs to talk to AsyncDialog.
So I’m ready to make an IndexedDB backend for Dialog, it’s just not the top of my priority list yet.
I suspect that the real source of the headache came from design choices made in the past that didn’t age very well.
That’s the same as what I said. :)
I’ve updated the Parchment site generator to support localStorage isolation. It also now compresses its files, so you can probably store about 20MB of savefiles now.
I’ll update the Inform 7 template ASAP too. Just got to incorporate the Itch iframe fix as well.