Does AGS need savegame versioning?

Started by Crimson Wizard, Mon 20/08/2018 20:06:07

Previous topic - Next topic

Crimson Wizard

My background is large complicated software which writes and reads lots of files some of which may happen to be years old, and I guess my brain keeps working inside this scheme.
I've spent a lot of time inventing a savegame format for the engine that would be easy to update, where each component (Characters / rooms / etc) has its own version, and so in theory one could support reading saves made by older engines as much as they want.
With AGS in "normal" conditions people probably rarely load up saves from older versions of the engine, but such situation sometimes happened with ports: someone was playing original Windows version of the game released with e.g. AGS 3.3.3, then loaded it up in latest Linux port of AGS 3.4.0, or maybe just moved from the buggy version of the engine to play the game on newer one, and wants same saves keep working.
Another idea I keep having is that since program is popular and used by many people (both developers and players), the "documents" it creates should have format that is easy to decypher and proper distinct versioning in case someone wants to parse them for any reason.

But the problem is that... I start having doubts in rationality of my decisions. Maybe this is all because I was working alone for too long and had no one to discuss things with properly, or maybe that's because I constantly feel pressure of having to answer to people having issues with the program all the time. On one hand I want program to work consistent and have certain "discipline" in it, on another I am no longer sure if the requirements I set for it are valid.

Because the simpliest way would certainly be to just have savegame bound to the engine version and refuse to load anything else even though in theory it could, and if someone complains just say "sorry we dont support anything else".

Cassiebsg

I'm not really a coder, so disregard if this idea is completely bogus... How hard would it to have a little extra software on the side. Let's say a savegame file converted? So if anyone wanted to load an old save on a new engine, they could just load it on that program and "upgrade" the save (by making a new copy of the original) with the new standard?

Just an idea. Personally I've never loaded an old savegame on a new engine version... though maybe for those doing commercial games and pushing game updates that is not a wish but a requirement? would be interesting to hear they POV.
There are those who believe that life here began out there...

morganw

Escoria has an interesting approach, where the save game file contains the script commands to restore you to your current point in the game. Potentially, could the 'cutscene' functionality be used to jump through a script if there are checkpoints set?

Crimson Wizard

Quote from: morganw on Mon 20/08/2018 22:06:02
Escoria has an interesting approach, where the save game file contains the script commands to restore you to your current point in the game. Potentially, could the 'cutscene' functionality be used to jump through a script if there are checkpoints set?

I have a feeling we are speaking of different things... I meant data format versioning, not game versions.

morganw

Yes, but I wondered if this could cover both cases, as long as any available script functions to restore the state were still available in a newer engine version. So the data version is just the script version, and you drop support support for loading an old restoration script in the same way that legacy functions are phased out (script version strictness).

Just an idea though (and possibly a bad one).

:)

Crimson Wizard

#5
Quote from: morganw on Mon 20/08/2018 23:00:45
Yes, but I wondered if this could cover both cases, as long as any available script functions to restore the state were still available in a newer engine version. So the data version is just the script version, and you drop support support for loading an old restoration script in the same way that legacy functions are phased out (script version strictness).

Oh! Hm. Now that actually sounds quite interesting.
Not sure how it may be achieved with compiled ags script though.

Danvzare

As far as programming goes, I still consider myself an amateur. Also, I have no idea how AGS is coded. So take this with a pinch of salt.
Also, I've never released a large game, let alone a commercial one. So I feel as though I don't know enough to have a valid opinion on this one way or the other.

But while savegame versioning sounds like it would be a nice addition, it also sounds like it would be way too much trouble than it's worth.
If you can't get something like that implemented in a week of less, just don't bother. It's not worth the stress.

Crimson Wizard

#7
Quote from: Danvzare on Tue 21/08/2018 12:21:05
But while savegame versioning sounds like it would be a nice addition, it also sounds like it would be way too much trouble than it's worth.
If you can't get something like that implemented in a week of less, just don't bother. It's not worth the stress.

It is already like a year as it's implemented.

I decided to stop this topic.

SMF spam blocked by CleanTalk