![A man gives a thumbs up while holding a broken vase fixed with tape in front of TVs.](https://i.kinja-img.com/image/upload/c_fit,q_60,w_645/53f67fe3300f10d64f3dae372971adde.jpg)
Did you know all the horses in Assassin’s Creed 1 are built using really fucked up human skeletons? Or that Titan Quest used invisible squirrels as in-game timers? All of this is true and is more proof that games are mostly wild collections of code and hope that have more in common with miracles than they do with software.
Video games shouldn’t work at all. This is what I’ve learned after reading stories shared by devs about making games and all the tricks and hacks used to get these things running. These tales of hacked-together solutions have always been around, but a recent viral tweet about invisible squirrels being used as in-game timers has led to a new wave of stories emerging online that show, once again, how video games are mostly held together with tape, magic, and some sticks.
For a great example of this, let’s start with a tweet from Charles Randall, who worked on the original Assassin’s Creed. He shared two interesting developer hacks about hidden arms and fucked up horses.
It turns out, in Assassin’s Creed, the team didn’t have the budget to create a special, custom skeleton rig for fellow assassin Malik. So, when the character loses an arm, it’s actually still there, but just inside out. Randall explained that if you clipped the camera into his model you’d likely see a “tiny little scrunched-up arm inside the bicep.”
Another, wilder AC1 hack involves the game’s horses. Randall explained that horses in the game were created out of “twisted fucked up” digital human skeletons rigs because, at the time, the team’s tech only worked properly with bipeds.
“Cheers to the amazing animators and riggers that managed to make that guy look like a horse,” tweeted Randall.
On Twitter, game developer Luke Parkes-Haskell shared a simple fix that was used in Fable: The Journey, the Kinect-only Fable spin-off released back in 2012. According to Parkes-Haskell, the team encountered a problem right before shipping the game.
The issue: Certain grass and water materials wouldn’t properly render in the game. Instead, players would see the game’s default gray checkerboard textures used by the devs during development. But with time running out before launch, the team figured out an elegant and quick fix. They just swapped out the default dev texture from checkerboard gray to flat green. Problem solved and the game shipped.
Dark Table shared a story about how they worked at a studio where the engineers weren’t able to provide the designers with timers or any way to delay triggers or sequences. They did, however, have access to falling objects which featured physics and collision. So they hacked together their own timers by dropping in-game boxes off-screen from different heights to trigger events using the objects’ collision.
While they didn’t feel comfortable sharing the name of the studio or the Dreamcast game in question, Dark Table shared a funny story with Kotaku about testing the game on 50hz TVs.
“I believe the primitive physics system was frame-rate dependent,” Dark Table explained. “So when they first did testing on PAL TVs (50hz) instead of NTSC TVs (60hz) all of the timers in the game were off by a bit. I think this was actually when the engineers first discovered what the designers had been doing (and it was too late to change it).”
Rolf Klischewski, a dev who worked on The Settlers III, shared how the team was able to ship the game despite massive desync problems when playing online. After spending weeks looking for a fix, one day the error message confirming a desync had just stopped appearing. According to Klischewski, the CEO praised the coders for their hard work. But then he revealed what really happened:
“Few of us knew that one of them had just REMmed the error message.” In other words, someone added a bit of text to the code to make the error message go away, which doesn’t really fix the problem, but it does let you ship the game. It’s the game-dev equivalent of placing some duct tape over the “check engine” light on your car.
Artist and game developer Alex Zandra shared a story about a small motorcycle game she made that featured roguelike progression. As she told Kotaku, her track-building system used pre-built vertical level chunks and then placed them together to create a seamless track players would then race across. All of this happened during the loading of the level.
However, there was a problem. Every single time a level was generated, it would place an extra, unintended and large wedge section at the very end. Realizing that it would take too long to rewrite the code to fix this hard-to-solve bug, Zandra went with a different, less “elegant” hack.
![A screenshot that shows a cartoon motorcycle driving up a small hill.](https://i.kinja-img.com/image/upload/c_fit,q_60,w_645/8ce72ede7469e13337d9a996a8af90c5.jpg)
“I just left that in and instead made a little bit of code to destroy the odd block out,” explained Zandra.
“Technically when a level begins that weird oversize ramp block is there at the end, but thankfully it’s too far ahead for the player to see it, and my extra code finds it and deletes it before it even comes on-screen. Not exactly elegant, but it works!”
Sometimes these game development hacks can be summarized in a few words or a single tweet. However, Nate Purkeypile, a former Bethesda dev, had a more involved and wild tale of video game hackery to share concerning the fantastic Fallout 3 DLC, Point Lookout.
The problem he encountered was that at one point in the DLC, the team needed a mansion to explode. Seems simple enough. You blow it up. If you’ve played the DLC, you likely didn’t think anything of it. They blew it up and that’s that. But oh… there is so much more to it. Because of how the engine in Fallout 3 worked, Purkeypile and the small group making Point Lookout were unable to trigger events far-off from the player. Anything in the distance you see was just a static object.
The solution to this involved using one piece of already existing tech in the main game: repurposing the system used to blow up Megaton in Fallout 3.
Despite the mansion being right in front of you, Purkeypile explained to Kotaku that it “had to be of that ‘distant explosion’ object type” used in the destruction of Megaton in the original game. “Otherwise we would just always have a house there when you’re far away. So this workaround let us then turn off that “explosion house” (that was just a house and NOT an explosion) after the mansion actually blows up.”
Or to put it another way, Purkeypile stated: “So yeah, counterintuitively, after it explodes, we turn off the fake “explosion” house.”
You might be wondering why the team didn’t have the resources to create what they needed. Purkeypile explained to me that, at the time, Bethesda was fairly small. And most folks then were working on Skyrim. So the DLC teams had to figure out interesting and cheap ways to use already existing tech and assets to solve problems like blowing up a mansion.
Taylor Swope, a designer at Obsidian, shared how the team made NPCs appear on monitors and screens in its RPG, The Outer Worlds. It turns out that whenever you see someone speaking to you on a screen or monitor, the character is actually nearby in a separate room decorated to look like the area they should actually be in when sending the message.
Swope explained to me that this is a common trick that can be found in many other games. For example, I’ve seen this myself when no-clipping and exploring levels in Valve’s Half-Life 2.
As for why devs use this option instead of pre-rendered video files, Swope explained to me it mostly comes down to file size.
“Video files get real big, real quick. So not having to include them in the game files is a plus,” said Swope.
“For games like The Outer Worlds, there’s also a lot of player interaction involved in conversations like this, and so the sequence playing out on the screen needs to be able to respond dynamically.”
“We could theoretically pre-render each response in a separate video and pick which one to play based on the player’s choices, but then you’ve got even MORE video files to deal with and need to build out a new system just for that. It’s easier to just use the conversation system we’ve already built and capture the other side of the conversation ‘live’.”
Game developer Logan on Twitter shared a simple solution to a camera issue they kept running into while working on their game, Go Fly A Kite. Using a first-person perspective, the player would spawn while seated in a bus. However, this caused an odd bug.
“Essentially the player would spawn in,” Logan told Kotaku “and the player camera would try to move to its ‘docked’ position at the same time, causing the camera to do this 360-degree flip.”
Having your game start with such a wild camera move wasn’t part of Logan’s plan, but fixing it was tricky. So instead, Logan simply added a fake 2-second loading screen that plays right as the scene starts and after the real loading screen.
Finally, Georg Zoeller explained on Facebook (which was shared on Twitter with his permission) a huge number of wild tricks and hacks used by different teams across a large selection of popular games. Here are just a few of the best ones they shared:
In the MMO Star Wars: The Old Republic, all exploding barrels are filled with shrunken invisible people, as only NPCs are a valid damage source. “Yes, that’s right, someone is blown to bits every time you shoot an exploding barrel,” explained Zoeller.
“Oh, initially they were complex models with transparency applied because to many a designer, when you have a hammer, everything is a nail,” Zoeller said. “I had to write a script to find all of them because they tanked the frame rate quite badly.”
![A man holds an assault rifle and looks at a large green bush in an old retro shooter.](https://i.kinja-img.com/image/upload/c_fit,q_60,w_645/87cca7f66a7246ba35e6293a2dea3dcd.jpg)
In the military FPS, Operation Flashpoint, Zoeller revealed that the designers had “no way of making explosions.” Instead, they launched vehicles such as tanks and trucks at the ground at massive speeds to create large explosions. Apparently, on some maps, this is how they created artillery fire.
Perhaps the wildest one was in Star Wars: Knights of the Old Republic, where there was one random animal that controlled a planet, basically.
“All global quest variables on a certain planet were stored on an untargetable ambient creature,” said Zoeller. “Turns out AOE effects could still acquire the creature and kill it, breaking your game if you just happen to kill the right ambient creature.”
Sorry, your game broke because you killed the God Animal of Naboo. Video games are amazing.