This is both a design question and a lazyweb question…
I am in the very earliest stages of design for a game, and I am considering how to incorporate meaningful danger. Basically, I want to be able to kill the player, and in ways that immediate undo won’t fix–I want the story to be able to spin out around the player’s death, in a kind of unhappy denemount. At the same time, I don’t want to frustrate the player too much, or require her to navigate the file system to save and restore (a tiresome task).
So, I’m considering a system whereby the game would autosave at key points, writing the file to the player’s hard drive silently (w/o prompting). In the event of player death, there would be an option to restore to the last checkpoint, alongside the normal restore option. There would also be an in-game command that would show all autosaved checkpoints and allow the player to restore to any of them.
My questions are:
Design: How does this sound? Am I missing anything that I should be thinking of?
Lazyweb: Is this (saving w/o a prompt) something that can be done in Glulx Inform? I believe it is, since other external files can be written that way, but am not positive.
Lazyweb: Assuming it works in Glulx Inform, would it work seamlessly with Quixe’s local storage file management? (Again, I assume that Quixe would work just fine, but I’m not sure.)
OK, I had more time than I thought I would for IF today, and I’ve answered Question 2 to my own satisfaction by referring to the template code and Doe’s infglk summary–it’s definitely doable. I think the answer to Question 3 should also be yes. I’m still open to comments on Question 1.
I like this idea – part of the reason zarfian-cruel games bother me is that I’m too lazy to mess around with saves (also, kind of frustrating to discover that I saved just after the game became unwinnable), so it’d be nice to have the game do it for me.
I would suggest that maybe the game should say “(autosaving)”, which spares the player worrying about whether they need to save or whether they’ve just passed a checkpoint. Also it lets you know that you’ve just made some progress. Also I suppose some folks might want control over where the files get written, though I don’t know how plausible that is.
Sounds great. The only thing I’d request is that you make it clear where the files are being written, and/or allow the possibility of wiping them at the end of the game. I play a fair amount on public computers, and it’s polite to keep those uncluttered.
Thanks for the responses; these are all good suggestions.
It isn’t possible to specify a save location for files that are saved w/o a file dialog; Glk doesn’t provide authors a way to access the player’s file system directly, which is probably the way it should be. Most interpreters thus choose to save the game file to the same directory that the game file is in–that seems sensible. Zoom saves to the user’s home folder in at least some situations (I haven’t bothered to work out the wherefore of it), and that makes considerably less sense to me.
I could offer a batch delete command (Glk does allow deletion of files it has an internal reference for)–it shouldn’t be very difficult, and it might be a nice thing for users on private as well a public machines, in fact.
OK, the main thing I’m concerned about now are the UI issues–how to reveal this capability to the player, how the player should interact with it, etc. Matt, your idea about making it obvious that an autosave has just occurred is excellent. I was originally thinking that the autosave feature would live alongside the library’s standard SAVE/RESTORE commands–which allow the player to choose the save location–but I think now that the best thing might just be to track all saved games in the way I’m tracking autosaves.
To get concrete: Typing SAVE or RESTORE would bring up a list of previously saved file names, not an OS file dialog. Both autosaved and manually saved games would appear in the list (possibly under different headings). When the player types RESTORE, the list is hyperlinked, and clicking on a file name restores the game. Typing SAVE, on the other hand, presents the list of previous saves and prompts the player to type the filename for the new saved game. (It might be better to use descriptions rather than filenames; that is, the filenames would be opaque to the player, and the descriptions would give some sense of where in the game the SAVE was made.)
Or maybe I could collapse SAVE/RESTORE into a single SAVED GAMES command: The player can click on a file name to restore, or type a new name to save…