Improving your dev process: Automating collection of game-crash info

(As spotted in last month’s Game Developer magazine’s Inner Product column. Good enough that I wanted to draw some attention to it, and hopefully add a bunch more of these good ideas as I come across them / remember them)

Most games, when they crash hard enough, memory dump. The customer (or internal tester during development) can then be requested by the dev team to find a specific file in a specific directory (the mem dump) and email it to them for analysis.

Some games actually popup a dialogue to the user, to tell them about this file, and where to find it, and who to email it to.

Some even include some contextual information automatically (“the user was on Level 3, and has the following DirectX hardware info”). Most just ask the user to fill in a field “telling us what you were doing when it crashed”.

Most games, during development, automatically either popup – or display in a custom textarea – a message every time somethign unexpected happens, something that MIGHT be a symptom of a bug. There are even conference talks about how to avoid making your playtesters so sick of error messages that they stop bothering to read them, and hence the messages become mostly a waste of time.

How many games do a simple call to the SQL client library to send to the local SQL server a simple detailed report of what happened, when, why, and how bad it was? This information is ALL already available, but how hard is it to copy/past the following into your source code and execute it as an SQL command?

INSERT INTO reports.errors (time, problem, severity, stacktrace, user, IP, clientversion) values (TIMENOW(), “+assertion.getMessage()+”, “+assertion.getLevel()+”, “+assertion.getStacktrace()+”, “+assertion.getUsername()+”, “+system.getLocalIPAddress()+”, “+client.getVersion()” );

Nice idea – free, detailed, metrics on exactly why, when, and where your game exe is crashing, any unexpected problems, anyone who’s running an out-of-date version, etc.

And with the dev team no longer having to rely on users *actually bothering to tell them* when they see big flashing warnings and errors, we might avoid some of the programmer/artist antipathy (“[artist] hey, can you help me with something?” “[programmer] its got an error! no wonder it doesnt’ work!”, “oh, ignore that, it always does that”, “um, how long has it been ‘always’ doing that?”, “ever since around the time the game started running really slowly, 2 months ago. It sucks – now everything takes me twice as long to test. But that’s just life, I guess” [cue: programmer grinds teeth, smashes forehead on desk, or similar]).

NB: I have nothing against artists. They are just an easy scapegoat for a not-very-funny-but-actually-quite-painful-if-you’ve-been-there joke. No artists were harmed in the making of this post.

5 thoughts on “Improving your dev process: Automating collection of game-crash info”

Comments are closed.