Always assume it’s a bug
Do you follow the development of SpyParty? If not, you should! It’s a really cool asymmetrical multiplayer game focused on deception and getting into the opponent’s head. The lead developer has some good thoughts about how to develop games, so there are some really interesting posts to read on his blog. Balancing a 1-on-1 game with completely different gameplay for each player is no easy task, but he’s doing a great job of it.
The other day, he posted an article about tracking down a persistent bug in SpyParty, one that popped up every now and then and caused real problems, but was not easily reproduced. The article does a great job of explaining the difficulties involved in debugging – a task that most players never really think about. Most player-submitted bug reports are along the lines of “I was playing the game and it crashed. Fix it.” Obviously, this is useless to the developers, since they have no way of figuring out what the player was doing when the game crashed. A good bug report should at least try to explain what the player was doing when the bug happened. Even if the player doesn’t know the exact cause, some level of description is needed.
I really like the author’s mantra: “assume it’s a bug”. I’ve had issues in my own work when I made the (incorrect) assumption that the problem I was seeing was the result of some physics engine weirdness or something else outside of my control. But that’s a dangerous mistake to make, and the underlying bug can bloom out into far worse problems when things get more complicated, especially when dealing with a complicated system like a physics engine. Always assume it’s a bug, try to fix it, and keep an eye on it, otherwise you’ll wind up shipping your game with persistent and impossible-to-find bugs.