I don’t know if this weblog entry about bug hunting in large scale game development is more appropriate for my spring games course or my spring project management course. The stories are great for both directions. Team members with poorly defined roles! Frantic timelines leading to bugs! The reality of entire days lost to a bug that won’t be found, let alone fixed! Bugs explained in simple code a novice student can understand! I particularly enjoyed the explanation of why the live server compiler ran without debug capabilities, violating the ideal that the dev and live servers are identically configured, to ensure that debug features used to test the games by forcing benefits, monster spawn, etc. weren’t leaked into the live system – if there were never sensible reasons for breaking what seem like obvious rules, they wouldn’t get broken.
And there is an interesting lesson about customer satisfaction in the story of embedding code in a game to identify hardware failures and then not only detecting when bug reports are actually related to customer hardware failures but proactively telling customers when they are having hardware issues before problems crop up so they can do something about it. The explanation of why this ultimately saves them time by avoiding hard to resolve bugs that are really due to hardware faults makes sense, but also reflects an interesting decision about how much responsibility to take for the entire game playing experience, whether portions of that are actually one’s responsibility or not.