[Harlowe] Multiple saves in the same passage

Menti

(set: $test to 1)
[save 1]<1|
[save 2]<2|
(click: ?1)[(set: $test to it+1)(save-game: "slot 1")]
(click: ?2)[(set: $test to it+1)(save-game: "slot 2")]

Why doesn't this work? This code creates three save slots, but if you inspect localStorage you see that the updated variable is not saved. Each slot saves the state of the variable when the passage was first printed, not at the moment the save-game macro is run. So, apparently, Harlowe needs a passage change to store new values into a savegame.

Is there any way of making this kind of structure work? Allowing repeated saving without leaving the passage?

Thanks!

greyelf

Because a save contains the state of all known variables as they were just before the contents of the current passage was first processed, it also contains the name of the current passage.

When a save is loaded the story's variables are updated to be the same as those stored in the save and then the contents of the related passage is executed thus returning everything to exactly how it was when the save was created.

Menti

So, it's impossible that multiple saves in the same passage ever register different states. Unintuitive, but I guess there's some technical reason for it. Thanks.

TheMadExile

The reason that the pre-play state is saved is chiefly for consistency—specifically so that double-dipping does not occur, either with basic passage coding or when using interactive elements.

Basic passage coding. Upon loading a save, the passage that the player was on when they made the save is replayed. If a post-play state were saved instead of a pre-play state, then you run into the issue where even basic state modifications made by the passage are done twice—more, if the player saves & restores multiple times. You might think that this could be resolved by not allowing restored passages to modify state, however, there are some consistency issues with that and it doesn't address the other 800 lb. gorilla in the room.

Interactive elements. Twine story formats, generally, do not have a notion of state beyond the passage navigation level. Interactive elements, which allow players to modify the post-play state of a moment, throw post-play consistency straight out of the window. There's no way for the story format to know how much extra-passage-navigation interaction and state modification a player has already done, so you end up in a situation where, again, double dipping is an unfortunate likelihood.

PS: SugarCube's save subsystem does the same thing, BTW.