databases dev-process programming

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 replies on “Improving your dev process: Automating collection of game-crash info”

At Turbine there was a pop-up whenever a crash would occur that would just say, “Here’s the dump, do you want to email it straight to the bug tracker?” And then the QA tester (or whoever) would just look it up to make sure it’s not a dupe crash, and press “yes” if it’s not a dupe.

This is always a good idea, and can be done easily with a single stored procedure (preventing the long string concatenation) and an ODBC client library (or MySQL client library if you want).

I’ve had way too much experience where a “Ignore all warnings” button existed in a game, which prevented lots of problems from being tracked down, both from the art and code side of things. It’s quite sad really. Having a record of every crash and error (even duplicates) helps a lot. At least then you can also know how often a crash is occurring.

Comments are closed.