Seventeen years ago, Brandon Sheffield put together the classic "Dirty Coding Tricks" collection on Gamasutra (http://www.gamasutra.com/view/feature/132500/dirty_coding_tricks.php), Habr translation here, along with "Developers share their most memorable dirty coding tricks" (https://www.gamedeveloper.com/programming/developers-share-their-most-memorable-dirty-coding-tricks) — featuring a camera rotated 90 degrees instead of fixing the renderer, a space added to the code just to make a checksum match, and two megabytes of memory stashed away "for a rainy day" so they could be triumphantly produced a week before ship.
Since then, those collections have been quoted to death — I've even found some of these tricks in the code of real projects — and the genre took root not just among game developers. I think the programming crowd fell in love with these stories because they so often recognized themselves in them: their own deadlines and shameful hacks that might still be spinning away somewhere in production.
This article is a lighthearted continuation of that collection, with stories in the same genre — American studio legends, eighties classics, and Russian and Soviet gamedev with its own special mood. Some of the tales are unverified and I couldn't find any sources; some turned out to be genuine tall tales, but ones so convincing that the legend ultimately beat reality in the most literal sense, ending up in the code of an actual game.
I'll try to credit the storyteller when the memories belong to someone else, and if a story only exists as folklore, I'll flag it as such. As you'll see, the difference sometimes matters. So, off we go — I hope it turns out to be a fun read...
About the battery...
"Super Time Force" by Capybara Games was built entirely around a time-rewind mechanic: if the player died, they could rewind time and then run alongside their own past copy — and there could be a lot of those copies. From the engine's point of view, this meant the state of every object had to be stored for every moment in time, and since memory was a perpetual headache on the Xbox 360, hacking this mechanic wasn't hard.
During certification, QA filed a bug: if you mashed all the buttons at maximum speed for two minutes, then rewound time, then repeated... and repeated again, the game crashed. It's perfectly normal for testers to file bugs like this... what's not normal is what happens when you sit down to fix them.
Crashes during certification can't be waived by any amount of pleading, especially a crash found by the vendor's own internal testers, so certification was a bust. Welcome to a retest in two weeks. And with a month left until release, "properly" fixing a core gameplay mechanic guarantees blowing that very release — so the team started detecting inhuman input speeds, and if the player was pressing buttons faster than an ordinary human physically could (testers being a separate, malicious subspecies of gamer), then it was either a tester or a monkey banging a controller against its cage, and in both cases the game could pretend the player accidentally slipped up and died. The player dies, part of the timeline buffer collapses, memory is freed, everyone's happy.
But Microsoft's testers are no fools either, and seeing such a brazen mockery of the effort they'd spent finding this very cunning bug, they found another one — this time overloading the timeline with a huge number of explosions, which of course also obeyed the game's time-rewind laws. Release was getting closer, something had to be done, so as memory approached the limit, a "controller battery low" dialog would pop up on screen and the player was politely booted back to the level-select menu, even if the controller was fully charged.
QA, seeing the familiar system dialog, closed the bug, accepted the fix, and the game passed certification. This story was told by the studio's technical director, Kenneth Yong.
About the importance of FPS counters...
The developers of a racing game (probably Burnout 3: Takedown, judging by the timing, the studio, and the person who tells the tale) ran into a complaint from testers that the car handled differently depending on whether an FPS counter icon was drawn on the virtual dashboard. I'm not sure about the icon... They couldn't find the cause of this behavior, and in the master build, where the counter was gone, the cars were described as "jittery" — meaning the FPS counter was somehow affecting the car's physics.
Two weeks of engineering work, digging through the physics, hunting for variables that depended on the stack state after the font was drawn, checking timings and the update order of subsystems... none of it turned up anything. The cause was never found, and the game shipped with the frame counter permanently enabled, printed just off the right edge of the screen. Millions of players played a racing game that had an invisible widget in the corner dutifully printing two little numbers and — by the sheer fact of its existence — fixing the physics and the handling.
Martin Turton, who worked at Criterion Games at the time, told this story specifically in the context of developing the PlayStation 2 and Xbox versions. According to Martin, the difference in the physics engine's behavior came down to the fact that rendering text (the FPS counter) changed the state of memory or the cache, which somehow "aligned" the timings when working with VSync, on which the game's physics calculations were tied. A vivid example of the Heisenbug genre: if you don't understand the cause, then nail down the effect that fixes it.
About invisible squirrels...
Titan Quest had no timer system for quests, and any trigger fired instantly on the next frame after activation, so the ability to "wait three seconds and then open the door" simply didn't exist. The feature was requested near the end of the game's development, which was an almost impossible task, because it dragged a rework of the entire quest system along with it.
A tester helping with the scripts discovered that a delay could be obtained through the duration of the spawn animation for game creatures, which could have script triggers hung on them. You wait for the animation to finish, you get your trigger. The chosen timer was a squirrel — a decorative critter that in the game just ran around for looks, and now its invisible version started working across the levels as timers, measuring out the necessary delays through animations.
These harmless rodents became the standard timekeeping mechanism in a commercial RPG, and to this day, somewhere in the Greek forests of Titan Quest, crowds of invisible squirrels still dwell and conscientiously... tick. For his ingenuity, the guy was awarded an honorary tambourine and the title of supreme designer, and a dirty hack became a standard mechanism in the game. Told by the owner of Crate Entertainment, Arthur Bruno.
About a second of silence...
While working on Mega Man Legacy Collection for the 3DS, the developers caught a bug in the sound system that they were never able to track down. The very first sound in the game, when the studio logo was displayed, stuttered or didn't play at all, and after that everything worked perfectly — only the first sound broke.
Debugging showed that the "channel is playing" flag in Nintendo's audio API considered the channel busy for the first sound started in the game, even though nothing was physically playing. It could have been anything, from an initialization race to a firmware quirk depending on the phase of the moon, so before the first real sound the game played one second of silence.
The silence stuttered and heroically failed to play, while the logo's sound came second and played just fine, and that's the fix they shipped with. Told by Keith Kaizershot, and I'm almost certain that dozens of audio programmers around the world independently invented this trick, more than once. On one of our projects we also had a "silent alert" sound that mobs could hear but the player couldn't — that's how a mob told everyone around it that it had been shot at. Silent sounds are generally one of the oldest patterns in game development, letting you alert nearby enemies, open doors, launch scripts, and even close quests, but that's... a whole other story.
About level 256...
The level counter in Pac-Man was just a single byte, so level 256 was stored as 255 (0xFF). Drawing the fruit at the bottom of the screen took the level number and added one, but on level 256 the 255+1 overflows to 0, and the game starts drawing garbage from unrelated regions of memory on the right half of the screen. This level was impossible to clear, because you couldn't see the dots you needed to collect.
Namco's developers figured the rising difficulty would keep anyone from making it to level 250, so they simply never wrote overflow handling. The first "perfect game," reaching level 256 (3,333,360 points), was officially credited to Billy Mitchell in 1999.
About 4 seconds...
The time to complete a level in Donkey Kong is calculated as 10×(level+4), but on level 22 this limit works out to 10×26 = 260, which with an 8-bit counter gives 4 — meaning the player has only ~4 seconds left, which physically isn't enough to run to the top, and Mario dies.
For 44 years this level was considered unbeatable, until in February 2025 the speedrunner Kosmic cleared it for the first time via a glitch of climbing a "broken" ladder plus lucky barrel timing. So the legend of its unbeatability turned out to be not quite true, and the game can be beaten without any "modifications." A good example of how even a "rock-solid" bug can, decades later, still give way.
About someone else's API...
The studio Backbone took on the job of porting six Midway arcade games to the early PlayStation 3 in a matter of weeks, but the problem was that the code of these games — which had previously come out on Xbox Live Arcade — was not at all cross-platform and was buried up to its ears in DirectX.
Several weeks of suffering and rewriting each game's render layer for the PS3's new graphics API culminated in the team partially implementing the DirectX API itself on top of the PS3's video system. From an engineering standpoint in game development, an emulation shim for someone else's API is a legitimate porting classic of the eighties, but from a legal and certification standpoint, you don't bring it up in meetings with the platform holder.
The author of the story, Ian Sherman, recalled that the team spent the final week of the project covering their tracks, renaming functions and scrubbing from the build every mention that could have identified the foreign API calls. The games shipped, and the PS3 spent nearly a year pretending to be a little bit of Windows, until the renderer was fully reworked for the platform's API.
About buried games...
Atari bought the rights to "E.T." from Spielberg for around 25 million dollars at the end of July 1982, and the programmer Howard Scott Warshaw was given only about five and a half weeks to develop it instead of the usual six months to a year, so it would be ready for Christmas.
The game came out in December 1982, flopped, and became one of the symbols of the 1983 video game crash. Legend had it that Atari buried the unsold cartridges in a landfill in Alamogordo (New Mexico), and for decades nobody believed it — even Warshaw himself considered the story a tall tale — until a public excavation confirmed it on April 26, 2014. Later, one of Atari's managers, James Heller, clarified the scale of the tragedy: it wasn't "millions" of cartridges but around 728,000 units (a total figure; E.T. supposedly made up 10% of the volume). But an unconfirmed fact remained about two other confirmed burial sites, because the total number of E.T. cartridges produced was on the order of 5 million, of which about 1.5 million were sold, while ~3.5 million vanished into the unknown.
Another such site is thought to be a plant in El Paso, where game cartridges were ground into scrap for further recycling. When Atari's management saw locals hauling away pieces of the dump, they ordered everything to be covered over with concrete, but local teenagers in 1983 still slipped past the guards and brought back dozens of crushed but still working cartridges.
About the most stubborn bug...
Dave Baggett (Naughty Dog), one of the two programmers on the first Crash Bandicoot, wrote the save code. The tale is sometimes attributed to Andy Gavin, the second programmer and co-founder of the studio.
Occasionally, writing to the memory card would fail on a timeout, and since the write wasn't transactional, a failed attempt would wipe the player's entire card. That is, the bug didn't just interfere with saving — it physically destroyed saves from other games.
Baggett methodically cut out chunks of code until almost nothing was left but bare engine initialization and the write call, but the bug still sometimes reproduced. In other words, there was barely any code left, and the bug was still there. The cause turned out to be in the hardware: when the guys, for the sake of the most accurate physics simulation possible, set the PS1's programmable timer to one kilohertz — a thousand interrupts per second — whereas by default it ran at a hundred hertz.
This excessive timer conflicted with the data exchange over the controller ports with the memory card, which occasionally led to data loss, and the write operation broke. A classic case of perfectionism in one system breaking a completely different one that has nothing to do with it. And so here too, tuning the bandicoot's jump physics was killing the memory card — and just try finding a connection like that while staring at the save code.
About DOOM's dad...
From the book "Masters of Doom" by David Kushner.
At fourteen, the young John Carmack decided he needed an Apple II from his school. The break-in was organized with characteristic Carmackian thoroughness — the office window was pried open using a thermite mixture — but the "operation" failed.
Carmack ended up in a psychiatric evaluation and a year in a home for troubled teens, and world gamedev got its chief engineer with an already-formed reputation as a difficult teenager, for whom obstacles are of a purely technical nature.
About the DOOM that got banned...
When this pair of geniuses were bolting network play onto DOOM, they made the first version of the netcode on IPX, which simply broadcast packets of data — meaning every game state update was received by every machine on the local network, including ones that weren't playing any DOOM at all and were, in fact, the accounting server.
A four-player deathmatch would put an entire campus network to sleep under a storm of broadcast packets, and within a week of release, system administrators all across America had learned to filter DOOM traffic and ban machines running the game. Universities banned it by decree, and the long-awaited network feature — the one that spawned the very term deathmatch — worked, at first, like a DDoS attack. Not many games can boast that their patch notes were written under pressure from the accounting department's sysadmins rather than from players.
About nuclear Gandhi...
You probably know the legend... The story goes that in the first Civilization, the peaceful Gandhi was given a minimum aggression of one, and when India switched to democracy the leader's aggression dropped by two and went negative; the unsigned byte overflowed, the one turned into 255, and the greatest pacifist in human history began pelting his neighbors with nuclear gifts. The story spread so widely that it's still cited as a textbook example of integer overflow — at the very least, I myself heard exactly this version.
But Sid wrote plainly in his memoirs that there was no such bug in the original Civilization, that it couldn't have existed, and that the integer variables were signed, so an unsigned overflow from one-minus-two simply couldn't have happened. And even if the value had by some miracle become 255, aggression was used in the game as levels 0-1-2, so 255 would have just meant a two, and Gandhi would have behaved as usual. There isn't a single confirmed piece of evidence for a "dirty Harry" in the original 1991 game, and the meme itself took shape on forums and wikis only in the 2010s, after the fact.
But the legend turned out to be so convincing that in Civilization V they deliberately made Gandhi the most likely candidate to use "delivery systems," and the developers, knowing the meme, decided to play along. And so a made-up bug became a real feature, even if only after the fact.
About psychopathic cops...
A DMA Design project under the working title Race'n'Chase was about top-down car chases with cops in an open city, but the chases turned out rather bland, and the publisher was mulling over whether to shut the whole thing down — but then His Majesty "Chance" intervened. The pathfinding on the police cars broke, and during a chase they started trying to ram straight through the player, cutting across sidewalks and oncoming lanes, causing more chaos than the player themselves.
Run into cops like that and the boring chase quickly turned into mayhem, flattened pedestrians, and a demolished city, and the testers — who just yesterday had been yawning through playthroughs — started fighting over a seat at the test machine. The psychotic police were such a hit that they decided not to fix the bug and instead built a whole chase mechanic on top of it, shifting the game's focus from racing to criminal freedom, and giving the world Grand Theft Auto.
And so a single AI bug effectively set the DNA of the most commercially successful series in the history of games. Now, every time a crazed police sedan comes flying after you in GTA, remember the bug with thirty years of aging.
About beans and a god simulator...
Before games, Peter Molyneux and his buddy Les Edgar ran a goods-delivery company and, among other things, shipped canned beans to the Middle East. The company was called Taurus, and it had about as much to do with gamedev as beans do with a compiler.
Commodore confused their Taurus with a networking software firm called Torus, and on the wave of this mix-up offered the future fathers of the god-game genre a dozen free Amigas. Molyneux, by his own recollection, was in no hurry to clear up the misunderstanding and signed the papers before anyone could change their mind about giving away free computers.
It's worth noting that almost this entire story is known from Molyneux's own account, and he's famous for his love of a good retelling, so I won't vouch for the factual accuracy of the computer beans. When the newborn studio needed a name, they picked it from a frog figurine sitting in the office, on whose base was the proud inscription "Bull Frog by Leonardo." That's how the legendary studio got its name.
And Populous, which spawned an entire genre of god games, was assembled out of Lego, when Molyneux and his comrades laid out terrain with blocks and moved little plastic figures around. Admittedly, he later confessed that this did nothing for the game's balance and mostly worked as an excellent media hook and advertising. That, however, in no way diminishes the role of chance, when a studio that gave the world a whole spread of new genres in the form of Syndicate, Theme Park, and Dungeon Keeper grew out of someone else's clerical error, a children's construction toy, and a plastic frog.
About the extra letter...
In Aliens: Colonial Marines there was a typo in the file PecanEngine.ini — in the class-remapping line for the bots, the word Tether (a behavior binding for the AI) was written as Teather with an extra "a." The engine looked for the correct bot behavior class for Tether, didn't find it, and the xenomorphs' "hunt-binding" parameters reset to default behavior, so the aliens wandered around like drunks, got stuck in walls, or stood there like posts while being shot.
The typo was found by a modder (jamesdickinson963), and "PC Gamer" and "Kotaku" reproduced the fix by deleting the one letter, after which the AI noticeably came to life, starting to walk normally, flank, dodge shots, and even climb along walls, which of course is not at all how Aliens are supposed to behave.
It should be noted that the effect of this was in places on the verge of a placebo, because the game was still bad for a whole host of other reasons, from muddled core mechanics to frankly weak AI and unimaginative level design. So it's not right to present it as "one typo killed the whole game," and it would be more accurate to say that "one typo switched off a noticeable layer of AI behavior." The publisher never officially patched the game.
About six-minute loading times...
In February 2021, a programmer going by the handle t0st (GitHub tostercx), fed up with six-minute GTA Online loading times on PC, dug into the store-connection logic with a disassembler and found two bottlenecks. In the first, the game parsed an almost ten-megabyte JSON every time the page refreshed (the store catalog, ~63 thousand items) via sscanf, which internally called strlen on each element, turning the parse into O(n²). The second spot was right there in the duplicate-item check, which ran a simple search for each of the 63 thousand elements, again leading to an N² search.
t0st wrote his own DLL that injected into the process and redirected both spots to optimized variants, cutting load times by about 70% (from ~6 minutes down to ~2), and published a detailed breakdown on his site. Rockstar later confirmed the problem, rolled the fix into update 1.37 (March 16, 2021), thanked t0st in the patch notes, and paid him a $10k bug bounty as an exception.
About bugs and champagne...
Matthew Smith's Jet Set Willy came out on the ZX Spectrum in 1984 and quickly became a hit, with one small problem: it was physically impossible to beat. The culprits were several unrelated bugs, one of which overwrote important game data, causing one of the required items to disappear. The developer simply never played through the whole game before shipping and didn't notice the problem, and the publisher signed off on it all, satisfied that "well, the main path works."
The game came with a contest, and the first person to beat it was promised a case of Dom Pérignon, a helicopter flight, and a meeting with Matthew Smith himself. As a reminder, the game couldn't be beaten. The publisher, Software Projects, when complaints started pouring in, first tried to pass the bug off as an intentional feature, but when the number of complaints about the game being impossible to beat climbed past several hundred, they finally admitted the bug.
The winners of the contest turned out to be two players, Ross Holman and Cameron Else, who — despairing of ever beating the game and winning the coveted case of bubbly — dug into the code, proved that completion was impossible, and wrote the fixes themselves. And then they went on to beat the game they'd fixed with their own hands and called the publisher with proof; their fixes later formed the basis of the official patch.
They did get their prizes after all, and this is, it seems, the first documented case of a community patch that was paid for in champagne and a helicopter.
About Perestroika...
"Perestroika," from 1990, written by Nikita Skripkin, was the perfect product of its time. The company "Nikita" would be named after the author and founded only a year later, in 1991, so the familiar credit "a game by the studio Nikita" was actually running a bit ahead of events.
In the summer of 1989, the author was handed the idea of making something in the spirit of Japanese TV shows, where contestants race across logs and platforms over water; the country's political moment made its way into the design document, and the result was a political satire in which a "democrat" frog hops across a swamp on lily pads that represent laws and decrees, collecting consumer goods and hard currency while avoiding a progressive tax and dodging "bureaucrats" and various malicious characters that try to catch it. On the title screen, to round out the picture of the era and advertise the core gameplay mechanics, they drew Gorbachev against the backdrop of a breached Kremlin wall, set to "Dubinushka."
The game's mechanics were simple and "sticky" — the phrase "addictive gameplay" hadn't been coined yet — and all the content lay right on the surface; you just had to look out the window. Few games managed to get such a powerful response so cheaply in a Union that was bursting at the seams.
About the wolf and cartoons...
"Elektronika 24-01/Nu, pogodi! (Well, Just You Wait!)," also known as "The Wolf Catches Eggs," was the first mass-produced Soviet handheld game with a segmented LCD screen, produced from 1984 and costing around 25 rubles. It was an unofficial clone of the Nintendo EG-26 "Egg" from the Game & Watch line, both in hardware and in mechanics.
Among kids of the 80s, and the 90s too, there was a persistent legend that at 1000 points the game would show the cartoon "Nu, pogodi!" (Well, Just You Wait!), even though this was fundamentally impossible on a segmented display, where every section of the picture is hardwired into the screen. The real "bonus" for 1000 points was far more modest and consisted of resetting the score and speeding the game up by about a third.
About space and rangers...
One of my favorite stories from post-Soviet gamedev. Dmitry Gusarov taught programming in Vladivostok and single-handedly made the strategy game "General," which came out in 1999. The game turned out very respectable, and after release his mailbox was overflowing with letters from enthusiasts who wanted to make games, and that same year he put together the studio NewGame Software — with the developers sitting in different cities across the country and assembling the game by correspondence, over the slow and expensive internet of the early 2000s.
They chose the space theme because space was simply easier to draw. A black background, dots for stars, sprites for ships, and none of your running animations, faces, or dragons with proper skinning.
The signature text quests, the soul of the series, appeared almost by accident, when one of the members wanted to program something — since he was studying to be a programmer, after all — and Gusarov came up with a mini-game for him about landing on a planet, in the spirit of old text adventures with multiple-choice answers. He made the first such quest himself, then a whole community of authors plugged into the quest engine, and a side experiment grew into a core mechanic that fans of the series remember first and foremost.
It's said that the music was written remotely and blind, because the composer had no access to the build and the internet didn't allow sending builds around. Because of this, the melodies had to be composed from screenshots that were sent over. The plot, too, was thought up last, because what mattered most to Gusarov was a living world that played itself without the player, not a story — and when it became clear that a plot was needed after all, it turned out no one on the team knew how to write one. They had to bring in a separate person, who delivered a coherent concept about the Klissan.
About games on paper...
In the eighties, the mass gaming device in the USSR was not computers but programmable calculators, like the Elektronika B3-34, MK-54, and MK-61 (which I had too — or rather, my dad did). The magazine "Tekhnika Molodyozhi (Technology for the Youth)" ran a column called "Electronic Games Club," where every month they printed... hmm... new games, and the word "printed" here is absolutely literal. A game was distributed as a listing on a page in the magazine, and since the calculator had no data storage medium, the game had to be re-entered into memory from scratch every time you turned it on, keying in the instructions on the keypad. This loading screen lasted about twenty minutes and demanded care, because a typo on step forty-seven would be discovered, at best, by the program crashing — and at worst, never.
The entire richness of the platform was limited to roughly a hundred program steps and a dozen and a half memory registers, if memory serves — for comparison, even the Atari 2600 with its 128 bytes had orders of magnitude more room to maneuver.
The hit of the column was "Lunolyot," a clone of Lunar Lander, and I first read Mikhail Pukhov's science-fiction story without the listing, which explained what to do and why, and then I saw the listing in the magazine and something clicked in my head. You had to control a craft with a limited fuel supply, entering thrust and engine burn time, and you had to land it on the Moon at a speed no greater than five meters per second, otherwise it was G-force overload and the death of the crew. On the calculator's display there were only digits: altitude, speed, remaining fuel, while all the graphics, all the landscape, and all the drama of the landing happened in your imagination.
A large community grew up around this game within Pukhov's cycle "The Path to Earth," where even the error message on the display — the famous EGGOG — became part of the folklore and got an in-universe explanation. In essence, this was gamedev where the graphics engine was your own head, and distribution ran through the print shop and physical paper.
So the next time someone tells me you can't make a game today without Unreal, a budget, and a publisher, I'll just show them a listing from "Tekhnika Molodyozhi (Technology for the Youth)" and a photo of my ten-year-old self with a calculator.
I won't break with the traditions of this genre, so if you have similar tales, share them in the comments — and if they come with a source cited, all the better.
Links, in case anyone wants to go hunting for bugs, flaws, and discrepancies:
https://www.gamedeveloper.com/programming/developers-share-their-most-memorable-dirty-coding-tricks
https://en.wikipedia.org/wiki/Burnout_3:_Takedown
https://www.gamedeveloper.com/programming/my-hardest-bug-ever
https://beza1e1.tuxen.de/lore/crash_bandicoot.html
https://davidkushner.substack.com/p/prepare-to-meet-thy-doom
https://doomwiki.org/wiki/Broadcast_packet_meltdown
https://en.wikipedia.org/wiki/Nuclear_Gandhi
https://www.gamespot.com/articles/sid-meier-confirms-nuclear-gandhi-is-sadly-just-a-/1100-6481941/
https://www.grandtheftwiki.com/Race’n’Chase
https://www.destructoid.com/grand-theft-auto-only-exists-because-of-a-glitch/
https://www.filfre.net/2016/06/peter-molyneuxs-kingdom-in-a-box/
https://handwiki.org/wiki/Company:Bullfrog_Productions
https://www.techinsider.ru/technologies/1738689-pochemu-amerika-soshla-s-uma-po-igre-perestroika-sdelannoi-v-sssr/
https://hypestorm.ru/perestroika/
https://dtf.ru/avi/1057195-kosmicheskie-reindzhery-istoriya-serii
https://habr.com/ru/post/176485/
https://pacman.fandom.com/wiki/Map_256_Glitch
https://en.wikipedia.org/wiki/Billy_Mitchell_(gamer)
https://errors.fandom.com/wiki/DK_kill_screen
https://www.gamesradar.com/games/donkey-kong/after-44-years-donkey-kong-player-discovers-that-the-legendary-kill-screen-isnt-really-the-end/
https://www.pcgamer.com/all-this-time-aliens-colonial-marines-stupid-ai-may-have-been-caused-by-a-single-typo/
https://techraptor.net/gaming/news/coding-typo-ruined-xenomorph-ai-in-aliens-colonial-marines
https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/
https://www.techdirt.com/2021/03/18/modder-solves-gta-online-loading-time-problem-gets-paid-rockstar-it/
https://dubikvit.livejournal.com/23894.html
https://droider.ru/post/volk-lovit-yajcza-sovetskoe-nintendo-razbor-05-09-2022/
https://edition.cnn.com/2014/04/27/tech/gaming-gadgets/atari-et-video-game