"No, your controller was not really low on batteries."
November 29, 2017 10:46 AM   Subscribe

Developers share their most memorable dirty coding tricks Developers behind video games such as Super Time Force, Mega Man Legacy Collection, Titan Quest, and others solved pesky problems with dirty coding tricks. Here's how they did it. (Warning: features ambient squirrels)
posted by Servo5678 (34 comments total) 42 users marked this as a favorite
 
That FPS counter slightly affecting the physics code makes my ankles hurt.
posted by RobotVoodooPower at 11:02 AM on November 29 [9 favorites]


Several of these sound like the classic hack when you're making pancakes: instead of trying to get the conditions perfect before you start, throw the first batch away.
posted by Mapes at 11:05 AM on November 29 [7 favorites]


These are great! My closest contribution: We were coming up on deadline on the Toy Story Animated StoryBook, and we were coming up against the amount of video we could store on the CD ROM. Video compression was a hugely compute intensive process, so once a clip was baked in we were super loathe to change anything.

We'd created a new codec that had an additional compression layer to try to solve the disk space problem, but this one animation clip was triggering an issue on the Windows version of the codec.

I spent a week sleeping under my desk trying to shave cycles off the codec and figure out why it was only the Windows version that was causing the problem, until we realized... duh: we could re-compress one of the earlier clips with the newer codec, and just compress this one clip with the older codec, and everything would work fine.

Sigh. I blame sleep deprivation.
posted by straw at 11:05 AM on November 29 [10 favorites]


I've always liked this clever bit of asset reuse in Skyrim.
posted by tobascodagama at 11:19 AM on November 29 [15 favorites]


I remember talking to a AAA sports game veteran who told me about a particularly onerous access bug that was preventing cert. The solve? #ifndef private public - Turn all the private variables everywhere to public ones. You probably paid 60 bucks for that game!
posted by GilloD at 11:26 AM on November 29 [5 favorites]


That FPS counter slightly affecting the physics code makes my ankles hurt.

Saint's Row 4 has that issue- in the scene where you're piloting the ship to escape the mothership while Haddaway's "What Is Love" plays, there's a scene where you have to boost past a closing gate or crash the ship into it. If your FPS is low enough, you literally cannot go fast enough and will die every time.
posted by Pope Guilty at 11:26 AM on November 29 [4 favorites]


See: SMB bushes are palette swapped clouds.

(Goombas are also palette swapped mushrooms)
posted by tocts at 11:28 AM on November 29 [4 favorites]


Not exactly in the same realm, but I spent a lot of time getting JS & CSS to work on IE6 with a bunch of dumb hacks like this, so I love hearing articles like this about similar hacks.
posted by Aleyn at 11:28 AM on November 29


Saint's Row 4 has that issue- in the scene where you're piloting the ship to escape the mothership while Haddaway's "What Is Love" plays, there's a scene where you have to boost past a closing gate or crash the ship into it. If your FPS is low enough, you literally cannot go fast enough and will die every time.
That sort of problem (frame rate affecting the physics) is not uncommon in games. What was crazy about the situation in the article was that displaying the value of the frame rate was affecting the physics.
posted by dfan at 11:34 AM on November 29 [4 favorites]


I enjoyed this article, and I've learned a useful lesson: so many of life's problems can be solved by invisible squirrels.
posted by tallmiddleagedgeek at 11:35 AM on November 29 [14 favorites]


I'm pretty sure when EA was dealing with poorly coded commentators on their Madden games, their hack was to sign up Nantz and Simms (and then Collinsworth), because they're not that different in reality and nobody would notice it.
posted by lmfsilva at 11:43 AM on November 29


Invisible critters are a standby of several games.
posted by Pope Guilty at 11:45 AM on November 29 [9 favorites]


Invisible critters are a standby of several games.
I came up with the same solution (I guess everyone reinvents the wheel) in Ultima Underworld, where our creature state was much larger than our regular-object state. I wanted to have a door yell at you and start a conversation when you opened it (it was a wizard that had decided to turn himself into a door, which seemed like a funny idea for some reason), but as soon as I tried to implement it I realized that there was no place to attach a conversation ID to a door. After a bit of head-scratching, I realized that I could just attach the conversation to an offstage creature (I choose a rotworm) and trigger it when the door opened. It always tickled me that no one ever knew that they were "really" talking with a rotworm.
posted by dfan at 11:54 AM on November 29 [23 favorites]


In my field (multimedia programming for legacy embedded systems made by literally hundreds of manufacturers), we have to do these things all the time. I’ve been doing it for sixteen years, so I know a bunch of tricks. If these tricks weren’t necessary my job would be automated away by now for sure.

Just three weeks ago I shipped a master that plays three seconds of silence upon load so that the client’s logo isn’t garbled upon playback; a master that tweaked an audio file at the individual sample level to ensure no digital artifacts when the sound looped in he buffer; a master that has its physical asset placement carefully arranged so that players that interpret the platform spec in completely incompatible ways will work the same; and a master that has physical-level discontinuities during changes from loud and visually busy content to soft, still content so it can seem “seamless.”
posted by infinitewindow at 12:13 PM on November 29 [8 favorites]


There is really no way to know for sure whether the physical universe also uses invisible squirrel timers.
posted by Jpfed at 12:13 PM on November 29 [38 favorites]


> What was crazy about the situation in the article was that displaying the value of the frame rate was affecting the physics.

I had to deal with a similar problem in a browser-based app a couple years ago: QA was reporting Internet Explorer bugs that nobody could replicate, even in Internet Explorer. The root cause turned out to be console logging -- Developers would test their work in IE with console active, QA would not. IE would only implement the window.console method if the dev tools pane was open when the page loaded, otherwise script execution would halt the moment Javascript invoked a console method. This should not have been be surprising to those of us who'd had to develop for IE versions before 9, but sometimes hindsight is faulty.

We couldn't ban or bulk-remove console use. Certain log activities had to be retained because Customer Support was using them to diagnose problems in the field, and the codebase was too large to hand-groom. So to forestall having to swat a million IE-only bugs I wrote a preload utility that would decorate window with an empty console object if none was found (this fixed the problem of IE only selectively supporting the console object), and then test console for every method I could find listed in MDN and all browsers' developer documentation sites, and construct an empty method of the same name if no match was found. This addressed the problem of console not being a standard (which it wasn't until earlier this year) and as a fringe benefit it effectively allowed all browsers to "support" all methods; developers could freely use any uncommon browser's console method they felt like and the app continued spinning, and that was sufficient to pass QA.
posted by ardgedee at 12:18 PM on November 29 [10 favorites]


There is really no way to know for sure whether the physical universe also uses invisible squirrel timers.

Tell Daphne to run a 199 on a possible Doolittle
posted by flabdablet at 1:07 PM on November 29 [7 favorites]


This is wonderful. I was literally rolling around (on the bed, not the floor) laughing at the invisible timing squirrels.

And of course there's the classic Fallout 3 Train-Hat.
posted by Zarkonnen at 1:20 PM on November 29 [17 favorites]


I worked in a mud where the mob scripting system didn't do math, I implemented a series of unlinked noteleport rooms to act like an abacus (mob would go from room to room and drop or pick up beads to do calculations)
posted by idiopath at 1:26 PM on November 29 [19 favorites]


And of course there's the classic Fallout 3 Train-Hat.

The ending slideshows in Fallout New Vegas are spoken by an actual NPC that's hidden outside of the players locked camera. Instead of scripting in a disembodied voice they just spawned an NPC and used the existing dialog scripts.
posted by nathan_teske at 1:32 PM on November 29 [8 favorites]


I always liked the way Barney in Half Life said "boop boop boop" when typing in security codes instead of having the keypad play the sound.
posted by rhamphorhynchus at 4:20 PM on November 29 [3 favorites]


That sort of problem (frame rate affecting the physics) is not uncommon in games.

My impression (not really knowing anything about the actual nitty gritty of game programming) is that computation of world state and rendering are typically (maybe even effectively always?) coupled in time, since decoupling the two and having the renderer poll the world state on its own schedule, asynchronously, is basically never worth the hassle. That is to say that I'd expect frame rate to affect game state, though not necessarily physics (since, again making an assumption that the game world's physical state is a function of time, a slower frame rate would just amount to sampling the state less frequently [which could I guess lead to aliasing issues, but this heap of assumptions and implications is swaying pretty aggressively in the wind now]). I'd definitely be curious to hear if any of this actually pans out in the real world.
posted by invitapriore at 5:35 PM on November 29


Yeah, world (state) updates are typically run at the tick rate (timestep) or some ratio of. But imagine a naive programmer, knowing that the tick rate is 30 Hz and the run speed is 9m/sec, e.g. 0.3 m/tick.

if (isRunning) playerPosition += 0.30m;

Ooops. You have to calculate per-tick increments based on the tick rate!

if (isRunning) playerPosition += runSpeed * secSinceLastTick;

You can easily run into problems when some things are based on the wall clock ("this door closes in 30 sec") and others are (accidentally or not) based on ticks ("we run at 0.3m per tick").

There are a lot more complicated issues than this, but I hope it shows the point.
posted by introp at 6:19 PM on November 29 [2 favorites]


I think most emulators have solved this problem by now, but the tick rate used to be a huge problem for certain old games played on newer systems. See, a lot of times a game's tick rate would depend on how fast the CPU could process the tick...
posted by tobascodagama at 6:59 PM on November 29 [1 favorite]


idiopath, I thought I knew you for a second there, but then realized my friend wouldn't have put up with that shit, he'd rewrite the scripting engine to support math operations.

He did, after all, upon becoming a builder on one mud he played for a while, nearly immediately implement an online build mode for said mud. He's never been one to fuck around. I suppose that's why he now leads a team writing industrial control software for a living. Every time I talk to him there's at least a bit of ranting about legacy bugs.
posted by wierdo at 7:55 PM on November 29


wierdo: this is something I did while I had build UI access but not source code access. In fact, after seeing what I built using the build commands, they figured the CPU of the server would be happier if they just gave me source code access :P
posted by idiopath at 8:00 PM on November 29


There's a guy on YouTube whose channel is at least half explaining 20 year old software hacks he did for various Sonic games, among others:

Environment mapping on the Saturn for example. It's fascinating how simple effects end up when they're broken down into their component parts.
posted by Kyol at 8:14 PM on November 29 [3 favorites]


From the Fallout 3 Train Hat article linked above:
...when you actually board the train... the player is equipped with a piece of head armor that covers the field of view and looks like the inside of a train... but you really just have a helmet on.

I would like an inside-of-a-train helmet, please.
posted by LEGO Damashii at 8:20 PM on November 29 [2 favorites]


idiopath, lack of source access was not a problem. One need not actually run the code on the server to fix said code and submit a patch. ;)

You think security is bad today..shit was the wild west back in the 90s. Nobody thought twice about leaving things world readable back then, sooo...you can imagine the many routes to access things that were not necessarily intended to be public. Also, one of the difficulties of youth is a lack of impulse control. Thinking back, I always wished I had been around for the golden age of the phone phreaks. Only now do I realize I had the privilege to live in an era where that spirit was still alive and well on the early Internet. Funny how you never realize what you had until it's gone...
posted by wierdo at 9:02 PM on November 29 [1 favorite]


In the superhero RTS Freedom Force, modders added a whole bunch of custom superheroes and superpowers. They created stretchy punches (Mr. Fantastic, Plastic Man, Martian Manhunter, a Green Lantern giant energy fist, etc.) by taking the standard beam weapon, slowing it down, and replacing the energy beam sprite with a drawing of a fist and an elongated arm.

But you couldn't predict from what angle a player would view the sprite (energy beams were all symmetrical so it didn't matter), so frequently the thumb would be on the wrong side and it looked awkwardly twisted around or like a left hand coming from the character's right arm.

I realized that if you instead drew the side view of a fist, it would look right from any angle, looking like an uppercut if the player's viewing angle caused the sprite to be displayed upside-down. I made a bunch of them in whatever colors modders requested for various characters, and used similar principles to make lassos (a slow stasis beam that triggered "surrounded by ropes" FX if successful) that also looked pretty good from any angle.
posted by straight at 11:36 PM on November 29 [5 favorites]


I have something more on the game physics being tied to frame rate thing. Most game physics simulations don't even attempt to be continuous, but update the physics with discrete steps and check for collisions and other events only on each update. Being physically accurate is computationally too expensive for real-time games, when an efficient and inaccurate solution can be tuned to look and feel right with some assumptions about the update rate and the range of values where the calculations give reasonable results.

When the assumptions break down due to the updates happening too infrequently or too often, unexpected things can happen. Slow update means less frequent collision checking resulting in different collision parameters, and can even cause collisions between fast moving objects to be missed. Fast update means that accumulating values get updated more often with appropriately smaller values, and floating point inaccuracies can add up over time to diverge wildly from the results a typical update rate gives.

Basically, typical game physics engines try to tell you convincing lies. When they have to work out of their normal operating range, they make up crazy shit.

You can fix your timestep and decouple the physics update rate from the display frame rate , but many games for whatever reasons don't implement the fully developed method in the linked article, or something equivalent. I imagine things get a lot more complicated in on-line multiplayer games for one.
posted by primal at 12:50 AM on November 30 [3 favorites]


What primal said. In addition, even without any of those issues, if an object is moving with non-constant velocity (it's accelerating or curving or whatever), as objects are prone to do, then running physics by computing its new state every timestep will give different results depending on how finely you divide up time. (The most naive way of doing this, Euler integration, is particularly bad, but even more sophisticated methods of projecting physical state forward in time will have issues in some cases and eventually diverge from "reality".)

One more issue has to do with the most important object, the player. If the frame rate is twice as low, and physics is being calculated per frame, your controls are being applied to your object half as often. As long as the physics is remotely reasonable this won't actually mean that you accelerate half as fast or anything, but it will affect your ability to control yourself.
posted by dfan at 6:39 AM on November 30 [2 favorites]


When I was taking these screenshots, I noticed every time I hit the hotkey the engine would stutter for an instant, and while the ball would appear where it should be on the next frame draw, the players wouldn't. I could easily get an ace on every serve by taking a screenshot.
posted by lmfsilva at 7:09 AM on November 30 [5 favorites]


Slow update means less frequent collision checking resulting in different collision parameters, and can even cause collisions between fast moving objects to be missed.

Oh man. I wrote a simple Asteroids-like game futzing around with a thing and this was such a pain in the ass. Fast bullets plus fast ship equals bullets travel through the whole ship from tick 1 to tick 2 and no collision for you!
posted by tocts at 10:07 AM on November 30 [1 favorite]


« Older No Pressure   |   X Gonna Sleigh Bell Ring It To You Newer »


You are not currently logged in. Log in or create a new account to post comments.