In this timeless feature from the March 2010 issue of Game Developer Magazine, we revisit the mighty kludges and well-meaning hacks that are occasionally required to get our games into the hands of eager consumers.
This article originally ran as a follow-up to the magazine's original 2009 Dirty Coding Tricks feature, but these hacks and heroics span the entire history of computer and video games, even extending laterally into the business software sector. Delight at the ingenuity, marvel at the audaciousness, learn from the mistakes of your predecessors, but most importantly, release games that work—on time, too.
If you want to share your own surprising solutions for getting games out the door, we want to hear them! Send your dirty tricks to Gamasutra and they may be featured in a future article.
Back on the first Wing Commander 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."
- Ken Demarest
When I first started working in the game industry I spent most of my time shuffling between various small, underfunded startups. Here is a horror story from the good old days when men were men and used DirectX 7. I worked for a company that had been forced to use a certain 3D engine by the publisher. The engine shall remain nameless, but the publisher had been persuaded to buy a number of licenses for it as part of a bulk licensing deal, and insisted that we use it.
To be blunt, the engine did not work, and I spent most of my time at the company making the 3D engine do obvious things correctly, such as fixing the engine company’s implementation of single-pass multi-textured lightmapping.
One of the more interesting things that did not work was the BSP compiler. Level designers would build level geometry with correct visibility, and then minor geometry adjustments would break visibility on the other side of the map. To this day, I don't know why this happened, but I believe that the engine’s BSP compiler added brushes to the BSP tree in a random order, and certain combinations would just ... randomly break things.
At the time, I had never heard of a randomized algorithm, but I invented one regardless—a preprocessing stage was added to the BSP compiler that shuffled the order of the brushes before they were fed to the engine's BSP compiler. That way, if the level geometry broke the BSP compiler, we could just try shuffling the brushes with different random numbers until we found a combination that worked, and then we stuck with it until the next time the BSP compiler broke.
The game itself was a disaster, and both the engine and the game were featured in a Penny Arcade cartoon that contained the first ever appearance of the Fruitf*cker 2000. This remains a milestone in my personal career.
- Nicholas Vining
I was working on NBA JAM TE for the Genesis, which used a flash chip to store game data. The game had been tested for months, and everything was ready to go, so the publisher ordered 250,000 copies of the cart. But it soon became apparent that no one, for months, had reset the flash chips on the test carts to make sure the flash init routines worked correctly. Nor did anyone order any carts for testing.
It was only after all the carts had been ordered that we discovered the flash init code was dead, and that the carts could not save games properly! The 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.
When all seemed lost, someone figured out if you played the games in an odd, and very specific order, the flash memory would sort of work. So an extra leaflet was added to every box explaining how to use this "feature."
- Chris Kirby