Bugs are the nemesis of programmers. They cause software to operate in an unintended ways and either cause funny situations or more often, frustration in users. In modern web and mobile development, we can fix bugs after they surface by correcting the code and deploying the code or updating a mobile application.
When software was distributed in physical form like game cartridges in pre-Internet era, there were no ways to provide updates to software. And for popular games published in the mid-1990s, we've had almost 25 years of time to find many of those bugs and exploit them.
But sometimes unexpected behavior in software is not necessarily a bug, at least not in the sense of "this should have or could have been avoided by programming less erroneous". Let's look at one of the examples that is very well known for its glitches, exploits and bugs: Pokemon Red and Blue.
Introduction to Pokemon Red/Blue
Pokemon Red and Green were released for the original Game Boy in Japan in 1996. Two years later, they were released to US market in 1998 and to European market in 1999 as Pokemon Red and Blue with small fixes and improvements from the Japanese games.
These games are notorious for their bugs. If you have been following speedruns or Youtube videos for these games, you might be familiar with the fact that they are full of small mistakes and larger exploits.
(If you have not, I recommend taking a look at a very entertaining Pokemon Glitch Exhibition by Shenanagans from AGDQ 2016 or JRose11's Top 10 Interesting Glitches in Pokemon Red/Blue.
Limitations of the Game Boy hardware
According to some sources online, Pokemon Red/Blue took somewhere around 375 KB of data. Huge chunk of that is in-fight sprites for 151 Pokemon, 160+ Pokemon moves, dozens of trainers and all the world map sprites for the buildings, player, NPCs and so on.
Fair to say, there wasn't much room for the code that takes care of the game logic.
Because of these limitations, many things in Pokemon Red/Blue are rather a great showcase of good software engineering. The games were written in Z80 Assembly and it operates directly with the memory of the hardware. This allows the game to be very memory efficient but it also opens it up to many exploits that work on changing certain values in memory by clever hacks.
One such approach is explained in this video. In that glitch, you manipulate the memory to change data of the map coordinates so you can warp to
That glitch also takes advantage of another approach used in saving memory: using certain memory addresses to have multiple purposes. Manipulating that data in one place and then having the game access it in another one is a good way to confuse the software.
Ramifications of these glitches
So while the basic bugs are annoying and especially huge for competitive gaming, most of the bugs, glitches and exploits are not really visible to a casual player. While it's possible to manipulate the memory of the game to do wacky things, a player needs to intentionally attempt then.
And I think that's a really important factor when weighing the importance of these oversights and bugs in general. Because while most of the bugs are annoying, some of them are not really that crucial to be fixed and some of them can even be accepted early on if it helps us build something with heavy restrictions.
Conclusion
Ever since I got interested in speedrunning and watching players take advantage of glitches (or even writing custom code like in this Tool Assisted Speedrun of SMB3), I've been fascinated by the limitations of early video games and how developers have been overcoming those restrictions and obstacles to create games and software that are way beyond what we imagine certain hardware can work with.
It's important to note thought, that having a bug that allows someone to mess with the memory of a Game Boy game is quite harmless. Having such a bug in a software that runs on a server, mobile phone or desktop can cause huge issues if that bug somehow allows the user to reach beyond the sandbox of your own app.
So don't use Pokemon Red/Blue as an excuse for not fixing your bugs but also learn that sometimes things that cause bugs might be stemming from real life restrictions and are actually great software engineering.
Top comments (0)