The 1986 Nintendo game Metroid is known for its impressive world map: it was immersive in that it offered a large world for players to explore, and yet also foregrounded its algorithmic nature when bugs generated maps the creators did not design. In the fan community, both intended and accidental maps have been significant sources of interest. The map's code provides a useful example for applying Wendy Chun's idea of "source code as fetish" to interpreting video games and new media artwork. This concept of code-as-blueprint becomes useful when the software under consideration is a form of artistic expression more than a tool for getting work done, like Linux or the ClimateGate code. Building on Chun's analysis, I argue that thinking of source code as fetish—that is, as an ideal artifact that yields a myth of control—offers us the chance to interpret games as a matter of how the intent of the author is borne out in the actual execution. To this end, I outline strategies for reading authorial intent from code, and how it might be a useful interpretive category. In doing so, I attempt to make explicit an unstated assumption in new media criticism: that authorial intent is the a significant interpretive category for interpreting a programmed artifact.
A lot of people find this series of hexadecimal digits fascinating. We call these people "fans." It's the world map of the 1986 Nintendo game Metroid. Because of the many ways it has been interpreted (and misinterpreted) by both machines and people, the code provides a useful example for applying Wendy Chun's idea of "source code as fetish" to interpreting video games and new media artwork. Chun's critique of source code as fetish is a useful response to claims that open-source software is better than closed-source software, because we are able to view and modify source code as if code alone determined how a computer is used. I think, then, that Chun's idea should help us to understand the source code as a blueprint that stands opposed to the actual execution of a program. This concept of code-as-blueprint becomes useful when the software under consideration is a form of artistic expression (a term I use loosely) more than a tool for getting work done, like Linux or the ClimateGate code. Building on Chun's analysis, I argue that thinking of source code as fetish—that is, as an ideal artifact that yields a myth of control—offers us the chance to interpret games as a matter of how the intent of the author is borne out in the actual execution. To this end, I would like to outline some strategies for reading authorial intent from code, and how it might be a useful interpretive category. Metroid will be my example because of the peculiar way its code has become visible in the fan community.
In doing so, I attempt to make explicit an unstated assumption in some criticism of digital media: that authorial intent is the ultimate determiner of the meaning of a program. Janet Murray implicitly makes such a claim in Hamlet on the Holodeck, describing the Woggles, a group of animated characters designed to express believable personalities. Most observers were most fascinated by one Woggle, Shrimp, because he occasionally banged his head against the ground. Observers would "build psychological theories, always incorrect, about Shrimp's mental state and seem to find him much more interesting and alive for having this behavior" (Murray 232). The idiosyncrasy, however, was the result of an elusive bug. Murray consequently writes off Shrimp's strange behavior because of its creators' failure to trace his actions to specific lines of code. Critic and game designer Ian Bogost also claims that authorial intent in video games is a necessary category for understanding them, stating "videogames participate in the struggle between authorial intent and interpretive freedom" (Bogost 123), but does not explain how we might know the author's intent. In Bogost's games that simulate social situations, we seem to glean authorial intent from a game's promotional materials or introductory screens, like with the website of his FedEx employee game. Both Murray and Bogost invoke the figure of the author without dwelling on it.
How, then, might we analyze games with interesting bugs but without stated rhetorical purposes? Metroid is such a game: a game with a bug as accidental as Shrimp's behavior, but a bug which nonetheless has probably consumed more player time than the time it takes to play whole other games. I submit that players can—and do—read an authorially-intended meaning into Metroid's code, and from this, those players determine a counter-narrative that emerges from an accidental execution (which we also know is accidental from the code).
To explain my position, I will describe and interpret Metroid. The player plays the role of Samus Aran, an intergalactic bounty hunter sent to an alien planet to destroy the space pirates, as well as their leader, the "cybernetic entity" Mother Brain. Samus must augment her own powersuit with various extensions to gain different abilities. In the last boss battle with Mother Brain, Samus confronts a cybernetic horror: a brain in a vat dependent upon life support systems and automated weapons for survival. Mother Brain represents technology run amok. The game's ending screen confirms this interpretation: if the player finishes the game in less than three hours, Samus appears without her powersuit in a purple leotard. If the player does it in two hours, Samus appears in a bikini. Therefore, I read this ending as a warning to the player to moderate their use of technology: Samus uses one technology (her suit) to defeat another technology (Mother Brain), and then appears without any technology at all. Samus's de-suiting and undressing shows that the hero is human underneath it all.
That's not all the undressing shows. The irony is thick: the possibility of seeing Samus in a further state of undress was a powerful temptation to the adolescent boys, who made up a big chunk of the target market, to play again. While the game ostensibly warns players not to play too much Nintendo, it simultaneously rewards the players for playing even more. In this way, Metroid is not unlike other Nintendo games of the 1980s. These games tended to trumpet the dangers of technology, and expressed a desire for it to remain transparent and hidden. Many Nintendo games are set in pre-technological worlds (such as Super Mario Brothers and The Legend of Zelda), but the ones that take place in modern or futuristic settings (Contra, Metal Gear, or Metroid) tend to present cautionary tales about technology. It's a rare game that sympathizes with a cyborg character (Mega Man is one of the few I can think of). These games display anxiety about the seductive power of technology and show how cybernetics might undercut human freedom. They place the player in the role of one heroic human blowing up evil machines. Machines are sometimes even explicitly associated with Communism, as in Contra and Metal Gear. The games insist that good people—and especially citizens of the world's democracies—must remain in charge of technology, though the company will do what it takes to keep you buying their products. The managerial myth of the all-powerful programmer is complemented by the marketing myth of the all-powerful user: both purport to be in charge of machines, whether by writing code or choosing which they use and how much. These games project the fantasy of the all-powerful consumer as a cornerstone of democracy, and yet this message rings hollow given that they are games telling us games are bad.
There is more than one way to play a game, though, and players found another way that resists this contradictory message by exploiting a bug. Samus's suit can roll into a ball to fit through narrow passages; going into ball mode raises her sixteen pixels off the ground. Usually, the physics engine drops her back to the ground, but if she is standing in a door that closes over her, she does not fall. If a player rapidly goes into and out of ball mode in a closed door, Samus keeps rising and can ascend through a room's ceiling. Doing this in some areas takes players to strange rooms.
This discovery began to circulate among fan websites in the 1990s; one site opened what it dubbed "The Great Secret World Hunt." A retrospective the site later wrote described the players' fascination:
These areas were glitchy and didn't make much sense in terms of layout, but if one knew where to look, they were accessible. They became known as the "Secret Worlds." For a long time, nobody knew why the secret worlds were there—were they intentional? Was the game originally meant to be larger? (Hansen)
Gamers posted descriptions of 40 different secret worlds. A few years into the hunt, though, a player named Kent Hansen wrote a Windows utility for hacking Metroid. In exploring the source code of the cartridge, he discovered the map I showed at the beginning, which reveals the secret of the secret worlds: there was no room for them in the map.
Hansen explained the secret worlds' origin as a glitch. The game's graphics engine creates each screen out of patterns, constructing each room from the master schema I just showed: a series of two-byte chunks that represent each room. The game adds variety to its large map and saves memory by swapping out tile patterns at various times, dividing the map into distinct "worlds" with different tilesets, but because of memory and processor constraints, it places the player on an elevator on a black screen to transition between worlds to give the new graphics time to load. Going through the ceiling, however, might take the player to a room in another world without doing the graphics swap. The world would therefore be drawn with the graphics of the world they were just in, and look very different from how it would appear if drawn with the correct tiles. (Hansen)
Hansen's appeal to source code explained the origin of the secret worlds to most gamers' satisfaction, but they continued exploring, and searched for similar bugs in sequels to Metroid. His discovery helped reify another way to play: hunting for secret worlds turns a game of subduing technology into an exploration of the possibilities of an algorithm, pushing the map engine to create worlds its creators did not imagine and showing the adaptability of even a relatively simple program.
We need to know, however, what the original game intended in order to give the alternate method of play its meaning of resisting authority. We must find a knowable intended execution to identify when it fails. I'll outline why I think we can identify the secret worlds as a bug with relative certainty from the code itself. I am using the code from a ROM image, disassembled and annotated by Hansen. Since the game was originally programmed in assembler code, the source code that I have mirrors almost exactly what the programmers wrote with fewer conceptual leaps between source and output.
We may distinguish between the intended and unintended executions of the game because the code that operates during normal gameplay is fairly straightforward, while the reasons for the secret worlds come to light only after extensive study—in fact, it took me a long, long time to trace the exact path that causes them. The two bugs that cause them result from the interaction of a large number of subroutines: first, Samus climbing the wall, and second, the map parser parsing the world map incorrectly. Explaining why these bugs happen will make it clear how unlikely it is that they happen in the first place. First, Samus can climb the walls as the unintended consequences of several routines. The most important ones are CheckMoveUp, SamusStand, and SamusRoll. As its name suggests, CheckMoveUp is one of the game's four general hit-testing routines. Each frame of a sprite's animation has an offset for the sprite to be moved, which also moves the object's position and happens without hit-testing. These are the four frames of the animation for Samus to enter ball mode. The second and third frames raise her sixteen pixels off the ground for a dropping effect. The word FC indicates that the next two bytes contain sprite offsets; in the second frame, the first (F here) indicates the Y-offset and the second the X-offset. The fourth frame lowers her back to the ground. To climb the wall, the player has to transition rapidly in and out of ball mode; completing the transformation to ball mode traps the player in ball mode in the wall.
Now, ordinarily, CheckMoveUp should prevent Samus from coming out of ball mode if there is a tile immediately above her, even if she is still in the transition state. However, the height of Samus that CheckMoveUp uses depends on the active event handler at that moment. This is where the event handlers SamusStand and SamusRoll come in: one of these is called as the handler for Samus depending whether she is standing or in ball mode. When the player presses the button to enter ball mode, the transformation begins, but until the transformation is complete, SamusStand remains as the handler routine. The transformation takes several frames. Because both modes use CheckMoveUp as a hit test routine, Samus' height and the distance to check is determined by the event handler. If SamusStand calls CheckMoveUp instead of SamusRoll, the calculation is performed as if she were still standing, even if the transformation has began. When the transformation is cancelled and Samus is in a wall, she bumps into the block above her head, but the transformation animation has already moved her up, so she gains height. The convergence of disparate routines—and code reuse—causes a bug. This result thus seems unintentional because the steps are spread across many different routines.
Additionally, with the exception of this bug, the mapping code never enters another zone without doing a tile swap. The reuse of the map code that creates the secret worlds is clearly unintentional because it only happens via exploitation of another bug. Therefore, we label this reuse of map data from one zone as unintentional.
The interpretive strategies I am pursuing here, then, involve the explicitness of the instructions, and how often a particular programming technique is used. I read the secret worlds as a bug or bugs because of the separation of the routines responsible for entering them and generating them; SamusRoll appears at addresss D0C9 in the object code, CheckMoveUp at E7A2, and the animation table, which is in a completely different bank from the main program code, from 88AD-88D8. The other is the rarity of use of one technique, the reuse of map data from other worlds without a palette swap. Therefore, I think that these can be safely identified as bugs because of the haphazardness and rarity of their use. They are bugs, and knowing that they are bugs makes them interesting, rather than simply leftover bits of data.
Playing the secret world hunt, then, opposes the myth of the all-powerful programmer and the domination of technology. The code becomes visible—to the players—as a description of what should have happened, and becomes interesting when it does not work as designed. The source code takes on the role of fetish that Chun describes: it shows us a desire to capture time with space, and it fails. When used in the practice of playing games, this idea of source as fetish helps us juxtapose the role of the player and the programmer and understand the complexities of their interaction. It replaces the all-powerful programmer and the all-choosing user with a more complicated series of relations: user and programmer who mutually articulate the uses of technology and the role of code.
Bogost, Ian. Unit Operations: An Approach to Video Game Criticism. MIT Press, 2006. Print.
Chun, Wendy Hui Kyong. Programmed Visions: Software and Memory. Publication Forthcoming.
Hansen, Kent "SnowBro." "Metroid Level Data Explained v. 1.01." http://mdb.classicgaming.gamespy.com/m1/lvldata.htm. Last visited 3/20/01.
Metroid Database, The. http://mdb.classicgaming.gamespy.com/m1/secretworlds.htm. Last visited 3/20/07. Includes subpages.
Nintendo Corporation. Metroid. Video game and source code. 1986. Disassembled by Hansen; annotated by Hansen and "Dirty McDingus" (Screen name; real name not given).
Murray, Janet Horowitz. Hamlet on the Holodeck: The Future of Narrative in Cyberspace. New York: Free Press, 1997. Print.