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.