#20 Store the progress, the figures and the settings

[Julien Gouesse]

The progress, the figures and the settings aren't saved yet, they are lost when the player quits the game. Some settings can become invalid when the hardware has changed in the meantime, for example the screen resolution; in this case, the implementation should use the default value as a fallback. The end user might set some parameters to invalid values when trying to cheat; therefore, all values obtained from the local storage should be controlled. The raw game data should be saved as is, rather store the total number of shots and the total number of successful shots than the percentage of successful shots.

I hesitate between two ways of storing those data:
- some property files, with key/value couples
- some XML files

The property files are easier to handle, to write and to parse but I'm not sure that they can contain structured information whereas the XML files can do that but they are harder to handle, they are difficult to keep backward compatible, they would require some conversions with several XSLT sheets. XML would fit into the needs of the editor whereas the properties would be enough for the game.

[Julien Gouesse]

JAXB can generate an XSD schema from a Java class and vice versa:
https://jaxb.java.net/tutorial/

It can transform an XML file respecting a known schema to another one by using XSLT:
http://stackoverflow.com/a/23110396

The missing part is the generation of the XSL file based on two schemas.

[Julien Gouesse]

Using JAXB or java.beans.XMLEncoder and XMLDecoder in the game would prevent it from working with the "compact1" Java 1.8 profile unlike java.util.Properties and the build-in binary serialization.

[Julien Gouesse]

The settings are stored into a file in the user's home directory since the commit 1094: https://sourceforge.net/p/tuer/code/1094/

The commits 1096 and 1097 improve this feature. Only a few settings are currently stored.