With the recent controversial release of Cyberpunk 2077 (a game that’s been delayed for longer than even its own developers care to admit and has undoubtedly seen some dirty coding going on in the last few months to reach that Christmas deadline), we thought it was time to peer behind the curtain of games development a little.
For Cyberpunk, cutting corners to appease waiting gamers may have done more harm than good. But that’s not always the case. In fact, sometimes a little bit of dirty coding might go completely unnoticed. Because it’s not about how dirty the code is underneath, but how presentable it is on the surface.
While dutiful game developers are constantly honing their skills and are committed to producing the cleanest and most sophisticated code, sometimes deadlines just happen and they need to dirty it up a little to get the job done. This invariably means corners have to be cut.
Sometimes, the market dictates that a game has to be on store shelves (be they physical or digital) come rain or shine and in those situations, even the best programmer might be forced to overlook certain protocols and blast through some quick code to save a project.
To underline these practices a little more clearly, we scoured the internet to find some of the cleverest (and, in some cases, most heinous) dirty developer coding tricks pulled right from the minds and the mouths of the devs themselves.
Mega Man® Legacy Collection. ©CAPCOM CO
Mega Man is one of the 8-bit generation’s most beloved mascots and his nascent adventures continue to be remastered, rejigged and re-released on a regular basis as a result. When the Mega Man Legacy Collection was being finalised for the Nintendo 3DS, however, one programmer encountered a gnarly sound bug that would see the first sound generated in every game playing like a garbled mess.
The problem appeared to be that every time the game was launched, the sound (or ‘stinger’) that accompanied the developer logo would glitch. When debugging the game, it transpired that the “playing” flag would read as true even if nothing was playing and the developer was at their wits’ end trying to figure out how to resolve this problem.
The solution? They simply loaded a single second of silence right before the developer screen. Quick, elegant and incredibly dirty! It’s the kind of solution that isn’t particularly clever or complicated but does involve a lot of thinking outside the box, and sometimes that’s one of the most important tools in a developer’s toolkit.
The Ratchet and Clank series of games have always been sleeper hits for the PlayStation, but one title that seemed to slip through the cracks was the wonderfully named online game Ratchet and Clank: Up Your Arsenal. This was back in the days when online console games were something of a rarity, and it ended up being shipped without the ability to patch code or data. Today, that would be unheard of, but this was 2004 and online console games were still very much in their infancy.
To get around the inability to patch, the devs exploited the EULA that was downloaded and displayed every time the game launched. This was an ASCII string stored in a static buffer that was filled from the server without checking the file size was within the buffer’s capacity. So, they sent an oversized EULA download, which overflowed the static buffer enough to overwrite a known global variable: in this case, the function callback handler for a specific network packet.
Once this handler was installed, they could send the network packet to cause a jump to the address in the overwritten global. The address was a pointer to 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, patching work could begin. A complicated workaround, for sure, but again, this was 2004!
PS2 - Jedi Starfighter Official Trailer. Ahhhh the memories
There are more Star Wars games than perhaps any other franchise in existence and around the era of the PlayStation 2, with the original prequel trilogy still fresh in people’s minds, there were dozens of games released to double down on the force fever. One such game was Jedi Starfighter, a generally well-reviewed flight simulator.
While it was being readied for final submission, however, the devs found that the analog sticks on the controller would shut out automatically when loading post-mission cutscenes. The problem would have been relatively easy to fix if the programmer who wrote the movie-loading code and the code for the controller hadn’t left the company months beforehand. Time was of the essence with two days to the submission deadline, and the team simply didn’t understand the code they were being faced with.
So, they inserted seven screen clears in various colours into the code they thought likely to be the source of the problem. This way, they thought they could narrow down the problem by checking what colour the screen was when the analog sticks shut off. But then when they tried to reproduce the bug it appeared to have been solved. They’ll never understand how they did it exactly, but to this day it’s a fault that has remained undiscovered.
While in the era of the cartridge it was almost impossible to pirate a video game, the PlayStation - and the era of CD-based games it brought along with it - was rife with piracy almost from the get-go. This was something developers became aware of quickly but few found a reason to take preventative measures, assuming that was up to Sony. The developers of Spyro 2: Year of the Dragon, however, had another idea entirely.
Just before shipping the game, they decided to write code that was able to ascertain whether or not a player was using a genuine or pirated copy. This went above and beyond a simple line here and there though. Indeed, they even went so far as to write dialogue specifically for the pirates.
The game began with the fairy character “Zoe” alerting pirate players that they “may experience problems that would not occur on a legal copy”. This included numerous crashes, items randomly being removed from the player inventory and (most crushingly of all) the saved game being deleted automatically should the player attempt to tackle the final boss. Nicely done!
Super Time Force - ©Capybara Games
Let’s finish with a more recent (and remarkable) example of ingenious dirty coding. Super Time Force was a hectic 2D shoot-em-up for the Xbox 360 which allowed players to rewind time. The problem was that meant the console’s memory had to be able to store all the information of every active object in the level, for every moment in time, for the entire duration of the rewindable timeline.
It might not seem like such a ‘lo-fi’ game would require that much memory but when you see the game in action you’ll understand why. The litmus test for the devs was starting any level, pressing every button on the controller as fast as possible for two minutes, then rewinding and doing it twenty more times. They could have delayed the game and gone back in to rebalance every level individually, but they had a better and dirtier idea.
They coded the game to detect extended periods of unreasonably fast button pressing and self-destruct the player as a punishment. They made the bug into a gameplay feature that actually made the game feel more balanced and less ‘spammy’. They also installed a hidden rewind ‘limit’ that told players they were running ‘low on batteries’ and booted them back to the menu when they went too far with the rewinding. The memory limit was reached so seldom that the devs never heard a peep out of a disgruntled player. Truly the archetypal dirty coding success story!
If these stories have inspired you to get down and dirty with your own coding and you need a decent rig to do so with, get in touch with Novatech today.