Optimised Saving

We noticed recently that many players were reporting long load times (over 30 seconds!), which is not ideal. I’ve written about the save system before, and until now it’s served pretty well.  We decided to investigate and came away with some neat optimizations, and some insights into the meta-game.

After running some tests on culprit save files, we found that there were way more lockering events happening than anything else. Players seem to love going into a dungeon and converting their locker item, they also love coming out and reclaiming it, but will often just go find that item again and re-locker it over the reclaim slot. It didn’t make sense to keep two matching ‘destroy’ and ‘restore’/’relocker’ events, so we wrote a save game pre-processor that can go through the file removing matching statements like this, and some other odd edge cases, like an item being lockered over the same item.

What this did is gain us some big savings in file size, and a fair reduction in  load times … but something still wasn’t right. After some more investigation, we realised that there was a graphical element that was being re-drawn every time the locker status changed, and that was eating up load time as well! That little hole was soon plugged, and now the graphical reset only happens if the game isn’t loading.

One nice thing is that we now have the pre-processor in place, and we can add to it if we ever find another way to save space/load time.