Playing For Real: Gotta Glitch ’em All
Jesse Porch is breaking all the rules.
Every year, dozens of expert players gather together to perform incredible feats of play as part of events like Summer Games Done Quick (SGDQ), an annual charity “speedrunning” exhibition. As the name implies, a “speedrunner” focus not merely on completing games, but in racing the clock to get through the game as blazingly fast as possible, often with special restrictions placed on the run to make things even more interesting. These runners take their craft seriously, relying on rote mastery of game mechanics and encyclopedic knowledge of game content. The result is a sort of digital poetry, with runners twisting the games to their will and following precisely designed strategies, seeking every last opportunity to shave a few seconds off their overall time. This self-imposed game on top of a game is exactly the sort of “serious play” that this column loves to examine.
While some runners focus on optimizing based on the game’s mechanics to achieve the shortest possible time down the to the “frame”—a sub-second unit of time that represents the smallest possible advance of game state—many runners are not content with achieving the best time a game’s mechanics permit. Instead, they find ways to exploit defects within the game to attain times faster than even the best player can achieve while bound by the game’s normal rules. By pairing their exhaustive knowledge of game mechanics with an understanding of how the game’s code actually works, devious runners can pierce through the typical limitations and find new ways to explore the game. By learning to look beyond the Deep Magic of the game’s rules to the Deeper Magic that a game, as a digital artifact, ultimately follows, a runner is able to wield powers that really do seem almost magical to those who don’t know what’s going on behind the scenes.
A perfect example of this sort of run comes from this year’s Pokémon Blue “Reverse Badge Acquisition” run by speedrunner eddaket. Rather than pushing just for fastest completion time, eddaket cheekily ignores the game’s expected arc and promises instead to collect all eight gym badges in the opposite order they are normally won. Right off the bat this indicates that something special must occur, as the game rules prevent this under normal circumstances: there’s a certain assumed ordering built into the game’s progression that cannot be changed short of finding a new route through the code itself.
This article is going to be a bit more complex than usual to examine the details of how eddaket manages to use the game to break itself and ultimately make his impossible objective seem easy. I try not to assume that you’ve watched the run I’ve linked, but if you get a chance then it will definitely be worth thirty minutes of your time. Seeing these things in action is a sight to behold, especially when you understand just how complicated a process is at play to make the run possible. Eddaket and his co-host Shenanagans provide an excellent running commentary of what they’re trying to do, but given the constraints of the run many of their references, such as commenting on specific numbers, slip by without full explanation, so my hope is that this article gives enough background that watchers can appreciate what is happening behind the scenes.
The first major glitch that eddaket uses is a great case study of how exactly runners can twist the game to their will. Throughout the early minutes of the run, he constantly references certain stats as being “good”, and while he doesn’t always call attention to each action, he’s very careful to perform tasks in a specific way to make sure he has a precise number of items or moves available. The reason for this becomes apparent as he leaves Pewter City, where normally the player is forced to defeat the first gym leader, Brock. Because stopping to fight Brock now would take too long, and more importantly disrupt the whole point of the run, eddaket needs to skip this required fight and return later. Fortunately, a well-known glitch in the game called “Brock Skip” allows him to do just that. Even better, by making sure to perform the glitch with a carefully prepared party, eddaket not only skips the required fight but is granted the ability to walk through walls, making the journey beyond Pewter City safer and much faster.
How can something as simple as having a specific group of Pokémon when talking to a certain character have such dramatic implications and break the game in such an obvious way? To understand this, we need first to learn a bit of a dirty secret about videogames, indeed all computer programs: at their heart, a program is just a very long list of numbers, carefully arranged in a particular pattern, that gets read and reordered as needed by rote processes built into whatever hardware executes the program. There’s no way for the basic hardware to distinguish between a Pidgey and a pointer (a numerical reference to a specific chunk of computer memory), so when the player understands the way the software expects to operate they are able to carefully manipulate it by substituting things they can control, such as Pokémon, for things that are normally untouchable, like bits of code that tell the game how to operate. Even something as mechanical as computer code can, with the proper mindset, be appropriated by the player and turned into a playground of new opportunities rather than just another restriction.
As explained by one of the spectators, this specific glitch—known as “Brock through Walls”—occurs when the player stands at an unexpected spot and the game attempts to find directions for how to make the player walk back to the gym. Normally those instructions don’t exist, but with the party above the game is able to find what it thinks are valid directions, and it sets about acting upon them. However, because the place the game has been tricked into following what’s not actually a complete set of instructions, it begins to change things that it shouldn’t, which in this case happens to have a useful side effect of disabling the code that prevents the player from walking through walls.
Of course, while handy, this glitch alone accounts for only a small part of eddaket’s run. However, by understanding what occurs here, we get a solid picture of how the larger glitch he’s about to use functions. Because all character data is ultimately indistinguishable from raw code, anything that is able to modify any sort of in-game data is theoretically able to modify the underlying code. Normally the game’s programming limits the player’s ability to directly edit chunks of memory to specific regions that are carefully controlled. However, computers tend to do exactly what they’re told, and these protections are themselves instructions that depend on the values stored in memory, so a devious player can slip things through.
The vulnerability, in this case, happens to be the player’s backpack. Consider, for a moment, what the backpack is used for: holding a constantly-changing collection of different items, each with a variable type and quantity. To be useful, a player must be able to modify the contents of their backpack, and for convenience they would likely want to be able to move items around. Thus the game provides basic tools for adding, removing, and shifting items that are stored within the backpack. In order to track this, the game must devote memory to these items, and to protect the rest of the game it limits the backpack-tool to the modification of only the memory slots specifically devoted to the items. However, since the computer cannot tell what’s an item, we need the directions to be a bit more explicit: instead of “only modify items”, the programmer instead says to “only modify memory at this location and X following spots”, where X is based on the number of items currently being stored.
This works well, in general: if the player has 1 item, the game lets them use or discard it. When they find more, now they can use those, too. Should they throw away everything they have, X is now 0 and there’s nothing to modify any more. However, there’s a subtle flaw here, in that whenever the player throws away something, X is decreased to correspond. This works well as long as X is increased whenever an item is added, which is almost always the case. However, by exploiting another glitch, it’s possible to decouple the actual number of items in the bag from the game’s count. When this happens, the game dutifully reacts by allowing the player to use the backpack to modify X spots in memory, where X is now abnormally large and the latter spots are no longer items but important bits of data, such as the player’s current location and the code that determines how the map connects to other related maps.
This series of glitches, which the speedrunners refer to as a “soft GameShark”—a reference to a gaming peripheral that allowed direct modification of memory locations to help players break the game’s typical limitations—presents an interesting case study: a defect in the game’s rules allow a determined (and careful) player to work within the game’s systems to literally rewrite the game rules and go beyond the normal limits. This is, of course, quite dangerous, and only through trial and error can players determine the exact way to wield this power to accomplish a useful goal rather than bringing the run to an abrupt end. But with the appropriate steps, the player can break outside of the restrictions typically enforced and accomplish a variety of goals, such as winning gym battles in reverse order or capturing a specific Pokémon far earlier than the game is designed to allow.
This is a sort of playfulness that builds atop what is already a playful activity: to pursue goals that are normally inhibited by the game’s core rules, players have found ways to turn the rules that do exist and are carefully enforced by the game hardware to their advantage. A relatively common bug like a buffer underflow is the bane of many programmers, and while in many contexts such a mistake on the part of the programmer has significant security and legal ramifications, within a game it provides an avenue for a rare breed of player to demonstrate their total mastery of the game. There’s something delightful about watching an expert perform a task with such deftness, and the programmer in me loves seeing a game that is played not just with mastery of the explicit mechanics, but with such a foundational understanding of the game’s guts that the impossible becomes trivial.
Jesse Porch is a software developer who enjoys dabbling in videogame scholarship, especially the cultural role of play in ethics, empathy, and relationships. Check out his other work here.