[Feature]Save game converter

[littlepig]

I saw in the code that a load of a saved game needs a function to every different version of it. So, given the saved games version diagram:

V1--V2--V3--V4--V5-- ... --Vc
-
-
V3.1

From what I've read in the code, it currently implements a loadV1, loadV2, that loads those files to the current version Vc of the game.
One disadvantage of this paradigm is that if Vc changes, every piece of code of loadV{i} must be changed to ensure compatibility, which greatly decreases the ability to change saved games with new features.

I would suggest that since the version is a increasing list with possible branches (i.e), lets create a bridge between each version:

Let convert(V{i}) a function that have an input of version of a saved game (V{i}) and an output of a V{i+1} saved game (for instance convert(V2) converts a V2 version of a saved game to a V3 (creating a new file or replacing the existing file).

So, every time a saved game has a version V{j} and the game have a current version V{i} (where i>j), then a ConverterToCurrentVersion() is used. This converter do a recursive conversion:

for (k = j, k < i,k++)
{
convert(V{k});
}

This have more computing time since it have to run i-j convert(). However, this is by no means a problem, since people tend to use new versions of the game, so i-j~~[1-3].

The great advantage of this is that every time there is a new version (Vn) of a saved game, one must only produce a code with the CHANGES from the older current Vc, to the new version Vn. The ConverterToCurrentVersion() is already granting that all the versions are properly converter to Vc.

What do you think of this?

Cheers,
littlepig

[Per]

The proper solution is to get away from saving all the data as a binary dump, and instead use a more semantic markup that is easier to keep backwardly compatible. For example, by using INI files for most of the data. For the short term, we are breaking savegame compatibility in master anyway, so don't worry about it.