Cope better with story changes as save file is reused

[joethephish]

Two scenarios to consider:

• Developers iterating on a story during development of a game. As story changes, it's common to reuse a save file. Ideally ink should cope as well as possible with the changes, but obviously there's only so much you can do, and at some point you have to throw your save away and restart the story.
• Developers iterating on the story after the game is released. It's critical for ink to cope so players don't lose their save data, though it's also down to the developers to understand that the types of changes they're allowed to make are limited. Even if a change is made that's impossible to fully recover from, ink should do its best to cope though.

It would be good to enumerate some possible problems here, and have a think about what the best way to cope is:

• New variable added: X exists in new story, but doesn't exist in old save file. There should be a mechanism for realising that this is a possibility and instantiating new variables with the default value provided in the ink declaration.
• Variable removed: X exists in old save file, but doesn't exist in new story. Mostly harmless I think? The story state will contain extra data that it doesn't need, and will quietly accept new values to be pushed in from the game side where normally it would complain that the variable doesn't exist. (See Bug: Setting global variable from c# can set local variables unexpectedly #193)
• Existing written content removed: If the current saved path (or a choice's path) in the story no longer exists, we should probably try to play with the path to find the smallest tweak that makes it valid again. This can obviously create all sorts of other bugs, but hopefully it would be perceived as a less critical content error. (The internal hierarchical structure of the runtime content was designed to hopefully cope well with exactly this.)
• Knot/function parameters changed: Too many/too few parameters will exist on evaluation stack. Could probably just try to cope with this situation better - right now it simply crashes.
• Content added before a choice point: ...causes the address stored in the save file for the choice point to become invalid, causing a crash on load.

The main problem with trying to be forgiving in these scenarios is that it's hard to distinguish between data changing and there being a bug, either in the story or in the runtime flow.

[micabytes]

Although I'm not using the same JSON structure in jInk, this is a typical problem that I'm encountering since I tend to work with an early access type model, where I expand and improve extensively on the game after release.

I think the examples given above cover the main cases; though for both variables and content, there is also the even more subtle issue where things change; e.g., the variable still exists, but now it's a number instead of a string (with all the fun that brings in calculations) or content still exists, but has been moved into another place (though that may be more a jInk specific issue).

I'm not sure there is actually a really good solution to this for long-form stories.

For storylet-based games (e.g., stuff like 80 days, which is most of what I work with), I'm considering simply going for a version-handling approach. I.e., Any major changes to a storylet that can crash things bumps its version. When the player saves in mid-storylet, I also save the version of the storylet used. When the player loads up the game, I load the version of the save. IOW, I do not allow script changes to modify the state of an existing savegame, although subsequent run-throughs of the storylet will use the latest version.

[ringlas]

• Choice conditions changed: Without introducing new variables, i.e. checking against existing knot visit counts, when you add a new {condition} before a choice with already defined conditions it simply crashes.

[joethephish]

Thanks @ringlas! Have added the "Content added before a choice point" bullet to the main post.

[joethephish]

Some improvements in https://github.com/inkle/ink/commits/story-changes-recovery branch will be merged into master soon. It currently attempts to improve all points above except "Knot/function parameters changed", which is harder since we need more metadata about parameter counts to be stored in the story.

[Skrylar]

3 can be done by replacing the now-dead section with a diversion to where the player should be taken if they happened to be in this scene at the time; 4 probably similar, put in a default (inferred or explicit) and jump to the replacement.

[wilg]

What's the latest on this situation. This problem just occurred to me so I'm wondering what the state of the art is? Perhaps strategies used by shipped Inkle games have informed this?

[joningold]

"ink tries its very best". It can't even be 100% perfect -- if you load a save from game X into game Y it would always struggle - but the general strategy is that if it doesn't know the state of a [new] variable, it takes the default value, and if it can't find the current story location, it tries to find the closest matching point in the story. We've shipped a lot of games with this now and while it's not bullet-proof, but it's very, very strong.

…

Message ID: ***@***.***>