Exactly; the point of this is to make the game aware that it's loading an older format save format, then - instead of crashing - deal with it and actually load the save. This is a feature.

As far as commiting to indefinate amounts of save formats, the point of this branch is to minimize the weekly incompatibility introduced by relatively minor changes, which should not utterly break a current game. The ultimate goal is a json save format that doesn't resemble what a cat produces when walking across a desktp calculator, and can actually deal with trivial changes. This PR has certian changes that mitigate the problem already without needing to bump the version variable:

* Segmenting unrelated data into seperate lines means adding new monsters or player variables will not completely trash a game. Currently, this happens because the number of monsters is hard coded, and the current game::load uses that to determine the end of 'killboard'. After merge, it will stop at the end of the line, and not get lost in the next data chunk (player vars)...this is -without- changing the save version. There is no benefit to putting completely unrelated data chunks on the same line, and prevents crashing. Infact, if new mobs were added to the end of enums, the saves would be 100% compatible.

* Save versioning is for major format changes, not new monsters or even player variables. It's for stuff like removing the weather string (also on it's own line) and moving it to where it can merrily retain past data, or completely switching the format to json, etc. Infact, after jsonification(tm) it might not require bumping between releases

* Segmenting the data chunks makes it possible to convert to json without doing it all at once. I've got monsters and items finished atm.