Gamasutra: The Art & Business of Making Gamesspacer
Dirty Coding Tricks
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Dirty Coding Tricks

August 20, 2009 Article Start Previous Page 2 of 4 Next

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 )

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

All Signs Point to "No-No"

This issue came up during Raven Software's new Wolfenstein, as I was setting up controller support for the 360. It turned out that for the Live integration, we had to know which controller was sending input events. The Doom 3 input code we were using was derived almost straight from Quake 3, so it was a pretty simple system.

In the existing event system, each event was passed around with two integer arguments and a void pointer in case you needed extra parameters. So the goal was to associate a controller ID with each input event. No problem -- just pack the controller ID into one of the event's integer arguments, right? Of course, they were both already in use.

Then came the next idea: Let's just use our fast no-fragmentation per-frame allocator to reserve some memory, plop the controller id in there, and then pass a pointer to it in the event's pointer slot.

It turns out that the event system would take it upon itself to free() the event's void pointer after processing the event. Of course this was totally incompatible with the multiheap approach that we were using. Moreover, there were a few legacy Doom 3 chunks that actually relied on the event code calling free(), so we couldn't just remove the call without non-trivial changes across the codebase. What about adding a third integer parameter? Well, that would involve changing several hundred function calls.

The deadline is looming, I can't spend much more time on this. So, I did the unthinkable -- I packed the controller id into the pointer parameter. I marked it as a horrible hack in a 4-line all-caps comment, and checked it in. This worked fine for a while, and lasted until the whole input system was replaced with something a little better down the line.

- David Dynerman

Velcro Sneaks

Here's a tale from a project in the early PS2 days. We had a ton of collision/bounding issues that were largely solved at the last minute by a rewrite of character collision to use a "collider" model -- a stack of spheres that were way better at resolving bumps vs. boxes than our hierarchical tree of oriented boxes ever could be (ah, the Land Before Havok).

However, we had a rare bug for ages that was pretty maddening -- we called it Velcro-ing -- where every now and then the player character would be up against a wall and sliding along it, but then a sphere of the collider would suddenly decide it was on the wrong side of the wall and wouldn't let you get away from it (i.e. you'd be stuck to the wall's surface).

This was one of those god-awful "sounds easy" bugs -- just figure out why the sphere thinks it's on the wrong side, and fix it. Problem is, you had to catch what happened in all the collision resolutions before it happened to figure this one out.

When you'd drop in things like handy conditional breakpoints to look for a weird response, or a push that made it get confused where it was on a skinny box or something similar, it'd bog the frame rate down and the issue simply wouldn't happen. (The real fix to this problem took blood, sweat, tears, and I think other fluids not usually required, but that is another story.)

Since we were trying to submit, and regularly would get this issue as a blocking bug, one "solution" was to buff out the bounding on whatever was causing the problem, which was guaranteed to make it not happen, but was clearly not the right fix. We'd forward the bug to our art team, they'd fix up that case, and in the ensuing turn-around time, we bought ourselves precious days to keep trying to track down the actual deep, subtle problem.

Testers would typically send back a "player hit invisible wall, player must not hit invisible wall" bug of roughly equal severity (bounding the wall tightly again fixed that, as Velcro-ing was really rare and hard to reproduce anyway), but after a couple cycles of this as we cleaned up the rest of the game, the blood, sweat, and tears fix was eventually found and off we went to duplication and shelves.

This wasn't the proudest cycle of bug-turn-around-stalling, but it got the upper-ups off our backs, because we could say "oh, no, we released that to testing yesterday," and keep scrambling to figure out that damned flipping issue.

- Anonymous

Article Start Previous Page 2 of 4 Next

Related Jobs

Red 5 Studios
Red 5 Studios — Orange County, California, United States

Graphics Programmer
Red 5 Studios
Red 5 Studios — Orange County, California, United States

Gameplay Programmer
Gearbox Software
Gearbox Software — Plano, Texas, United States

Server Programmer
Forio — San Francisco, California, United States

Web Application Developer Team Lead


Dirk Broenink
profile image
Hahaha, some great stories in there :P I dont get the second one, "Identity Crisis".. How does putting in a space fit it? :O

Scott Lawrence
profile image
A checksum / hash like a CRC changes when you change the file in any way. Because they changed the file (by adding a space), the CRC also changed, so it no longer had the same checksum as the other file.

Aubrey Hesselgren
profile image
That last one reminds me of a time I was on an unrealistically aggressive deadline along with the rest of the team. A producer had a meeting with the client, skillfully freeing up another week of time. I happened to be in on the meeting, and was super relieved to know that we weren't going to kill ourselves trying to get the work out.

I was just about to tell the team the good news when the producer pulled me aside, and mimed a "shh!" gesture.

The team continued to crunch, none the wiser, until we reached the now fake deadline. After that, the producer acted dissappointed in us, and told us to keep going.

Boy, that producer really knew how to get work out of people who were demoralized and exhausted already! HAH HAH!

Ken Demarest
profile image
Back on Wing Commander 1 we were getting an exception from our EMM386 memory manager when we exited the game. We'd clear the screen and a single line would print out, something like "EMM386 Memory manager error. Blah blah blah." We had to ship ASAP. So I hex edited the error in the memory manager itself to read "Thank you for playing Wing Commander."

profile image
hahaha I remember that line being printed out and always felt it was a nice touch. This is awesome to learn it was a hack =D

Daniel Lew
profile image
@Dirk: A CRC is a hash which creates a string (in this case used as an identifier). They were using the data inside the file to compute the hash; as with any hash function, collisions are possible between two sets of data. However, by adding one space character to the end, they change the data inside the file such that the CRC calculates a completely different hash value. Thus, the collision was fixed by changing the file in a way that's meaningless to the data inside, but very meaningful to the CRC hash.

Douglas Walker
profile image
Putting in a space would change the CRC, which was part of the computed identifier for the file. Change the CRC, remove the conflict.

Dan Weatherman
profile image
@Ken That's awesome :)

Stephen Northcott
profile image
Wonderful list of stories.. I honestly thought it was only me that did things like this!

I feel strangely more human all of a sudden!

As for 'The Programming Antihero" - Well on that one I actually thought *everyone* did that. The real trick when coding solo is to make yourself forget about that array until the very last minute of the project.. ;)

Jim McGinley
profile image

There is a special place in hell for producers that give resources fake deadlines. It's a trick bad producers use to make themselves look good, at the expense of everyone else. In this case, your team suffered so your bad producer could be the hero to the client (and upper management).

Way to cover up for him/her!

Did you like seeing your other team members get extra demoralized and extra exhausted? I guess letting them also be "super relieved" was not your problem. They must have been amazed at your ability to handle the stress of the "unrealistically aggressive" fake deadline. Hopefully that "can-do" attitude got you a promotion.

Good producers work honestly with their team, and they get far more accomplished as a result.

The fake deadline trick tends to only work once (it always gets discovered).

Ever notice that teams miss deadlines for some producers more than others?

Ever wonder why that is? It's all about trust and respect.


Brandon Sheffield
profile image
Ken, that's a great story! If anyone has more to send me, I'd love to do a round two of this feature. In fact, I'll add that to the feature intro!

Michel Carroll
profile image
I love these stories. Not only are they really funny, they also give me a good dose of working in the game industry as a programmer (something I'm working on acheiving at the moment).

Jason Young
profile image
Imho, it's good to have multiple deadlines: One for "try to get it done hack-free by then for a small bonus", and another "real deadline that you should hack to meet if-and-only-if absolutely necessary". The former is based on actual estimates of how long things will take. The second deadline allows more time to make sure everything is right; it is a safety net.

Rodain Joubert
profile image
+1 on the final story. It's an interesting way to look at things. :)

As some have already mentioned, this is done fairly often with deadlines in quite a few fields. I've not ever seen it done with memory constraints, though!

Byron Wright
profile image
@jim, there's a special place in hell for people who label employees as "resources".

Mason Mccuskey
profile image
search any large game codebase for 0xCDCD. Something funny usually comes up.

Wyatt Epp
profile image
This is a brilliant article, though I'm pretty curious what was actually happening in "Velcro Sneaks."

I can see I'll be looking forward to more in the comments, too. ;)

As far as that goes, we were recently having problems where the player avatar would mysteriously disappear and become unresponsive due to the screen clipping against a non-square map. We found the fix readily enough, but the performance cost was so high, that we ended up just forcing the player to render if they were alive with the comment:


// Players should ALWAYS be on screen if they exist.

There were also some related to how we had to implement our own renderer to get half-decent performance, but the real ugly stuff was in the grid optimisation. We lost about two solid weeks ironing out the bugs in that (which, considering our deadline, was actually about a quarter of the total development time; madness), and we still ended up with another avatar-specific hack so players wouldn't be dropped from the game state if they crossed a grid boundary. The code for this is still enclosed in



// End of lousy hack.

But I love the trick in "The Programming Antihero"; I think I'm going to start using it. :D

Jim McGinley
profile image
@Byron - touché!

Employees is a little vague though. Need a way of distinguishing between management, account managers, and senior leads (techincal or creative). Unless the producer is insane, those employees aren't given fake deadlines to motivate them. It's only the people underneath the producer, the creative and technical resources, that get abused. Not sure how else to group them.

Steven Boswell
profile image
My favorite last-minute hack was in the 4-player mode of NitroBike PS2. I couldn't make framerate in one particular level for the life of me; the level design itself resisted occlusion. There was one particular opening in one wall that made proper occluder placement impossible. So I covered the opening with a "wall-of-smoke emitter", i.e. it could be driven through but not seen through. Then I made one big occluder that covered that door and most of the wall. Luckily, it was a movie-set oriented level, so the wall of smoke didn't look particularly unnatural.

Alex Altman
profile image
This was an excellent article to distract me from Compiler Design study. Thank you kindly.

Laurie Cheers
profile image
My favourite comes from an N64 game. Rendering all the text in the debug menu was slowing the game to a crawl, making it hard to debug other issues. The number of characters being rendered each frame had to be reduced.

What could be more obvious? Only render every second letter! But alternate, so that on even numbered frames, you render even-numbered letters, and on odd-numbered frames, you render odd-numbered letters!

This leaves you a flickery, but fast and usable, debug menu.

Jonathon Walsh
profile image
Great article the ending of Identity Crisis cracked me up!

Stuff like this is a great read. Not only is it amusing but it also teaches you tricks you can implement when in a crisis, or more importantly what kind of problem might blow up in your face and how you can avoid them to begin with.

Aubrey Hesselgren
profile image
@Jim McGinley:

Sir, do not worry! You may have missed my sarcastic tones, and also I missed a key plot point: I did the exactly opposite of cover for him.

I was as shocked as you, and told my comrades the story behind the producer's back, because I'm a LOOSE CANNON. It was still a hard push, but they were able to pace themselves.

Jose Ortiz
profile image
Excellent article... and thank you for this gold nugget:

"static char buffer[1024*1024*2];"

That's just priceless.

Douglas Rae
profile image
Great article,

i really enjoyed every one. I would love to see the second edition of this, or maybe more!

Evan Bell
profile image
Whenever you have a CRC collision, you have just "won the lottery". Albeit a lottery that you entered 10,000 times. Or you have a bug in your checksum calculation that caused a loss of resolution. Like a bad mask operation.

Jim McGinley
profile image

Profuse apologies, I TOTALLY did not realize you were joking.

Tone totally changes everything.

I applaud your approach.

I deem thee "Sir" Loose Cannon.


Forgot to mention I loved the article.

Great reading. I have gained wisdom.

profile image
LOL .. priceless!

Jeff Zugale
profile image
@Ken Demarest - HA! I remember that line! Genius. :D

Major kudos to Noel Llopis' old hand coder for that memory trick!

Maurício Gomes
profile image
And I was thinking that only newbies like me shipped those horrendous code... :P

At university there was a team (not related to me, but these guys are the perfect example :P) that made a FPS flash game...

For some bizarre reason, the programmer instead of checking if you was colliding with the wall and not allow you go there, he made the inverse, he checked if there was a wall, and allowed you to move parallel to it...

This sparked a bizarre bug: In crossings, you could not actually cross, only turn to the passage on your left or right.

The deadline was closing, and they had no idea on how to fix it...

Then the team writer fixed the issue! He told the artist to draw a animation of hands touching the walls, and then he wrote in the story that the protagonist was blind and needed to touch the walls to know where he was going.

Andrew Grapsas
profile image
In every codebase I've worked in, you see the following lines:




And, well... they almost never get changed :)

Stephen Northcott
profile image
I think hacks are like squatters. If they can manage to stick around in one place for longer than a few revisions then they have a right to stay... "Just sayin'". ;)

chris kirby
profile image
Working on a basketball game for Genesis. Its used a flash chip to store game data. Game was tested for months and everything was ready so publisher ordered 250'000 copies of the genesis cart. BUT no one for months had reset the flash chips on the test carts to make sure the flash init routines worked correctly or ordered a few hundred carts just for testing..

Turned out the flash init code was dead and the carts could not save games properly!!! Studio went into meltdown trying to figure out how to ship 250'000 broken carts. Suggestions of production lines adding extra resistors and other hacks to every cart were tried and failed , then some figured out if you played some games in a weird order the flash memory would sort of work. So i extra leaflet was added to every box explaining how to use this "feature".

Job done

Chris Kirby

Jason Pineo
profile image
Using the art team and test team as in "Velcro Sneaks" may sound like a cool stalling tactic, is really just a waste of their time. I'm sorry to hear you worked in a place where you couldn't deal honestly with your management or colleagues. I also wonder what issues went undiscovered (and therefore unresolved) because the testers were playing musical chairs with bogus bugs.

Christopher Pickford
profile image

That's the best thing I've ever heard!

Florian Eisele
profile image
Very nice and funny article...BUT...I wonder why, in the "The Programming Antihero" story, none of the programmers ever had a look at the map-file and inspected code-,bss- etc. sizes. The static 2MB buffer would have been "discovered" very soon.

Yes, of course...if you are in need of many megabytes of memory, inspecting the code-size is definitely not the most obvious thing to do ;) but, at least for console/handheld-projects, it is somewhat of a standard procedure.

I have found similar (but unintended) stuff in earlier projects while inspecting the map-file once in a while.

Jim Van Verth
profile image
A couple examples from my past:


Don't know how many remember Force 21, but it was an early 3D RTS which used a follow cam to observe your current platoon. Towards the end of the project we had a strange bug where the camera would stop following the platoon -- it would just stay where it was while your platoon moved on and nothing would budge it. The apparent cause was random because we couldn't find a decent repro case. Until, finally, one of the testers noticed that it happened more often when an air strike occurred near your vehicles. Using that info I was able to track it down.

Because the camera was using velocity and acceleration and was collidable, I derived it from our PhysicalObject class, which had those characteristics. It also had another characteristic: PhysicalObjects could take damage. The air strikes did enough damage in a large enough radius that they were quite literally "killing" the camera.

I did fix the bug by ensuring that cameras couldn't take damage, but just to be sure, I boosted their armor and hit points to ridiculous levels. I believe I can safely say we had the toughest camera in any game.


When I was a lead on R6 Lockdown PS2, I also used the "The Programming Antihero" trick -- whenever an engineer found a significant memory savings I told them to release enough to get the game under budget for the time being, but hold some back for the eventual future overrun. In the end we had a 1-2K buffer (IIRC) that we released just before ship. Most of the team never knew.

Brandon Sheffield
profile image
That first one is awesome, Jim.

Steve DeFrisco
profile image
I was one of a few interns at IMAGIC in 1982-83. We were all doing Intellivision carts. One of the programmers had to leave to go back to school, and I was chosen to fix the random crash bug in his game. It turned out to be a stack overflow in the timer interrupt handler. Since the only reason for the handler was to update the *display* of the on-screen timer, I added some code to test the depth of the stack at the beginning of the interrupt routine. If we were in danger of overflowing the stack, return without doing anything. Since the handler was called multiple times per second, the player never noticed, and the crash was fixed.

Oisín Mac Fhearaí
profile image
There are a lot of great stories here, but the two nicest bits that stick in my mind are Ken Demarest's WC "fix" and Mick West's closing sentiments: 'If you go to the doctor and tell him "it hurts when I do this," then you expect him to find out why it hurts, and to fix that'. Right on!

Roberto Alfonso
profile image
From the 'All Signs Point to "No-No"' section: "So, I did the unthinkable -- I packed the controller id into the pointer parameter."

Well, this is basically what Microsoft uses as their WPARAM and HPARAM in WinProc, so it wasn't that bad =)

@Evan Bell: I am a programmer in the healthcare industry and hit that lottery once some years ago. I had to load a text file with over 100k lines, one per medicine, and two lines gave the same CRC32. Fortunately the update routine was run in our server and the clash was easily found. For two files with the same CRC32, check

Although not game derived, I got a couple to share. Around 5 years ago we had to change the L&F of the application. That included switching menus over, changing background images, reshaping controls, etc. It went pretty well (at 16 hours per day, took us just a week). However, testers complained that the application started to randomly crash after some time of use, with an out of memory error. Just 4 hours before shipping we discovered the error: the new rounded buttons didn't free the normal/pushed bitmaps correctly, eating memory every time they appeared on screen. So we had to remove the new buttons, and shipped a Mac-like rounded application with gray square buttons.

Regarding fake deadlines, we once decided to fulfill it. Indeed, we reached it, had the product uploaded to our servers, fully tested and waiting for the approval of the CEO to be released. But he decided not to launch it. The thing was that he had put a very impossible goal so that we would be forced to delay the package, giving him time to suggest more features before the real launch date arrived.

Also, whenever the physician chose a drug, it would be stored into the database, linked to the patient and a recipe within a visit. However, one of the programmers really messed up and, instead of storing the NDC (national drug code as set by the FDA), he stored the drug index in the drug database. The drug database was usually modified once per month (removing drugs that had expired, adding new drugs alphabetically, etc) so that, when I checked, the IDs in our database were usually pointing to drugs that were not the chosen ones. Even though the contraindication check used names instead of

NDC (which made the routine work still), it was too risky to have random numbers as medicine codes, so we had to clean them up. None of them was salvageable, and I had to wipe out the entire column, but there was no way to explain that to the users without making them think they were in great risk. So, I placed a progress bar that lasted around 7 minutes with something like "Upgrading drug information" which did nothing at all, and notified the user that he would be forced to relink some (all!) of the medicines in the program database with the ones from the medicine database as he starts reusing them. None of the doctors complained, though, and everything has been going smooth since then.

Chris Kirby's one reminds me of a couple. A programmer had just installed a spell checker into our program, with the ability to add your own custom words, and he started testing with words like a**, f*ck, and similar. Unfortunately, he didn't clear the table and we got angry calls from one doctor who was showing his secretary the new spell checking functionality when f*ck popped up. So, always clear your databases before shipping the product!

Great feature! I look forward to "Dirty Coding Tricks II"!

Maurício Gomes
profile image
I for security decided to make my game pop a dialog box for every single error possible to happen, even if the error was actually impossible... But even the "impossible" errors, in fact were possible in circunstances unknown to me in a change of 1 in 1000000000000000 or something like that...


After I typed that, I plainly forgot it, it was embedeed deeply in some initialization routines of the API, a code that once done I would never peek at, also it was the only case that I used profanity or that sort of stuff (I am a person that is not much into profanity, but that day was a bad day, so I ranted on that error message).

Unofortunally, one of the testers actually made that error happen... He called me all confused, and me too (since I don't remembered it) and I tought that he was joking, but I searched and actually found it...

Then I had two questions on my head:

How that error happened? (awnser: a mistype that I introduced on the lastest build caused a nasty chain reaction of bugs that made the execution stack go awry, making the impossible actually possible).

Why I did wrote so much profanity? (awnser: In fact I am still wondering the awnser for that...)

Jon Bellini
profile image
@Ken Demarest - I remember that message!! I remember playing and when I exited I saw that message... I was always like "you're welcome!" haha... good stuff!

James Coombe
profile image
That Wing Commander fix should have been stolen by Bethesda for Oblivion as that used to crash on exit for a multitude of patches they released...

David Howell
profile image
Regarding the CRC problem, it's a common misconception that a 32 bit hash gives you a 1 in 2^32 chance of a collision. This is only true when comparing a single pair of hash values. With 10,000 hash values, there are a lot of possible pairings and the probability of a collision is more like 1% (if the hash function delivers a uniform distribution). Check out the entry for "Birthday Problem" or "Birthday Attack" on Wikipedia for a detailed description of the problem.

Tim Randall
profile image
The engine team at Gremlin used to keep a single glove in their office. When someone asked where it was, it was because they were about to type some really dirty code. It wasn't so much a case of not wanting to leave fingerprints as of not wanting to actually touch the dirtiest fixes.

Peter Amstutz
profile image
The CRC problem may also have been due to poor choice of hash function. My understanding is that CRC functions are primarily designed to check for a data integrity (such as a flipped bit in a network packet) but do not to provide good randomness in your hash values -- for example, very similar files will tend to have similar CRC values, whereas strong hash functions are designed to produce drastically different results even for files that differ by only one insignificant bit.

Adam Galarneau
profile image
I think I know why the guy made the method Debug_GetFrameCount this way. In an interview I got some time ago, the guy asked me how I would access a protected member variable from a class (that was quite an easy question I'd say...). I just answered I'd create a getter method and that's it but when I arrived at my car, I realized you could also access it the same way the guy did it since the class members are set in memory the same way a struct is...

So this is a way to access private/protected members if there are no getter/setter.

Now I'm not saying I'd do that but in the case you're working on a program with an API and you only have access to the .h file, you could get around it this way. =)

abhishek bajpai
profile image
I really Like this Article (Masst :) ).....

mik fig
profile image
Awesome article :D

James Edwards
profile image
I was working on a game called Birthright that was basically a DOS game that got ported to Win95 because of how long the schedule ran over. The game had a high res mode that I think was 800x600. Mouse resolution at the time was 640x480 and we had buttons that were jumped over and unclickable.

I don't know why this ever worked but I had read that if you shift the mouse position left and then right it solved the problem. So I added that and it worked.

Later a programmer looked at this and thought it was just self cancelling and commented out the code and you could no longer click the button.

I explained the real problem was that we were not counting "Mickeys" and should move to a relative system. He asked if I knew how and that is how I moved from being a tester to a programmer.

Greg Aring
profile image
Funny article. On a recent project I was reading in text files, each with an identical format. For some reason only some of the files were getting read correctly. Even files with the exact same content but different names would produce different results. Sure enough, after much time spent scouring my code I discovered that adding a space at the end of a 'bad' file solved my problem.

Ian Richard
profile image
I remember working on one project where we were having major frame rate issues hours before our alpha delivery. Us programmer types saw a potential solution for many of the games... disable collision with the world. During these mini-games we didn't actually need collision, so it didn't effect anything.

Fast forward to the final insane 100-hour crunch time and we have hundreds of seemingly random bugs. Sounds aren't playing and projectiles aren't resetting properly on EVERY single minigame despite being written on entirely different codebases. Nothing made sense.

After days of all of us scouring through code and seeing nothing wrong, I followed a hunch and looked at our SVN logs. Sure enough, our lead designer wanted to improve the FPS and remembered that we had disabled collision in some levels. He knew we were busy and so he disabled it the rest of the mini-games rather than make us worry about it.

The projectiles could no longer collide with the world, meaning they don't "thump" into trees, never reset and so on. I was able to check off almost 500 minor bugs from our bug list by flipping "Check Collision" to ON.

The worst part, once we dedicated time to the FPS problems... I had everything working in 4 hours.

That's what we get for hacking... and more importantly... teaching the hack to people who don't know exactly what goes on in the code.