Dirty Game Dev Tricks

James

MyGaming Alumnus
Very interesting feature from Gamasutra giving some insight into the tricks developers use to get around problems, bugs, console limitations, etc

Dirty Game Dev Tricks - Gamasutra

Example:

This is not the bug you're looking for

Brett Douville, LucasArts

In early 2002, we were readying Star Wars: Jedi Starfighter for submission to Sony. One niggling TCR bug remained, which was that the controller's analog stick functionality would shut off while we were loading our post-mission cutscenes, causing the red light in the center of the controller to go off as well. This bug had shown up when we updated to a library version required by Sony, and the programmer who had originally written both the movie-loading code and the IOP logic for the controller itself had left LucasArts some months before.

In the hopes of narrowing down the problem quickly in code I didn't understand, I inserted seven screen clears in different colors in the code I determined to be the likely source of the problem, hoping that I could at least narrow it down to one or two sections of code by checking what color the screen was when the analog controls turned off. But when I then tried to reproduce the bug, it had disappeared.

It's an old programming adage that if you don't understand the cause, you can't be said to have fixed the bug. But in this case, we were two or three days away from our intended submission date and missing it would have been a big deal. So I changed all the screen clears to black, marked the bug fixed, and called it a day. We shipped on time, with no TCR showstoppers.
 
As a programmer, I can tell you that this type of thing is not unusual. I can't recall how many times I've waded through code only to find a comment saying something along the line of: "Don't remove the next x lines. It doesn't make sense, but the app breaks without it."
I've learned to trust the original programmer and not to tell my perfectionist manager about it. I guess that's what people call experience.
 
As a programmer, I can tell you that this type of thing is not unusual. I can't recall how many times I've waded through code only to find a comment saying something along the line of: "Don't remove the next x lines. It doesn't make sense, but the app breaks without it."
I've learned to trust the original programmer and not to tell my perfectionist manager about it. I guess that's what people call experience.
I.e. If it isnt a show stopper and the show can go one, don't fix it.
 
Back
Top