Dirty Coding Tricks

Someone on Twitter posted an article about some dirty coding tricks some game developers were willing to admit to making. The story covers little hacks, shortcuts, and desperate attempts to 'just get it done.' This made me think me of a time I made a dirty hack to fix a bug, and how guilty I felt about it.

This story from the article reminds me the most of my own:

10-Tative Code

Back at [company X], I think it was near the end of [the project], we had an object in one of the levels that needed to be hidden. We didn't want to re-export the level and we did not use checksum names. So right smack in the middle of the engine code we had something like the following. The game shipped with this in.

if( level == 10 && object == 56 )
{
HideObject();
}

Maybe a year later, an artist using our engine came to us very frustrated about why an object in their level was not showing up after exporting to what resolved to level 10. I wonder why?

- Anonymous

In my case, I had this bug I really really needed to fix during one of my past co-op jobs. I had been working on it for a few days, and that was pretty much the max allowed. I had gone through hundreds of lines of code tracing the math transformations involved for what seemed like many hours. But I could just not pinpoint what was causing the behaviour I needed to fix.

I did figure out the conditions of that behaviour, though. And by adding a little extra check just before the actual rendering of the object in question, the bug appeared fixed and no other bad behaviour came up. Case closed?

The fix was accepted, but I felt unusually guilty. I knew it would be better to find the root cause of the problem, but I also knew the time spent in doing so wasn't really worth it.

While I tried to forget about it and move on to other things, a coworker approached me saying, "I think I found a fix to the problem while figuring out my own bug. It's in that transformation code. Is it ok with you if I take your fix out?"

Umm, yeah!!