Retiring in campaign mode proved very tricky. We need to save only a slice of the game – the relevant site that contains the player’s base, and discard everything else. The saved site is then downloaded by other players, and loaded somewhere onto the map grid in their campaign.

The problem is that various game entities keep references to each other, for example a creature remembers the enemy that it was chasing, or a shopkeeper keeps a list of his items. The saving algorithm traverses this graph in a recursive manner and writes to disk whatever it stumbles upon. If it follows a reference that crosses to another site (for example if you stole an item from a shop, and traveled somewhere else), it ends up saving the other site too.

We definitely don’t want that to happen, as the save files would possibly grow very big, and contain a lot of useless information. So the game just crashes when it’s about to do that. 🙂 I spent a big portion of the last two weeks examining these crashes and modifying the troublesome references such that they don’t point to other sites.

Speaking of crashes, I recently made another dive into the crash reports that piled up since Alpha17 was released. I use an open source library to print out stack traces of crashes, and a simple batch file to send them to my email. The reports provide hints at what caused the crash, but finding the actual bug is a detective’s work. In the last four months I received 669 crash reports (compare it to 17700 runs that ended with a highscore, which means that about 3-4% of all games ended with a crash). I managed to figure out a few of the most common ones, and I’m planning a “hot” fix to Alpha 17 in a couple of days.

Nevertheless, the crash situation should improve very soon, as I’ve made good progress in porting KeeperRL to Microsoft’s Visual Studio. Among other things, it will provide much richer crash reports that are also automatically gathered and processed by Steam. This will definitely help keep the game much more stable!