(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!
Comments
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.
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.