But autosave (do_vm_autosave) is disabled by default in Quixe. The code for Quixe has comments on how to enable it, but that seems geared towards people bootstrapping Quixe, or something. I’m not sure how to do those things for an Inform release.
Am I supposed to make a new copy of Quixe in the Templates directory, edit the (minified!) JS code to change the do_vm_autosave option, and then release along with the edited Quixe interpreter?
Or make a new website template that includes some JS code (what?) which changes that option? Can that be done after Quixe/GlkOte has been initialized?
Not quite! After making a copy of Quixe in the Templates directory, you can edit (manifest).txt’s [INTERPRETERHEAD] entry, adding the do_vm_autosave: true to game_options. No need to mess with the minified JS.
I’m not necessarily looking for something lower level, I just went looking for autosave functionality and google/intfic led me down the interpreter path. It hadn’t even occurred to me that this was something the game itself could handle! I’ll check it out, but unless I’m misunderstanding it seems to require a bunch of boilerplate code (maybe as easy as making sure to autosave every turn, but I’m not sure).
Just philosophically, I actually think it looks way more “lower level” to have the game handle autosaving, and having the interpreter handling it seems “higher level” to me. I might be misunderstanding, but the way I’m thinking of “autosaving” (especially for a web interpreter such as Quixe), it’s more like a “suspend/resume”, ie. close the interpreter/browser and open it later and be back where you were, so to me that intuitively felt like something the interpreter should handle and not the game (the same way the operating system handles suspend/resume on my PC on a high level, without each individual program having to handle it or even know about it happening). Having the game handle it is of course interpreter agnostic and probably more flexible, but I don’t think that’s actually what I want.
Sorry for the ramble! I’ll check out the extension, thanks.
I guess that means it can be enabled per-project easily too (I mean, without switching between Release with a "Quixe" interpreter and Release with a "Quixe copy with autosave enabled" interpreter) by adding something like this to the project’s website template’s play.html right after [INTERPRETERHEAD] appears:
That said, I guess I’ll just enable it in my regular Quixe interpreter template - I’m sure there’s a good reason it isn’t enabled by default, but I can’t envision a scenario where I wouldn’t want it enabled.
Well, I’m not sure if this is the original reason or not, but there’s one gotcha here: After restoring an autosave, the undo buffer is empty. That means that if the game is anything less than “Merciful” on your cruelty scale and the player dies or enters an unwinnable condition that is otherwise easily undone, but closes the tab in that state, they’ve lost the game.
Of course, without autosaving enabled, closing the tab would mean an instant restart anyway, but being accustomed to autosave, the player might not (indeed, would not be expected to) realize closing the tab would have any consequences. Enabling autosave creates the assumption that that won’t happen.
But, a new player won’t automatically be “accustomed” to autosave either. They won’t know if the game autosaves or not without experimentation unless the game informs them of the autosave feature, so I guess in that case it could just as well inform them that “undo” is unavailable after an autorestore…
I’m not sure if the Autosave extension preserves the undo buffer or not, but from a cursory glance it looks like it could be used to create a hard autosave before entering any unwinnable state, so maybe that’s a use case for the extension over interpreter autosaving.
While we’re (I’m) spitballing: You know how, when you’re entering some information in a form on a website, and you close the tab, a popup appears that tells you “Are you sure you want to leave this page? Changes you made might not be saved”? Maybe Quixe and Parchment could enable that popup (especially if autosave isn’t enabled and the game hasn’t literally been manually saved this turn, but maybe either way since the undo buffer is lost). Just a thought!
The extension functions just like typing SAVE; it just lets the game choose the filename instead of the player. Which means it doesn’t interact with the UNDO buffer at all; if you restore an autosave and then UNDO, you’ll jump back to before the restore, not before the save.
Aha! Like a checkpoint system. Thanks. I suppose it’s a bit confusing that both features are called “autosave”.
I guess the thing to do then is perhaps a combination: Enabling autosave in Quixe as a convenience for suspend/resume, and using the Autosave extension to create a checkpoint before entering an unwinnable state (or maybe autosave every turn, except after entering an unwinnable state).
When I say “lower level”, I mean closer to the hardware. The game runs in the interpreter, so the game is “higher level.” It doesn’t mean something is a better or worse idea. That’s not how I meant it, anyway
My “Story Mode V2” is V2 because I couldn’t guarantee that the undo stack would be available after an interpreter autorestore. That’s how I became familiar with the extension.
I plan to offer to restore an autosave on startup with the next game; I just ran out of time.
Of course, while Quixe autosave loses the undo buffer, it retains the scrollback buffer, which the Autosave extension doesn’t keep (obviously - it’s just a regular save). So with the Autosave extension, if the player has closed the tab in an otherwise unwinnable condition and then restore their autosave, they can undo, but they’d be doing so blindly (maybe not even considering that they can) unless they remembered everything that brought them there. More like a “try to undo until we’re somewhere else again” situation.
Maybe it’d be an idea to rephrase the “You can’t undo what hasn’t been done” message (maybe only if you’re not on turn 1) to say something like “Try to restore an earlier checkpoint instead”…
PS. Since I mentioned Parchment in the first post: I hope it gets back its autosave functionality soon, because I’m really liking everything else I’m seeing in newer (post-Inform release) versions of it!
That’s a good point about the scrollback buffer. I’ll have to think about that.
Though I don’t do unwinnable states, I have missable stuff… I’ve thought about having a number of checkpoint saves, and just telling the player the game saved (with a descriptive filename). It might make sense in a long game.
You could even check if the turn count is greater than zero (i.e. actions have been taken in the game), since that’s a normal variable preserved across restores, in order to give the most appropriate message.
