As for the other issue of a keeping variables set correctly, even if those variables didn't exist when you played the game the first time around, there is no easy answer.
1st simple solution: Don't have variables. Seriously - write a kinetic novel with zero choices. Never have to worry about this shit.
2nd simple solution: Tell the players to suck it up buttercup - your save is incompatible with the current release.
Okay, okay... I'm being deliberately flippant here. No user really wants to hear they've got to play the game again from scratch because the dev decided to go rewrite chapter 2 while releasing chapter 18. But maybe that's what it takes.
Failing that... you're into complex and messy solutions using
label after_load:. "Complex", not least because
after_load: is invoked every time you load a save game. So whatever solution you end up with has to work not just the first time the player loads their saved game after a major revision of the game... but also all those other times too.
There are no good choices here... just least bad ones.
One solution I tried was based roughly on this:
Python:
default my_new_variable = None
# blah, blah... lots of code
label after_load:
if my_new_variable == None:
my_new_variable = True # or 6 or whatever you want the value to be.
return
# blah, blah, more code
When I absolutely had to add in a variable after the fact, I made figuring out it hadn't been set yet easy by using a value of
None... and if it wasn't set, I would pick a value I would expect "the majority" of players to have picked. To those players who wanted to remain a virgin by the end of the game... well, fuck 'em if they can't take a joke.
Which isn't to say you can't be cleverer about "upgrading" your list of variables after some major upheaval.
You can check other variables from the players "other" decisions and try to do your best to guess what "that sort of player" would have picked.
You can check if certain images have been seen by the player... or certain music has been played (same way some unlock-able galleries are controlled). This isn't ideal, because it's a global check against all previous play sessions. If the player has picked BOTH routes through a section of your game before - you're back to picking the route "most" players would have picked.
Another solution I tried at one point was to keep track of the version of the game when the save was done.
I had code that looked something like this:
Python:
default savefile_version = "0.0"
default grabbed_her_boob = False
label start:
$ savefile_version = config.version # set as soon as the player starts.
# blah, blah. Lots of code.
label after_load:
if config.version == savefile_version: # no point upgrading variables if we're already on the right release.
return
if savefile_version == "0.1":
call upgrade_from_01_to_02
if savefile_version == "0.2":
call upgrade_from_02_to_03
# you get the idea.
$ savefile_version = config.version # now we've finished the upgrades... let's make sure everything matches.
# in fairness, it should already be the correct version number.
# This is just me removing all doubt.
return
label upgrade_from_01_to_02:
# actually... do nothing this time. There weren't any variable changes in 0.1 -> 0.2.
# but we still need to temporarily set the savefile_version to 0.2 so upgrades can be done from 0.1 -> 0.2 -> 0.3 -> 0.4, etc.
# not moving the savefile_version forward by one release might mean a needed variable upgrade being missed because
# the player just downloaded version 0.9, but hasn't played since 0.1 or some other random shit like that.
$ savefile_version = "0.2"
return
label upgrade_from_02_to_03:
$ grabbed_her_boob = True
$ savefile_version = "0.3"
return
# etc, etc, etc.
If you do try something like this... be careful about maintaining an upgrade path for each and every release. Even fix releases like "0.6a" or "0.6.1" (if you use that naming style).
Alternatively, don't use
config.version and instead have something like:
Python:
default savefile_version = "0.0" # "default" variables are stored in save files.
default grabbed_her_boob = False
define currentsave_version = "0.8" # "defined" variables aren't stored in save files. They are effectively constants for runtime only.
# etc
This would allow you to not have to do the whole "0.6a" thing. Instead maintaining a sort of meta savefile version number that doesn't change as often as the main game versioning. Maybe you only change this string when you know you're introducing new variables that might break people saved games.
Again... none of this is ideal. It's just you need to do something - and these are "some" of the choices you could go with.
Don't like it? Fine... do something else... or do nothing.
Simple programming solutions tend to only work for simple programming problems. Save compatibility isn't simple. It isn't massively complex either. It just requires you understand WHY things might be a problem in the future.
