This is obviously an important problem with no simple solution. The data is stored as serialized json format but translates directly to Java objects (we use gson). This means that properties that aren't needed anymore will be ignored; properties that are new in newer versions of releases, however, may be problematic. And if the whole structure changes, there is a problem anyway. Updaters/importers will be necessary for major changes. These updaters/importers may even need to be chained. In any case the version number (that is stored in Version.java) should always be included and act as a save game version.
This was partly discussed already in #21 and the problem applies to save games as well as scenarios.
Let's see how much of a hassle this will be.
This is obviously an important problem with no simple solution. The data is stored as serialized json format but translates directly to Java objects (we use gson). This means that properties that aren't needed anymore will be ignored; properties that are new in newer versions of releases, however, may be problematic. And if the whole structure changes, there is a problem anyway. Updaters/importers will be necessary for major changes. These updaters/importers may even need to be chained. In any case the version number (that is stored in Version.java) should always be included and act as a save game version.
This was partly discussed already in #21 and the problem applies to save games as well as scenarios.
Let's see how much of a hassle this will be.