It appears that when you save a game in Quest, it saves not only everything in the game, but the game and all its logic itself. This means that you can't fix issues and players can get the benefit of it when they open a saved game. Not only can you not add commands, but changing the logic of existing commands doesn't work.

Is there any work-around for this?

Not without a lot of work on your part (for example, to devise your own save game format plus a new mechanism to save and restore it, etc).

Or come up with some sort of patch mechanism.

There are possible routes to go, but none of them are trivial or straightforward.

OK, thanks Jay. I guess we mere mortals live with what we're given. Do you think it is worth putting in a feature request for a version-agnostic save format, or is there no demand for such a thing?

The problem is what is considered data that needs to be saved? The current solution is to save the entire current state of the game. That keeps the game consistent. If you want to not save everything, then you need to know what is important to save vs what isn't, and that's not a trivial thing.

For example, let's say you have an "apple" object. That apple starts out in the kitchen (say). Now the player can pick up that apple and move it somewhere else, or eat it or throw it in the incinerator.

It seems you'd want to save the apple's state in the save file.

Now let's say in the future, you want the apple to start in the dining room instead of the kitchen. Now what happens? If the player hasn't found the apple yet, you'd want it to be in the new place, in the dining room. But if it has been found and moved, you'd want it to be in its new position. How does a save system deal with that? How does it know what information is important to save as opposed to that which should be overridden by new game code? What if the player has picked up the apple and is carrying it around, and in your next rev, you decide the apple is irrelevant and have removed it from the game altogether? Does the player still have it? Does it disappear?

Generally, how in the world can the game code figure out your desire for merging old and new game content?

You can add a feature request for this, but I think unless you can completely specify the behavior, it's not going to go anywhere, as it's not a simple thing, even to work out how it should behave.

What I was thinking of was that the saved file has a snapshot of all objects and attributes except for scripts. While that would not allow for some changes (such as adding rooms or changing descriptions), I think it would handle nearly all improvements and bug fixes in a game ready to be released into the wild. And since the attributes are all there, the updated game would be able to detect what version the saved data is from and so be able to update things like a different starting location for an object or different descriptions. Well, assuming there was a way for the game to detect that somebody had just loaded old data into it.

To be honest, most of my fixes for games have been in things like descriptions. And script changes often require data to go along with them...

The part about the updated game being able to detect what version, etc, is really the crux of the matter. You as the game author would have to account for the changes yourself somehow, as only you would know how the old and new should be merged. A mechanism could be put in place to somehow kick off this merge process, but it would have to be under control of the new version of the game, and it's not clear to me how to even do that (the new game would have to be able to access old and new objects in order to update them or bring them together).

I'm not saying it can't be done. I just can't see it ever being trivial or seamless for the game author, unless a lot of behavior is specified up front (which still won't make some people happy!)

As it is right now, resuming a saved game doesn't even look at the original game file any more (as far as I know), so that in and of itself would be a change in how things works.

It is an interesting problem, though!