[Announce] New Inform 7 extension "Permadeath"
The Inform 7 site now hosts a new extension of mine, Permadeath. This extension implements rogue-like saving. What does that mean? It means that (1) the player can save the game whenever he or she wants, but saving immediately results in quitting the game; (2) every saved game can only be restored once; and (3) when the player dies, his previous save game becomes unusable. In other words, you can only save to "pause" and then "resume" the game, but you can never use it to undo something that has happened. This makes for very tense games, as (to name one obvious example from which the extension gets its name) death is final.
Obviously, this extension is not to be used lightly. Think long and hard whether your game will become more fun by adding this feature, or whether it will only become more frustrating.
The extension also allows the author to switch at will between "normal" and "permadeath" saves. As a somewhat classic example, you can have a town where the player can make normal saves, which can be restored without limit and independent of whatever happens to the character afterwards; and a dungeon where you can only make "permadeath" saves which will become unusable after restoring or the death of the character. This allows you to fine-tune the balance between good tension and bad frustration.
Because it uses an external file to write down data about the save games, this extension is Glulx only.
Obviously, this extension is not to be used lightly. Think long and hard whether your game will become more fun by adding this feature, or whether it will only become more frustrating.
The extension also allows the author to switch at will between "normal" and "permadeath" saves. As a somewhat classic example, you can have a town where the player can make normal saves, which can be restored without limit and independent of whatever happens to the character afterwards; and a dungeon where you can only make "permadeath" saves which will become unusable after restoring or the death of the character. This allows you to fine-tune the balance between good tension and bad frustration.
Because it uses an external file to write down data about the save games, this extension is Glulx only.
On a brief scan of the documentation, it seems to make the old save unusable when you save (or die), not when you restart, correct? If so, hooray. nethack's "Delete the save on startup, and if the game crashes tough luck" approach seems gratuitous to me -- though it looks like they may have finally got around to bundling the save recovery program with Mac ports, and even fixing the non-terminal ports so they don't crash all the time, which takes the sting out of it. Anyway, allowing save files to be preserved in case of crashes seems like it'd save a lot of trouble.
ReplyDeleteMatt, in fact the old save game is made unusable upon restoring it. This does mean that the system is vulnerable to crashes, as you point out.
ReplyDeleteThe alternative, although not hard to implement, doesn't strike me as satisfactory. It would make everything except death reversible, since you could simply close your interpreter without saving/quitting. (This would reward a play style were you close your interpreter whenever things seem to be going wrong; not really something you want to reward.) Closing the interpreter is not, as far as I am aware, reported back to the Glulx-game running in the virtual machine.
This disconnect between the program and the game running in the virtual machine makes a truly satisfactory solution to the problem impossible.
:-(
ReplyDeleteCan't the existing extension be gamed anyway, by keeping a backup copy of whatever file the game creates, and then using it to overwrite the existing file after death or other unfavorable outcome? This is pretty trivial in nethack, at least on a copy natively running on a computer, and in fact I did this for a while because the port I use does in fact crash often. So the permadeath implementation effectively forced me to hack my game in a way that perfectly simulates cheating, and only my IRON WILL prevented me from actually cheating by restoring those save files after I died. (Well, that and the fact that when I died it was almost invariably before I'd actually got around to backing up the file.)
I understand your concern that "delete-on-save/quit" is vulnerable to easy exploitation in a way that "delete-on-restore" isn't, but it seems to me that you have to trust the player to not exploit the system in some way; especially since the existing system is probably vulnerable to (preordained) cheating. I'd rather use a system that lets cheaters get away with something than one that punishes non-cheaters for bugs, especially when those bugs can be out of the author's control. It depends on relative risk, though.
Anyway! This is obnoxious nitpicking of a very cool extension, and one that everyone is free not to use if they don't want to. Mostly I just want to vent about the effects of the nethack system -- since I stopped backing up files I lost one character two levels from victory and one wizard who was just DESTROYING arch-liches. Very sad.
Here's the deal: when I get around to making a version 2, I will implement a use option that allows the author to choose between these two modes of saving. :)
ReplyDeleteWell that seems like an excellent solution. (And I know that if I really care about this sort of thing I should do it myself.)
ReplyDeleteCool. I was just musing about what something like this would require. An interesting way to up the difficulty.
ReplyDeleteI think you'd have to be very confident in your code to use Matt's version; while I've had good luck with interpreters not crashing themselves, all it takes is one miscalled value to bring the whole thing crashing down.
Wait, my version is supposed to be the one that can recover from interpreter crashes. Am I missing a complication that this raises? (This is a sincere question -- I don't know anything about file handling, really.)
ReplyDeleteMatt - No, that was just a typo. Sorry. You're right.
ReplyDelete