Game Development Reference
In-Depth Information
3. If the bug is serious enough, it is assigned to someone on the team to investigate
a solution.
4. Someone investigates a potential solution. If a solution seems too risky, that
person reports back to the triage team for a little advice.
5. The solution is coded and checked on the programmer
'
s machine by a colleague.
t have to be the lead programmer, just anyone with neurons and a
reasonable familiarity with the subsystem being fixed.
6. The bug is sent back to test for verification.
7. The bug is closed when someone in test gets a new version and observes
the game behaving properly.
It doesn
'
If you think that the bureaucracy is a little out of control, I understand your con-
cerns. It might be out of control, but it
s out of control for a reason. Many bugs
might never make it out of step #1. For those that do make it to a real fix, it is
reviewed by a colleague who can really help ensure that the bug is fixed correctly,
and it is never seen again by the testers or the team.
'
Bug Meeting on
Martian Dreams
My first experience with bugs in games was on Martian Dreams at Origin
Systems. The whole team gathered in the conference room, and each new bug
from testing was read aloud to the entire team. Sometimes the bugs were so
funny the whole room was paralyzed with laughter, and while it wasn
'
t the
most efficient way to run a meeting, it sure took the edge off the day.
On Ultima VII, Ultima VIII, and Ultima Online, the teams were simply too big,
and the bugs too numerous, to read aloud in a team meeting. Between the
inevitable laughter and complaining about fixing the object lists again, we
'
d
probably still be working on those games.
Even on smaller projects, like Bicycle Casino and Magnadoodle, we held bug meetings with the team
leads. It turned out that the rest of the developers would rather spend their time making the game
better and fixing as many bugs as they could than sitting in meetings. Outside of that, time away from
the computer and sleep was a welcome diversion.
Of course, everything hinges on your active bug count. If you are two months away
from your scheduled zero bug date, and you are already sitting at zero bugs (yeah,
right!), then you have more options than a team skidding into their zero bug date
with a high bug count. I hope you find yourself in the former situation someday.
I
ve never seen it myself.
The only hard and fast rule is how many bugs your team can fix per day
'
this bug
fix rate tends to be pretty predictable all through your testing period. It will be
—
