Princess Fix IT

I seriously doubt that there will *ever* be a zero-bug game. It's not important enough.

At the same time, you can't define an acceptable number for a bug count - if a soundfile ends a millisecond to early, it's a bug with that sound. Clearly, you can have thousands of those without ever impacting the game. (It's a millisecond. You'll hardly notice. It might be a bit annoying)

On the other hand, if the game crashes, *one* bug is too many - so clearly, severity is important.

In general - if the amount of money generated by fixing this bug is more than fixing it costs, you fix it - otherwise, you leave it.

Why are you asking?

Well, with some recent submissions around these here parts, I've been trying to educate myself more about what is involved in getting a submission completed and passed.

I know there are different classes of bugs in range of severity (A, B, etc.) and I was curious if a zero bug game was even possible.

What is most important in getting a game shipping? I was thinking that the bug count had a lot to do with it, but I suppose if the team gets passed all crash bugs, then the rest is pretty much gravy. They can then turn to the million other procedures involved in getting the game submitted.

Usually you categorize bugs in three or four groups according to severity. Call them A, B, C and D bugs. A bugs would be things like early crashes and illegal content. B bugs would be violations of Sony/Nintendo/MS standards, inconsistent and infrequent crashes, problems where you can't finish a game if you do something exceptionally weird first, and graphics glitches. C bugs might be frivolous but obviously wrong things -- one great example was some of the braille above a door sign being wrong in PsiOps. D bugs are subjective or border on being wishlist items.

Games ship with lots of Ds, some Cs, and a few Bs, never (knowingly) As. A few times I've seen producers working just as hard as the programmers toward the end of a project, with the programmers trying to stomp out the last few bugs, and producers trying to negotiate B bugs into C bugs, or even offering to tackle somebody's favorite C in exchange for ignoring a B.

I'd wager that *most* games were bug-free in the early days. But games were much simpler then. The software industry as a whole is still doing a poor job of adapting to the scale of modern software however, and game developers haven't done such a hot job of adopting even the few practices that have shown promise in controlling complexity.

I thought you said things were busy at work this week! 8-)