Aequitas
Saving and Loading
As any game coder will tell you, saving and loading are horrible things. They make your life miserable, and people only notice them if they fail spectacularly. So I’ve snuck onto the blog to get some appreciation for my toil, and also give you a little “behind the scenes” idea of what’s going on when DD saves/loads.
When we were building the initial versions of the full, we got an XML serializer, made things we wanted to save serializable (this means you can convert them into text to store in a file), and simply created a bunch of lists.
Now, this seems like it would work out great, but as it turns out, when making changes to the actual game design, the system would fall on its face more often than not. The reason behind this mostly boils down to changes in the objects that are being saved, and not being able to load them because either they no longer exist or they have fundamentally different internal structures. This of course prompts the game to give you a “fresh” save game, erasing all your hard work … not ideal.
So we went back to the drawing board, and came up with this:
To begin with, you need to understand that DD is a system of Events and Handlers. Handlers subscribe to Events, and Events are fired when different things happen in the game (you click, an enemy attacks you, you upgrade a building, etc). Certain events represent decisions that the player has made about the structure of the Kingdom. Events like: Upgrading a building, selecting a preparation, finishing a quest, etc.
We now round up these events as they happen, and if they succeed, we add them to a big list of events. Because the information in Events is the bare minimum needed to re-create the player choice, they’re the perfect candidate for saving. Their internal structure is unlikely to change, and the structure of the quest tree/building hierarchy can change without the events being affected.
What this means for you is that there’s a good chance your progress (even in the beta) will never get reset … and for us, that’s worth it.
July 12th, 2011 at 11:14 am
Woo, really interesting Aeq. Nice job!
July 12th, 2011 at 7:33 pm
How big do those files get though? Surely that means that your save games will get progressively larger as time goes on (might be small enough not to make much difference). Was battling something similar at work 🙂 ended up saving total changes(net change effect) instead of every change.
July 13th, 2011 at 1:06 pm
I might be missing something here, but what stops you from releasing a convertor in the loading of the old save game, massaging it’s structures into the new serializable object?
The worry is saving the decision path will take a while – eventually as AlexK pointed out.
Don’t feel bad about nuking peoples saved games – eden games / atari did it a few times with the test drive series *bad joke*
July 13th, 2011 at 2:33 pm
As far as size is concerned, that should never become a problem. The ‘possible’ decision tree always terminates at a certain point, and from there keeps very rudimentary information for each dungeon run. It will save about the same amount of information even with the old system.
We will probably have to do conversion from one format to another at some point, but we’d rather decrease the frequency of that.
July 13th, 2011 at 10:28 pm
Very interesting, seems like a very elegant solution to a hairy problem (if I understand correctly). Would love to see some detail, if it is not top secret… brittle saving along agile design is a big deal. Please sneak back with more info if you can!
August 6th, 2011 at 12:02 pm
Another way to solve that problem: Use versioned documents, and provide a converter (migration) for each version to the next one. Then you can upgrade older versions step by step to the latest one. Add automated tests, and you have an easy and trusted system that goes a long way. Used that in several long-term projects without major problems.