Old Programs, Glitches, and Developing a Repository of Old Game Code

My first engagement with coding of any kind occurred when I was very young in the form of video games, and it was in the form of a glitch. My first game console was the Sega Genesis, and I first thought about coding through a common occurrence for those that play games, especially in those early years: the glitch.

Most of the time, when one plays games, we may not be explicitly thinking about the underlying code that assembles that game, even though it pervades every facet of that game. I never thought about games as being digital assemblages until I met my first unintended glitch. At the end of a stage in Sonic the Hedgehog 2, if one has collected all of the Chaos Emeralds and still has enough rings (over 50) after passing the end of the stage, if the player jumps, the character sprite, the titular Sonic, will light up and appear to change into his super form. However, he begins running in the air after the end stage screen begins to play. The points are tallied up, and then...nothing. He just keeps running, and the stage never progresses. I was "softlocked," the game not ending but progress completely halted because some condition is not being met, an unrecoverable situation. When this first happened, I was frustrated, thinking the game was broken. I reset the console, and I regained all of my progress after some work.

I learned to play video games before I learned to read. Since my younger years, my brain has often worked through these various systems that I encountered, from planning out my day, to how I can make an intolerable activity more interesting by treating it like a programmed task: assigning points, beating challenges, besting my previous times. It wasn't until a few years after the aforementioned Sonic glitch that I found myself experimenting with glitches intentionally in my playing.

In Pokemon Red/Blue for the Gameboy, there is a series of steps that one can take to make it so one's items in a particular slot in the inventory are multiplied to the game's max value: 256. I learned about this exploit in a gaming magazine, where they laid out all of the steps to do this process, something unintended by the game's developers, GameFreak. I felt like I had broken the rules, replicating items until I had enough to easily level all of my Pokemon to Level 100, the game's maximum level for individual monsters. But it saved me time, and when I linked in (through an analog cable) with my classmates at school, I easily won out. Until the glitch became commonplace.

In performing this glitch, one would encounter the infamous "Missingno.", a glitchy mess of sprite values that looked like a mutant Tetris piece (https://vignette.wikia.nocookie.net/pokemontowerdefense/images/c/ce/Missingno_image.png/revision/latest?cb=20180809204127). The magazine I had read warned not to catch this glitch. It would create a mess of one's save file, and the data would be irretrievable. Now that everyone had maxed out Pokemon, I became curious. I thought back to messing up my game a few years back. I had other copies of Pokemon games from that generation. I traded some of my better Pokemon to other games, and I set about ruining my copy of Pokemon Blue. I caught the Pokemon, and it let out a cry that sounded like mangled copies of the other monsters, randomly bringing up sprites from those other Pokemon. Steadily, my game became unplayable, refusing to even open the last time I tried to activate my game file. I had glitched out my entire experience, and I had to reset the game.

There are a number of reasons for this glitching problem. Ones involves "memory mapping" in those early years of limited memory and storage space. The code used in Gameboy games, often programmed in C and then transferred to binary coding on the cartridges, needed to point to specific locations in order to read what it was supposed to do.

Link to a deconstruction of Pokemon Red: https://github.com/pret/pokered

This glitch, (in)famous for those of us who played it back when, was almost like a rite of passage. Once you'd done what you wanted in the game, this was a way to push the game beyond its intended limits. After that, I found myself seeking out glitches. Could I break through this wall and walk outside of a level? Could I discover something the developers didn't want me to see? Could I crash the game purposefully? In my earlier years, this was somewhat easier, as the exploits were understood through the limited scope of the programming back then. Not to say that exploits aren't possible now (speedrunning communities are dedicated to discovering every unintended coding effect to make the completion of a game faster), but back then there was something ethereal about playing a game both within and without boundaries to the experience.

That's something I'm interested in exploring as I seek to develop games from an indigenous/queer perspective: embracing the glitch. There's something to be explored within "poor programming," or rather, programming within constraints that necessitate a certain cleverness. In the above example, Pokemon Red is a game that is both iconic and incredibly flawed. It operated as intended most of the time, but there were easily exploitable loopholes within the programming that the average gamer could stumble across and eventually foster to create an unintended experience.

As a further example, Pokemon Red was programmed within the bounds of the popular game Minecraft, glitches and all: YouTube exploration () and file (http://www.mediafire.com/file/cbu7gb2p1pbb4cv/Pokemon_Red_-_by_MrSquishy.zip/file). For one, to explore code visually and spatially is amazing (that's a separate topic that I'd like to explore in the future), but the glitches became synonymous with the game. Numerous projects have "patched out" aspects of the game for a more unified experience, but something about it feels..."inauthentic," to borrow a rather disliked and problematic term. The glitch wasn't necessarily beyond the scope of the game: it WAS the game. It was built into the very foundation of the experience; how could it be bad?

As I'm still learning to explore coding, and given the growing but limited support for looking at code from earlier consoles and games, I don't have specific snippets to share from the Pokemon series (though it can be downloaded and played with at your leisure). However, I want to explore ideas of "embracing the glitch," in a way, through developing games. Many contemporary games have employed "glitches" to a degree, though many of these are programmed and very much intended (thinking about the "Doki Doki Literature Club" game; suicide/gore warning to those interested in playing), but glitches, in a broader fashion: could programming practices be made to embrace these ghostly areas of programming? Does "clean coding" and more hierarchical thinking, when it comes to coding, smooth out some of the wrinkles that may prompt later users to play with and explore unintended sides of a gaming experience? Is an intended glitch still a glitch?

I have more thoughts, but I want to leave it here for now.