Inform question:
If a game is updated/recompiled, does that break compatibility with exiting old saves?
If so, what things do break it and what things do not?
For example, presumably simply changing some text won’t break (?), adding and object might (?), additional properties?
thanks.
Yup, any update breaks all saves. There might be clever ways around this – I think Ryan Veeder’s Fly Fishing did something on this front? But that’s way about my pay grade.
Thanks. I suspected this.
Trouble is, this needs to be addressed somehow. Otherwise, no existing game can ever be updated or bug fixed.
Ryan might provide additional detail if he’s inclined to, but he has a blog entry that explains how he handled auto-saving in a manner that avoids the game-version-dependency of the built-in save function.
I dunno, lots of I7 games see updates and bug fixes without anyone bringing out the torches and pitchforks, largely due to the existing norms about game structure, length, and development practices. Like, since most I7 games are relatively short and most of the time a player plays through them all at once, as part of a Comp or festival, with updates usually fixing bugs but not adding new content, it’s rarely the case that a player will make it halfway through a game, then stop, check online, grab the new version, then get frustrated their old saves don’t work. And since it’s usually really quick to replay an I7 game to get to where you left off, since you don’t need to read the text and implementing puzzle solutions is usually easy once you have the trick, even if you do need to start over it’s typically not too painful. In any case, this is where the norm of robust beta testing becomes especially important!
Of course, if you break those assumptions of how authors and players behave, as you say this limitation could start to have real teeth. In particular, it’d be hard to run an Early Access type development process for an I7 game, since folks would probably get frustrated at having to start from scratch every time they wanted to check out incrementally-updated content! In that case the table-based approach Jason mentions Ryan as having used starts to look pretty attractive.
Mike Russo is pretty much on the money about this. It’s been true since the first Z-machine games in 1980. So while you might want it to be addressed, in fact we’ve gone forty years without addressing it.
Ryan Veeder’s approach is possible. But it is hard to do it correctly, and the bigger your game, the harder it gets.
EDIT-ADD: For what it’s worth, I thought seriously about this when writing Hadean Lands. That game was meant for iOS App Store (and later Steam), where players are not familiar with IF and would be very surprised if their autosaves broke.
My conclusion was that I could use an external-file-table system like Ryan describes. But how likely was it to work right? My estimate was maybe 70%. That is, I gave myself at least a 30% chance of leaving in some bug that would corrupt people’s save files on each game upgrade cycle.
That wasn’t good enough. It was a better strategy to simply never update the game file (on any given platform). So that was my decision.
I totally agree with Mike regarding games for comps etc. People will play them and be done.
Then the point i was going to point out is exactly what you have described with Hadean Lands. Once you’re on a commercial platform, updates are expected. In fact you’re forced to update things from time to time anyhow. Either that or pull the product.
At some stage you’ll be facing that problem with HL. You’ll have to pull it or put out a big disclaimer regarding saves. This will be annoying because people’s devices like to update automatically, and they might still be playing.
A sure way to attract 1 stars.
I’m actually rather surprised Inform hasn’t already fixed this. OK, I’m guessing here, but something along the lines of:
Save out all tables and lists as separate chunks in a file, each with a header of info (and version). The compiler ought to have a way to put new stuff on the end of each table. Loading an old save would just load part of the new game data. Then pad with initial values for each table.
There would have to be a way to mark things as new. Perhaps something simple like prefix with a code, so that you could have new01_wibble, new01_wobble. Then if you had to make a further update, use new02_. Ugly, i know, but the idea would be to use it sparingly, and better than nothing.
No I won’t, because I will never update the game file.
I’m actually rather surprised Inform hasn’t already fixed this.
There is no good solution.
Ugly, i know, but the idea would be to use it sparingly, and better than nothing.
I promise you that any idea you can come up with is worse than nothing, because it will create a huge amount of extra work for the game author and also be an attractive nuisance for embarrassing “my save file is broken” bugs.
The current save system is limited but extremely reliable with zero effort. This turns out to be what IF needs.
Except a lot (most?) I7 game data isn’t in tables and lists by default. Sure, sending out the location of the player and every item in the game world wouldn’t be too bad, even accounting for stuff like containers and supporters. Add item properties, OK, even just with default properties that’s a fair bit of info that might not be needed, but in it goes. What about relations – how do you store those, and does it look different for one-sided and two-sided ones? Scenes seem easy but of course you can be in the middle of a couple of different ones at the same time; oh, and timed events mean you’ll need to keep track of the total turn count but also when whatever condition started the timed event fired, which could be anything.
And that’s the easy stuff. Do you have item descriptions where what the player sees uses the “one of… stopping” formulation? You need to track how many times the player’s examined the thing (and this could be scenery, not just movable, usable items).
Anyway it’s clearly not impossible since it’s been done at least once, but it seems really hard to me to use this approach in a way that’s sufficiently robust to work for even a medium-complexity game, and it’d probably require the author to construct their code in very specific ways to avoid breaking it. So I can see why there’s not currently a general-purpose solution out there even though it would be nice to have.
EDIT: I will say, @zarf’s “just don’t write code with bugs” approach seems to me by far the best.
Suppose I add an important new object to the game in an update. This object is in a place the player should have seen it and picked it up early on.
If a player loads an old file, where should the object be? Back in its initial position, since the player never moved it? In their inventory? What if it’s now needed to solve some puzzle that the player’s save is already past? How does Inform automatically decide where the object is supposed to go?
Modern games (not IF) tend to get around this by only saving specific bits of state, not the entire state of the world and all the objects in it. But in IF, the convention is that the game world will be exactly as you left it; objects won’t teleport back to their starting positions every time you save.
It’s entirely possible to implement this strategy in Inform; Ryan Veeder’s Authentic Fly Fishing does it, for example, as does an adult work that’s famous for being the only work to truly push the internal limits of the I7 compiler. But it’s not the default, because it’s a lot more work for the author (there’s no way to automate this, the author needs to specifically note every detail that should be saved and what shouldn’t) and it’s not what players will generally expect.
It’s worth doing a forum search on “save game”. You’ll find quite a few past discussions on this subject. It went around in 2014, and before that in 2011…
But what you won’t find is questions from people asking “Hey, I tried loading an old save game for game X, and now some objects are in the wrong place and the next game event isn’t triggering and I think I’m stuck? Is there a way to fix this?”
The total lack of this happening in modern IF systems is a great triumph! Save files work, even between PC/Mac/etc. Not breaking this has a very high value.
(You will find some questions about getting save files from one interpreter to load into a different interpreter. But this always turns out to be a matter of renaming the file.)
Loading and old save into a new game image would have any new objects and their properties at their start/default locations. Obviously saving again would result in a new format save. Nothing would ever teleport back.
What if it’s now needed to solve some puzzle that the player’s save is already past?
You mean a player is somehow past a pre-existing puzzle needing an object only in the new game image. That doesn’t make sense. Whereas if there is an existing solution, you wouldn’t add the new object.
I’m pretty sure authors regularly change puzzle solutions when they update their games – I’ve certainly done it in testing, as well as when making a post-IFComp release. I think this is an illustration of the points others have been making – if the way your save approach works presupposes authors will behave only in certain specific ways, authors, chaos muppets that they are, will violate those presuppositions and bork the thing. And you think your approach doesn’t presuppose specific authorial behavior, you’re probably missing something!
I totally accept my hand-waving “solution” is totally inadequate. But I do think it’s possible - given certain limitation which would be acceptable for bug fix updates, which is what we’re really talking about rather than new gameplay.
But what you won’t find is questions from people asking “Hey, I tried loading an old save game for game X, and now some objects are in the wrong place and the next game event isn’t triggering and I think I’m stuck? Is there a way to fix this?”
These weren’t commercial games. If you’d worked your butt off for a commercial release, you can bet there will be a major bug the day after release that you really want to fix.
It’s just the law of the sod.
I accept that major changes are unfeasible. But what is needed is a way to make a minor bugfix to a game without breaking save games. This might be a property change or a conditional of some kind, but probably not the addition of objects in fact.
The question is, what (minor) things can be changed whilst retaining save compatibility?
It may help to think of savefiles less like normal savefiles and more like memory copies, because that’s what they were. If you tell Windows to hibernate, took out the harddrive, put it in another computer, and then replaced all the software with newer versions, you couldn’t put the harddrive back and expect the hibernated session to be resumed! It’s the same with Glulx and Z-Code savefiles - they freeze the entire state of the virtual machine’s memory and it would cause the virtual machine to be incoherent if you loaded that frozen memory state into a different program. The interpreters have safeguards to prevent you from being able to load the memory into a program that doesn’t match exactly.
Almost nothing - only the kinds of things you can accomplish with a hex editor. Things like changing a single number (sometimes), change a text (as long as it doesn’t get longer).
Bocfel makes a number of patches to classic Inform games. If the change is as small as one of those you might be able to update the storyfile while keeping save compatibility.
Thanks. I think this is the best explanation of the problem. Marked as solution.
Now that’s not to say that you can’t design a game to be updateable, but it does need to be designed that way from the beginning. The table based model has already been mentioned. It would also be possible to implement a sort of entity component system. I wrote an extension that lets you write and parse JSON data. As long as save files only need to be backwards compatible you can design systems like these to be expandable. But the more data that can be changed, the more fragile it would be.
I mean, Hadean Lands is a commercial game. I think out of the people in this thread, zarf probably has the most experience with using Inform for a commercial release.
It’s only relatively recently (within my memory, and I’m not that old!) that it’s become standard for games to need day-zero patches for game-breaking bugs. Infocom, the original creators of the system that underlies Inform, didn’t consider save file compatibility an important feature, because the vast majority of players would only ever have access to a single version of the game: the one that came on the physical medium they bought.
There would, of course, inevitably still be bugs, and later releases to fix those bugs. But those later releases would only be available to people who players who bought the game later on. So there was (presumably) extensive quality assurance to get rid of as many of those bugs as possible before release.
My WIP is intended to be commercial. It comes in chapters that often involve different characters and locations. I have, as per Dannii’s comment –
– designed a kind of updateability for it. True save files will break, as ever. But the game will let you restart from any chapter you’ve previously unlocked, and this will work across versions. So at worst, you only have to go back a little bit. As Fly Fishing does, my game stores custom, version-proof data files to do this.
-Wade