After some hard work, I’ve re-added the savegame system, then fixed it so doesn’t crash when saving/loading. I’ve also created some support code that enables a massive file size reduction, while still keeping the existing XML based system. And I’ve started filling the gaps in the savegame. It’s not complete yet, but it’s getting closer now.

I had to disable it sometime before the DBP deadline when I saw the amount of work remaining. I had to choose between saving/reloading and doing a thousand other things, like content and polish. I picked up content over saving, and so limited the ‘campaign’ to a shorter demo that I was intending at first.

This taught me a good lesson: never put the savegame system as a low priority ‘to be done at the end’ task. Of course, if you’re only saving the high scores and sound volume preferences, that’s no big deal. But for a game with progress saving, it is a big task, all entities should be designed with save/load support in mind, maybe automatic serialization, if possible.

In my case, automatic serialization isn’t practical, due to huge file size and multiple dependencies (OK, the dependencies could be fixed). So I’m writing it all by hand. For instance, take a good care at how things are setup, how the data is loaded, what kind of loading order dependencies there are, etc. I’ve made mistakes with some classes that can’t be instantiated with default values, then setup, then their content loaded.

Anyway, enough technical discussion! What this means is: the project is getting nearer release! The savegame system is the last major feature I need to have working before release. After that, there is only polish and content to be done. Which isn’t easy and quick either, but it doesn’t feel like a huge wall in front of me. And it will enable adding much more story missions, as testing them would become practical again, not having to play through the whole game each time I want to test one 😉