Game Development Reference
Third parties, such as middleware vendors, who may be asked to review a bug
that may be related to a product they supply to the project team.
Customer service representatives, who may be asked to devise workarounds for
Other testers, who will reproduce the steps if they are asked to verify a fix during
Because you never know exactly who will be reading your bug report, you must always
write in as clear, objective, and dispassionate a manner as possible. You can't assume
that everyone reading your bug report will be as familiar with the game as you are.
Testers spend more time in the game—exploring every hidden path, closely examin-
ing each asset—than almost anyone else on the entire project team. A well-written bug
will give a reader who is not familiar with the game a good sense of the type and sever-
ity of defect it describes.
Just the Facts, Ma'am
The truth is that defects stress out development teams, especially during “crunch
time.�? Each new bug added to the database means more work still has to be done. An
average-sized project can have hundreds or thousands of defects reported before it is
completed. Developers can feel very overwhelmed and will, in turn, get very hostile if
they feel their time is being wasted by frivolous or arbitrary bugs. That's why good bug
writing is fact-based and unbiased.
The guard's hat should be blue.
This is neither a defect nor a fact; it's an unsolicited and arbitrary opinion about
design. There are forums for such opinions—discussions with the lead tester, team
meetings, play testing feedback—but the bug database isn't one of them.
A common complaint in many games is that the AI (artificial intelligence) is somehow
lacking. (AI is a catch-all term used to mean any opponents or NPCs controlled by the
The AI is weak.
This may indeed be a fact, but it is written in such a vague and general way that it is
likely to be considered an opinion. A much better way to convey the same informa-
tion is to isolate and describe a specific example of AI behavior and write up that spe-
cific defect. By boiling issues down to specific facts, you can turn them into defects
that have a good chance of being fixed.
But before you begin to write a bug report, you have to be certain that you have all