Bugs

Like any large software product, King of Dragon Pass is not perfect. We wish it were, so we track bug reports and try to fix things when we do an update.

When we created the original game, we had a quality assurance team to find bugs. We also relied on beta testers. For the iOS version, we don’t have a paid team, and Apple limits the number of outside testers. So we have to rely on players to do much of the bug finding.

Today, a blog comment read “the game seems to be crashing often.” My first thought was “no, it doesn’t!” The second was “that’s not a very good report.” But then I thought, “what if it is crashing more often than I think it is? If so, I want to fix it!”

I remembered that Apple makes crash logs available to developers. Normally, if an app on your iPhone crashes, a log is saved on the device. When you synchronize, it’s copied to your computer. And if you’ve given the OK, it is also sent to Apple. (I believe only when you synchronize, though I’m not sure of the details.)

This is especially handy because Apple will combine duplicate reports. When I logged into iTunesConnect and checked, the top 3 crashes accounted for 71% of the reports. I grabbed these.

The logs by themselves aren’t very useful. They include a stack trace which shows exactly where the crash occurred, but only in numeric form. They need to be symbolicated — cross-referenced against the symbols (typically method or functions) of your app. For this to work, you need to save the symbols with each build. Luckily, when you make an archive to submit to the App store, the symbol table is saved. Unfortunately, Apple’s development tool Xcode is terrible about symbolicating. In fact, I was only able to symbolicate about half of the logs. Luckily, I could get one log from each of the top three crashes. And they all pointed at a method in my AdviceView. In one of them, the call stack included showQuestDialog, so I started showing advice and opening and closing the Quest dialog. Sure enough, I got the crash. From there it was pretty short work identifying what was going on (it was a message sent to zombie object, one that should have been dead). And easy to fix.

So this story has a happy ending, and one that makes me glad I’m an iOS developer and a lot of the work was done for me. (Bigger software developers often create a similar infrastructure themselves, to capture crashes in the field.)

But the moral of the story is: we can’t fix bugs we don’t know about! The 2.0.5 build has been played since February. Nobody mentioned anything until now. Please let us know about problems! http://a-sharp.com/kodp/bug.html explains how to send a report from the game itself. (This won’t do anything with crashes, but you can email bugz «at» a-sharp.com with the reproduction steps, and we can send back the somewhat picky details of finding the logs on your computer.