Gamasutra: The Art & Business of Making Gamesspacer
Dirty Game Development 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 Game Development Tricks

June 24, 2013 Article Start Previous Page 3 of 4 Next
 

Certification headache

Michael Carr-Robb-John, Monolith Productions

Anyone that has ever written a game on a console knows about the certification headache. For the most part, certification is simply common sense and good practices, but there are one or two "requirements" that just seem to be nothing more than a way to cause developers problems. One such requirement that we've had to deal with is that from the time the user chooses to run your game, you must be displaying the first presentation screen within four seconds. If you have a large executable, it can take at least two or three seconds just for it to load before you get control, and you still have to load a whole bunch of visuals and sounds in order to present the main menu.

My game was taking 26 seconds from the time the user selected the game to the time it displayed the first presentation screen, so I could already feel that headache starting. My first job was to isolate what was required to display the menus, and put off loading specific global data until it was actually needed. Surprisingly, this had a bigger impact than I was expecting; it knocked off over nine seconds. Many tweaks later, I had managed to knock it down to around 10 seconds, but I just couldn't get it to load any faster. While discussing the problem with another engineer (best problem-solving method I have ever found), the solution dawned on us.

The specific console also has another requirement that two specific screens are displayed by your game before progressing into the menu system. What is also of interest is that the user must be prevented from skipping the screens for a set amount of time. Let's see now -- if we loaded only those two screens, and did most of the menu loading while the player is watching those screens... voila -- 5.5 seconds to load and display.

Unfortunately, that still was not enough to satisfy the letter of the requirement, so we eventually had to ask for a waiver, which was granted (probably because we were so close).

Painting sounds

Edward J. Douglas, Flying Helmet Games

I was running cinematics on a long-running racing series. Our scenes were a mix of straightforward startgrids and fancier action sequences. As we iterated on further sequels, our ambitions with the scenes got greater and greater, but our technology iterated at a slower pace.

You see, the cars would be animated by a QA "stunt driver" to get the base motion, then hacked up in a 3D animation program to adjust the timing and placement of the action, and re-exported to our in-game cinematic tool where playback would simulate all the physics and engine behavior. Lots of gameplay data was captured, including gas and brake information from the controller and represented in metadata in the 3D file, then reproduced in-game. The idea was that this would drive the car audio system as well.

The problem came a few sequels down, where our scenes were very complicated, with a mix of hand-animated car action and recorded capture. The old tricks of using the engine metadata to drive simple audio rev samples for our cars wouldn't work anymore -- the data just wasn't there! The audio team couldn't post-process the audio like a movie, because any scene could have any car in it, depending on player's choice and modifications, so the audio needed to be procedural. But by this time, our games had won numerous awards for audio, especially for the car engine sounds, so we were determined to make it work.

Coming on to beta, things were looking dicey, but a combination of ingenuity and madness between our cinematics, audio, and AI engineering teams found the solution. The gas and brake metadata was represented by a float scale on a cube in the 3D scene. If an artist went in and "drew" curves in a keyframe editor like 3DS Max, they could draw in the car engine sounds they wanted. A few members of the audio team rushed to learn 3DS Max, and by using their intuition of how rev patterns should look, they drew in the animation, exported all the scenes, and squeezed it all in in time. It sounded great, but after this last-minute hack, we knew we'd need something more robust if we'd continue with the same tech-base for the next sequel.

...Or so I thought. I left the studio after that game, and a few years later I met an audio guy who had joined that team after I left. It wasn't long before I realized they never upgraded the tech, and he was the "engine rev painter" guy for the latest sequel. 


Article Start Previous Page 3 of 4 Next

Related Jobs

Red 5 Studios
Red 5 Studios — Orange County, California, United States
[10.24.14]

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

Gameplay Programmer
Gearbox Software
Gearbox Software — Plano, Texas, United States
[10.24.14]

Server Programmer
Forio
Forio — San Francisco, California, United States
[10.24.14]

Web Application Developer Team Lead






Comments


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.


none
 
Comment: