Gamasutra: The Art & Business of Making Gamesspacer
Dirty Game Development Tricks
arrowPress Releases
October 31, 2014
PR Newswire
View All

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

Dirty Game Development Tricks

June 24, 2013 Article Start Page 1 of 4 Next

In this article from the final issue (June/July) of Game Developer magazine, game developers share their hacks, tricks, and war stories about getting the game out the door however they had to. (The complete issue is available as a free download here.)

The article is being highlighted as one of Gamasutra's best stories of 2013.

One of Game Developer's most popular features was our "Dirty Coding Tricks" bit from 2009, where we got devs to open up about some of the ugly hacks they've resorted to in order to make a ship deadline or pass certification. Well, we're back with nine new from-the-trenches stories, including a few unorthodox tricks from other dev disciplines besides programming. So read on, revel in your colleagues' ingenuity, and relax -- because you're not the only one that pulls out a dirty trick under pressure.

Crouching RSX, hidden texture assets

Joe Valenzuela, Insomniac Games

This trick was on the PS3: We on the Insomniac engine team had some textures that we wanted distributed with our engine/tools release. These were things like noise textures and source input for full-screen filter effects. For some unimportant reasons, we didn't want to distribute these as actual asset files, so instead we converted them to binary arrays and compiled them into the executable. There was one downside, though -- we wanted these to be in a different chunk of memory (RSX visible), so we would end up copying them out and just wasting the memory for the source.

The PS3 toolchain had a link feature to put certain sections in RSX memory, but it requires using 1MB pages, and in our case it would have wasted 700k. Instead, we added a new data section in the executable that aliased the bss (the "bss alias" or "balias" section). We had something like 3MB of bss in our final builds, so there was more than enough space to hide some texture assets. We ran some code as early as we could in the crt initialization to initialize the destination memory, copy the assets out, and then re-initialize the bss to 0.

Believe it or not, it worked! There was a little tweaking to accommodate hidden bss use and toolchain updates, but overall it was pretty straightforward.

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.


Jonathan Garrett, Insomniac Games

Ratchet and Clank: Up Your Arsenal was an online title that shipped without the ability to patch either code or data. Which was unfortunate.

The game downloads and displays an End User License Agreement each time it's launched. This is an ascii string stored in a static buffer. This buffer is filled from the server without checking that the size is within the buffer's capacity.

We exploited this fact to cause the EULA download to overflow the static buffer far enough to also overwrite a known global variable. This variable happened to be the function callback handler for a specific network packet. Once this handler was installed, we could send the network packet to cause a jump to the address in the overwritten global. The address was a pointer to some payload code that was stored earlier in the EULA data.

Valuable data existed between the real end of the EULA buffer and the overwritten global, so the first job of the payload code was to restore this trashed data. Once that was done things were back to normal and the actual patching work could be done.

One complication is that the EULA text is copied with strcpy. And strcpy ends when it finds a 0 byte (which is usually the end of the string). Our string contained code which often contains 0 bytes. So we mutated the compiled code such that it contained no zero bytes and had a carefully crafted piece of bootstrap asm to un-mutate it.

By the end, the hack looked like this:

 1. Send oversized EULA
 2. Overflow EULA buffer, miscellaneous data, callback handler pointer
 3. Send packet to trigger handler
 4. Game jumps to bootstrap code pointed to by handler
 5. Bootstrap decodes payload data
 6. Payload downloads and restores stomped miscellaneous data
 7. Patch executes

Takeaways: Include patching code in your shipped game, and don't use unbounded strcpy. 

Article Start Page 1 of 4 Next

Related Jobs

InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Mobile Developer C++ (m/f)
Activision Publishing
Activision Publishing — Santa Monica, California, United States

Tools Programmer-Central Team
Amazon — Seattle, Washington, United States

Sr. Software Development Engineer - Game Publishing
Intel — Folsom, California, United States

Senior Graphics Software Engineer


Juan Belon Perez
profile image
And that's why I admire Insomniac team

Daniel Accardi
profile image
Chris Pruett, marry me?

Will Buck
profile image
That is one dedicated husband, bravo to you Chris!

Aaron San Filippo
profile image
The (S)self exploitation one from Garret is awesome and scary at the same time. I worked with a guy who came from Insomniac before, and he was always going on about fixed point math hacks and stuff and some of the horrors he had seen before. Now I can appreciate all of that a bit more.

Koray Hagen
profile image
I only wish there was more. Absolutely hilarious.

Amir Ebrahimi
profile image
Re: The Dalton Allocator, I did something similar at Naughty Dog because we had to fit code and art into a 3MB (IIRC) memory block and quite frequently artists would go up to the very limit and us programmers would be scrounging around for every KB to get the level to fit within memory. Frustrating? Yes. How to solve? Mis-report the memory by 256KB :)

Aaron San Filippo
profile image
I've heard similar stories before - reserve some "shipping time" memory and don't tell the art team about it. Very efficient solution to the problem ;)

Joseph Moore
profile image
Yeah, that's a very common technique. On a DS title I worked on, we reserved a rather sizable chunk of memory on the side as a "just in case" buffer. Whenever a level designer needed a bit more memory for levels, an artist a bit more for textures, or a sound designer a bit more for audio, we could dole it out. (We, of course, made a great show of scrounging and optimizing to obtain the requested memory.) By the end of our development cycle, the buffer was nearly gone.

Brian Schmidt
profile image
Joseph--that's funny...
When I was doing Genesis/SNES music and sound, I'd do the same thing, though in reverse. My system was designed to submit a single black-box binary file to the developer. I'd always make sure my first delivery filled up my entire audio budget, even though most of the binary was empty. That way, I could "save the day" by being able to add in sounds late in the game, or by "optimizing" my audio to give some back to the developer...

Jane Castle
profile image
@Joseph Moore..... lol! You are like a memory banker loaning out memory.....

Sean Sanders
profile image
I love this series! That (s)Elf manipulation trick is the nastiest / coolest.

The "Dalton Allocator" sounds familiar. I discovered when working on a PS3 game that Audiokinetic, the makers of the audio engine we licensed, actually had a recommended knowledgebase article on streaming audio stored in GPU memory, which we exploited to great effect.

y h
profile image
hehe, very nice material, inspiring in many levels !

and I rise my hand to ask for more of these !

Leroy Sylva
profile image
I chuckled at the HR hacks story.

Jacob Pederson
profile image
I actually did something similar to Chris Pruett, with a Diablo 1 on PS1 save file, successfully moving it from emulation to the real system by copying headers.

Reverend Ted
profile image
The PC version of DRIV3R has a bug (or it seems like it has a bug) where the Cheats menu doesn't unlock after beating the game. To this day I have only a vague sense of how I managed to figure out where in the ProfileData the "triggers" were stored, but I managed to locate and unlock them by hex editing the ProfileData file (a component of the DRIV3R savegame system). Felt pretty proud of myself for that one.

David Hawisher
profile image
The EULA exploitation is HORRIFYING. And clever.

Aiden Eades
profile image
Jamming the cartridge isn't really a dirty programming trick though, it's just optimization, sure it's not optimiation in terms of speed, but it's still a form of optimization.