I7: Continuing saves between different games?

Is it possible for either a Z-Code or a Glulx game to retrieve information from a saved game file from a different game?

I’m imagining a series of games (like the graphical Mass Effect series) where the player can make meaningful choices that have consequences in later games, such that the player would want to port in their old character along with the state they left the world from previous games. (This could of course be done quite easily with a code given the player at the end of each game which they could type into the next game).

A different application: you could have a meta-game that takes information from lots of different stories (say, all the entries from a given comp) and unlocks different paths within the game depending on what stories the player has played.

These are purely theoretical questions at the moment (I’ve got other fish to feed), but it would be interesting to know.

You can write a game in such a way that it writes data to a separate file (not a game-save file) or reads such a file. It will be up to you, as the author, to encode and decode whatever data you decide to make use of – there’s no way, as far as I know, to load the whole game state as a lump into a different game.

Short answer: no. AFAIK a saved game in Z-Code or Glulx represents the state of the virtual machine in its entirety. Saves can’t even be ported from a game to another version of the same game, let alone a completely different game.

Long answer: yes, but not by using the built-in saving mechanism. I7 has a system for saving info to external files. This can be used to keep track of choices, character stats, etc. One thing to bear in mind is that since inform doesn’t natively support dynamic creation of objects (although there’s an extension for it), moving actual objects from one game to another will be problematic.

There is a good discussion of your options here:

https://intfiction.org/t/idea-i-have-possibly-already-implemented/3017/1

Thanks everyone!

I really like Katz’ suggestion for a minicomp* based around compatible games. The comp curator could write an extension that contains all the possible items** and character-variables for the games, and then the authors would write games using different combinations of these items and variables, giving different content depending in what order a player plays the games.

*Though it would be less a competition than a short collective project.
**As one way around the problem of dynamic item creation.

I’m curious about this too since I’m planing something that is split up into several independent modules. From what I can gather, assembling the data in a way that makes them easy to import in an organized fashion will probably be the hardest part.

Quick example of a party export/import that considers that some members may not exist in the following module:

Export:

[code]“Full team”

File of Members is called “partyExp”.

Lab is a room.

Jane is a person.
Ben is a person.
Frank is a person.

When play begins:
repeat with p running through people that are not player:
let x be a random truth state;
choose blank row in Table of Members;
change Name Entry to “[p]”;
change Alive Entry to x;
say "Exported party members: ";
repeat through Table of Members:
say "[Name Entry] ([if Alive Entry is true]alive[otherwise]dead[end if]) ";
write File of Members from Table of Members;
end the game in victory.

Table of Members
Name Alive
indexed text truth state
with 3 blank rows[/code]

Import (males/females):

[code]“Males only”

File of Members is called “partyExp”.

index_check is an indexed text that varies.

Lab is a room.

Ben is a person.
Frank is a person.

When play begins:
If the File of Members exists:
read File of Members into Table of Members;
say "Party imported: ";
repeat with p running through people:
change index_check to “[p]”;
if index_check is Name listed in the Table of Members, say "[Name Entry] ([if Alive Entry is true]alive[otherwise]dead[end if]) ";
Otherwise:
say “ERROR: Couldn’t locate file”;
end the game in victory.

Table of Members
Name Alive
indexed text truth state
with 3 blank rows[/code]

But that only works as long as a) the number of rows in the receiving module is at least the number of the exported rows and b) printed names of the object’s match in both modules (can you refer to an objects ‘real’ name? Can’t remember…)