I want to build a very forgiving game, where the player never gets killed. If a mistake is fatal, the game throws him back to a previous state.
And I don’t know how to do this.
It sounds similar to saving/restoring, but without the player commanding it or knowing about it.
My guess is that a saved game is a large database file that determines every object’s current state/location, every value’s state, etc. Perhaps it is an overkill for what I want to build.
Would you advise me to manually create “storing” rules for the objects that concern me, eg. a phrase that stores objects’ info -location, values, etc- in a table, and then restore them from that table? Or is there another way of jumping back in time?
Saving every-turn data isn’t a big deal anymore, given storage is fairly cheap. This was one of the selling points of fyrevm-web, but with code-wrangling, it’s possible in Inform-glulx games too.
I created checkpoints in The Baker of Shireton using Emily Short’s “Recorded Endings” extension.
It saves data to an external file. Any time the player did something significant that I wanted to make permanent, I recorded it as an ending, then when the game begins, you can check for endings and rearrange the data as necessary.
For example, if the player acquires the sword, I stored “gotsword” as a recorded ending (without actually ending the game.) When the player starts again, it checks if “gotsword” is a recorded ending, and if so, puts the sword in the player’s inventory so they don’t have to do it again.
You might not be able to make it granular enough for every single moment in a long game, but you can at least save the player from replaying large portions when they start over. The best way to do this would be to bottleneck the game after significant events. You could even ask the player “Do you want to start at the castle?” if they’ve been there.
The only limitation is if the game is being played in a browser with security settings to prevent a web page from writing a file.
Yes, this is an interesting approach and not covered by the cruelty scale, unless you categorise auto undie from death as “not dying”, and therefore merciful.
Some benefits of this approach are that it underpins player agency and a feeling of behavioural freedom - especially in parser games.
You’re Sherlock Holmes and you’ve got a gun. Here’s Watson. “Shoot Watson in the head”. I’m always disappointed by responses like “you don’t want to do that”. Yes, yes i do, i do.
The scope for comedy within an otherwise serious game is much appreciated. You shoot Watson. Inspector Lestrade busts in and arrests you. You’re sent down for murder and rot in the cells underneath Scotland Yard, trading cigarettes and insults with your former criminal adversaries. You have failed!!
But then it unwinds back, like waking from a bad dream.
There are a few ways, in fact! One is Autosave. This lets you save and restore without the user being aware of it, but you have to specifically save the game.
Here’s an alternate solution! Include this snippet of code in your game:
To immediately undo the last move: (- VM_Undo(); -).
Now “immediately undo the last move” will have the same effect as the player typing >UNDO. So you could call it in a “when play ends” rule, for instance, and it’ll undo after any “end the story”.
