It looks like you're new here. If you want to get involved, click one of these buttons!
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.
Thanks so much for sharing this.
I have seen Minecraft redstone computers implemented in Minecraft before, but wasn't aware of control block programming. While watching the video at first it wasn't clear to me what was at stake in (apparently) projecting an emulated gameboy screen into a large Pokémon stadium VR environment.
The "a ha!" moment for me in the video is when they leave the stadium through the tiny hole in the floor and begin a behind-the-scenes tour of the source, in which every line of code in the reimplementation exists as a block floating in space.
Just the aesthetic effect of the vista (setting aside the labor involved) is breathtaking. It reminds me of experimental game spaces and in particular sublime architectural vistas in games like Shadow of the Colossus, Kairo, Naissancee, or (perhaps most especially) DeadCore. The sense of purposiveness from the Pokémon Red Minecraft implementation is in some ways like seeing a circuitboard design -- even if one doesn't know why the forms repeat and vary in the ways that they do, but one has a sense of design and intention, even if it is illegible (perhaps I am calling back to circuitboard cityscape from The Crying of Lot 49 here).
One of the things that interests me about this is that, in order to author code that will run on Minecraft-as-a-platform, one must spatialize code in some way. If this is done using the Minecraft GUI as an interface then I imagine that the authoring practice is laborious -- and the resulting structures may seem baroque. However, the idea of code logic as spatial environments resembling circuit-boards is also an old aesthetic tradition in cyberpunk and VR. Being able to fly through a code landscape and reorganize blocks of it like masonry has, for some parts of science fiction, been desirable in and of itself. I'm thinking for example of how much flying through Pokémon Red Insiide Minecraft looks like VR hacking scenes in the cinematic adaptation of Gibson's Johnny Mnemonic (1995):
For our reference I am attaching the code here in case the MediaFire link expires.
That film was in the back of my mind, but I didn't remember it until you mentioned it.
Seeing the ways that he was able to work through the older code of Pokemon and implement it using this feature in Minecraft made me realize that developing a codebase of older generation games would be valuable to future projects that want to play with an re-engineer older code bases for various projects. I've been doing some research and am looking to post some of the things I've found concerning older platforms and code dumps that could be useful in looking at these platforms in new lights.