Hello hello
I don’t know if my thread’s title is very clear, but :
I’m working on a game that will be improved from time to time, version 1, version 2, and so on.
Each new version will contain new rooms, new NPC’s, new stories…
I know that you cannot load a save from version 1 to version 2, but I’d like to enable the player to import his character and all the world of his game, I mean variables, truth states, and so on.
Is it possible ? And if yes … how ?
Thanks in advance… 
It’s theoretically possible, but really annoying.
What you need to do is manually write out everything important to a file (see the documentation on this), then manually read it back in. Which requires a list of all the variables and states you want to keep consistent. And that list can’t ever change, except to get longer at the end.
I suspect we’ve been pondering solutions for this for years, but we’ve settled on breaking changes break save files. It’s worked because players have accepted it.
As Draconis points out, you can’t use the standard save mechanism because that’s a memory based save routine. When you rebuilt the story file, the memory blocks will be entirely different, so won’t be compatible with those previous memory blocks. Instead, you have to save the data itself and there are mechanisms to do that (read/write from/to files).
With fyrevm-web, I’d like to introduce interfaces to web services for things like this.
But to me, the looong-term solution is to eliminate the virtual machine and have a normal program as an engine that uses external data.
In some sense, that’s exactly what a virtual machine is. It’s a program, and it loads external data (a saved story file).
The problem, I think (and I’m totally not a computer scientist, so Zarf will jump on my head in about 15 seconds), has to do with the form in which a story file is saved. If it’s a memory map of the virtual machine, it’s not going to load when the underlying game structure has changed – and that time-hallowed format dates back to the days of Infocom. Undum, IIRC, saves an actual list of the player’s actions. That’s a different type of story file, and should work nicely after the underlying game structure is changed – unless you change the location of a door or something like that, in which case the command file would break when it hits the dead end where a door used to be. [Edit: Zarf’s example of changing the name of a door is a more subtle example of the same danger.]
If your new version of the game has added, for instance, an extra property to the rusty sword, then the sword would occupy a different amount of memory in some (or most?) virtual machines, which would throw everything ass-over-teakettle. But if there were a mechanism in the software to set defaults for new properties, default locations for newly added objects, and so on, then there’s no reason in theory why a new version of a game would have trouble loading an older story file. It wouldn’t be a memory map – it would be in the form of a database or something of that sort.
Most software does that already! I’m using Reason 9 (a very nice electronic must program), and it can load song files from any earlier version of Reason – it’s backward-compatible. When a Reason 9 file is saved, it can’t be opened in an earlier version of the program, but there is normally no reason to do that.
The real issue, I think (see the caveat above), is that creating an IF system that would do this would be a huge job for the developer, and would also require more work from the story author. The incentive for developers, given the tiny size of the IF “market” and the total absence of $$$, is minimal. [Edit: Zarf’s essay confirms my speculation on these two key points.]
Thanks for your replies, guys. I’m just gonna forget all that 
no time, no money, no skills.
/waves
No. The way the Z-machine or glulx machines are constructed, they’re really meant for in-memory execution. Although they could be adapted to having external data sources, that’s not how they were designed. It would be better, (not easier), to just build an engine without the virtualization.
There really is no technical reason to have virtual machines for IF anymore. Even mobile CPU’s can handle large execution cycles. And if you add functional cloud computing like AWS Lambda or Azure Orleans, massively scalable calculations are within reason.
Needless to say this is a passionate subject-matter to me. Not for any reason other than I’d like to see it tried to see what can be done differently. I wonder if some restrictions within the VM/inform/tads world can be removed (without adding other restrictions).
I should point out this process doesn’t have to be quite as hellish as everyone’s making it sound, just Pretty Hellish… if you apply a bit of conscious attention to your material first and can design a few things with your goal in mind.
Do you really need to remember the state of everything? Or just important stuff?
For instance, if your game has a bunch of regular openable doors, will the player care if they flip shut between versions? Probably not. Most regular props and scenery can be allowed to snap back to the default state. Most console games used to work that way and some probably still do.
I’d say a typical start list is -
And then you have to read these flags when the game starts and adjust some parts of the scenery accordingly.
So yeah, to minimise the amount of manual reconstruction involved, you need to design with this approach in mind. Make typical sure doors don’t need to be closed. Make sure typical food items can just replenish. Make sure the majority of items don’t need to hold vital stats, etc etc.
It’s not impossible, just extraordinarily annoying. But doable!
Actually my game is more like a kind of (non-linear) CYOA. The most important things are PC and NPCs variables (who’s dead, who’s known, who’s with or against the PC…) and the truth-states of the world itself (epidemic, civil war, and so on).
Do I absolutely need to store all these things in tables, to save them in files ?
No, but it’s the most convenient way. (Inform has built-in utilities to read/write tables and strings to files, but if you want a different format you’ll need to write your own code for serializing and unserializing.)
Perhaps check out Aaron Reed’s “Config File” extension which can read an external file. I might guess it could be extrapolated to potentially write data to the file during a game. inform7.com/extensions/Aaron%20R … index.html
For Baker of Shireton, which remembers certain events that persist over game sessions, I used Emily Shorts “Recorded Endings” extension. When certain events occurred, I would “record” it as an ending, but not actually end the game. The extension allows the game to check for “used” endings and move the scenery around as necessary. This is an easy fix if your save-state isn’t too granular. If your game has some bottleneck checkpoints…you can put the player there hopefully with the correct objects they need to proceed.
inform7.com/extensions/Emily%20S … index.html
Only issues with both of these if you’re adding material to a game: you have to ensure that the player overwrites the original game in the same location with the config or the recorded endings in the very same place with the correct filename that it expects. Or you need them to move any config/save file to the new location where the new game is.
If anything, perhaps these extensions can get you started to know what is involved to roll your own thing.
You might consider running your game old-school. Give the player a code at the end of one episode, then in the next version of the game include every bit of the original material and accept the code to skip the player forward. The code itself might determine your variables. Or you can strategically make the bottleneck empty the player’s inventory and give them amnesia so you have less to fiddle with.
The hard part in implementing something is where the file(s) get stored and on what platform. Linux, Windows, and Mac-OS would store data files in different places. I think the optimal solution would update the Quetzal routine to also execute “store these values during save” and “load these values after restore” routines and append such data to the emitted save file (possibly as a blorb file?). Then there’s some synchronicity to the data.