We understand games by playing them. Card games, board games, videogames — their idiosyncrasies and dynamics become clear not when we read the instructions, but when we play them. Play is, as Katie Salen and Eric Zimmerman describe it, “free movement within a more rigid structure”  [Salen & Zimmerman 2004, 304]. We bump up against this rigid structure — rules, boundaries, mechanics — and reveal the contours of the game, slowly uncovering what Lev Manovich calls its “hidden logic”  [Manovich 2001, 222]. This is play. This is how we come to know games, by experiencing them. Like all cultural activities, however, games can be approached through means apart from the experience itself of playing them. Games can be played, but they can also be interpreted. The early years of videogames studies were defined by this tension. Were games mainly about rules, structure, and play? Or did games tell stories and contain allegories? Self-proclaimed ludologists argued for the former, while many others defended the latter. The debate played out in conferences, blogs, and scholarly journals such as Game Studies and Electronic Book Review (e.g. [Eskelinen 2001], [Aarseth 2004], [Jenkins 2004]). In the past few years the debate has largely dissipated, with most scholars in the field recognizing that no single approach can adequately explore the cultural significance of videogames. Yet I want to advance an approach to videogames that, in light of this reconciliation, might at first appear to be retrograde, a reactionary doubling down on the position that videogames are texts. I don’t mean metaphorical texts, using that word haphazardly the way literary scholars like to describe everything as texts. I mean texts in a literal way, comprised of words, or at least, of numbers and letters. I am referring to the code of the game. Videogames are pieces of software, made of code, and I argue that thinking about game code as a signifying text is a fruitful way to enrich our understanding of videogames. To illustrate this methodology I will consider the code of two games — Micropolis (2008), which is the open source version of the legendary simulation SimCity (1994), and the notorious first-person shooter JFK: Reloaded (2004). In particular I will focus on an aspect of the games in which the signifying excess of code is palpable: the procedural logic of crime and the shock of history found in programmer comments in code.

My insistence on the importance of code follows a recognition that for too long new media studies has suffered from the symptoms of what Nick Montfort calls screen essentialism [Montfort 2004]. Screen essentialism occurs when the “digital event on the screen,” as Matthew Kirschenbaum puts it, becomes the sole object of study at the expense of the underlying software, hardware, storage devices, and even non-digital inputs and outputs that make the digital screen event possible in the first place [Kirschenbaum 2008, 4]. One response to this essentialism is found in Katherine Hayles’ call for media-specific analysis of creative works. A media-specific analysis attends to a work’s materiality, which Hayles formulates as “the interplay between a text’s physical characteristics and its signifying strategies”  [Hayles 2004, 74]. A media-specific analysis is an important intervention into screen essentialism, but it privileges the manifestly present elements of media. What about digital works with characteristics beyond the physical — or at least, beyond the visible — that nonetheless influence how that work circulates within culture?

Nick Montfort and Ian Bogost’s development of platform studies presents one answer to this question. Unlike typical screen-centric approaches to born-digital works, platform studies considers both the software and hardware of systems, exploring the relationship between these hidden foundations and the more visible creative and expressive acts that appear on the surface of the machine. Every platform is a composite of chips, circuits, controllers, software, storage devices, and so on. And each of these individual components offers affordances — capabilities that are both enabling and limiting. A platform studies approach reveals, for example, that the Atari VCS’s unique Television Interface Adapter constrained playfield graphics in a way that shaped the look and playability of games themselves, the Atari 2600 adaptation of Pac-Man being a dramatic example of this dynamic [Montfort & Bogost 2009, 67–75]. Chips and other hardware constraints also affect what kind of software can be executed on a computer, making computer code a critical part of platform studies.[1] Without code, a computer is inoperable, inert. But the significance of code goes beyond its purely computational power. In a recent examination of the parallel configurations between the development of UNIX and changing race relations in 1960s America, Tara McPherson hones in on code as an especially relevant site of cultural engagement for scholars. Using the UNIX pipe command to dramatize the modularity found in many social fields since 1968 — including urban segregation and academic departments — McPherson demonstrates that code is deeply intertwined with culture. The difficulty is that with its emphasis on modularity and interfaces that distance the programmer from the kernel of the machine, “the structures of code work to disavow these very connections”  [McPherson 2012, 36].

Textual studies, with its awareness of the social and material history of texts, perhaps comes closest in traditional humanities scholarship to the spirit of both media-specific analysis and platform studies. The concerns of textual studies — attentiveness to physical forms, recognition that hands other than the author’s shape the text, an almost forensic desire to trace the history of marginalia, errata, and variants — have their analogs in emerging strains of new media studies. It should not be surprising, then, that I will revisit much earlier notions of what McGann calls “the textual condition” as I examine computer code in a gaming context [McGann 1991, 3]. The late German media theorist Friedrich Kittler has argued that, as Alexander Galloway phrases it, “code is the only language that does what it says”  [Galloway 2006, 5]. But my close reading of code insists that code not only does what it says, it says things it does not do. Staking out the territory of a field he calls critical code studies, Mark Marino describes code “as a text, as a sign system”  [Marino 2006]. Code may speak to a machine, but it also speaks to us. It is a rich textual object, layered with meaning. “Code may in a general sense be opaque and legible only to specialists,” as Rita Raley notes, “…but it has been inscribed, programmed, written. It is conditioned and concretely historical”  [Raley 2006]. Here, then, are the two sides of code I will explore as I seek to understand these two videogames — Micropolis and JFK: Reloaded — as extensions of our textual condition. First, code’s performative power, or what may be more accurately called the procedural power of code. Second, code’s evocative power, rife with gaps, idiosyncrasies, and suggestive traces of its historical context. Approaching code in this twofold fashion, it becomes clear that the more a programming language emphasizes human legibility, the greater the chance there’s some slippage in the code that is readable by the machine one way and readable by scholars and critics in another.

Consider the case of Micropolis, the open-source version of SimCity that was included on the Linux-based XO computers in the One Laptop per Child program. Designed by Will Wright, SimCity was released by Maxis in 1989 on the popular (though nearing the end of its life cycle) Commodore 64. It was the first of many popular Sim games, such as SimAnt and SimFarm, not to mention the enduring SimCity series of games — that have been ported (the programming equivalent of translation) to dozens of platforms, from DOS to the iPad. The videogame behemoth Electronic Arts now owns the rights to the SimCity brand, and in 2008, EA released the source code of the original game under a GNU GPL License — a General Public License that stresses the freedom of users to share and modify the program’s source code. EA prohibited any resulting branch of the game from using the SimCity name. The developers, led by Don Hopkins — who had worked on the first Unix port of SimCity in 1992 — called it Micropolis, which was Wright’s original name for his city simulation [Hopkins 2007a].

According to Hopkins, Will Wright was once asked by a journalist how much urban planning theory, demography, criminology, and sociology went into SimCity. Wright replied simply, “I just kind of optimized for game play”  [Hopkins 2007b]. Indeed, from the beginning, SimCity was criticized for presenting a naïve vision of urban planning, if not an altogether egregious one [Bleecker 1995], [Friedman 1995]. As recently as 2007, the legendary computer scientist Alan Kay called SimCity a “pernicious…black box,” full of assumptions and “somewhat arbitrary knowledge” that cannot be questioned or challenged [Kay 2007]. Kay’s and others’ critiques of SimCity focus on what Ian Bogost calls the “procedural rhetoric” of the game. By procedural rhetoric, Bogost simply means the implicit or explicit argument a computer model makes. Rather than using words like a book, or images like a film, a game “makes a claim about how something works by modeling its processes”  [Bogost 2009]. In the case of SimCity, I want to explore a particularly rich site of embedded procedural rhetoric — the procedural rhetoric of crime.

In fact, Kay illustrates his point about the black box nature of SimCity by describing how crime operates in the game. SimCity, Kay argues, “gets the players to discover that the way to counter rising crime is to put in more police stations” [Kay 2007]. Of all the possible options in the real world — increasing funding for education, reducing overcrowded housing, building mixed use developments, creating employment opportunities, and so on — it’s the presence of the police that lowers crime in SimCity. This is the argument that game makes, its procedural rhetoric. Naïve though it may be, the game has staked out a position on urban planning from which it cannot deviate. It doesn’t take long for players to figure out the position. Indeed, the original manual itself tells the player that “Police Departments lower the crime rate in the surrounding area. This in turn raises property values” [Bremer 1993, 5]. It’s one thing for the manual to propose a relationship between crime, property values, and law enforcement, but quite another for the player to see that relationship enacted within the simulation. Players have to get a feel for it on their own as they play the game. Recall Manovich’s comment about the hidden logic of a game. A player’s success in a simulation hinges upon discovering the algorithm underlying the game. But if the manual describes the model and players can discover it for themselves through gameplay, what’s the value of looking at the code of the game? What can the code reveal that playing the game cannot?

To answer this question we must examine the code itself. Because the code for Micropolis — SimCity’s open source twin — is freely available, this close reading of code is feasible in a way that a similar reading of a commercial game is not.[2]To wit, below are lines 413–424 of span.cpp, one of the many sub-programs called by the core Micropolis engine. It’s written in C++, a common middle-level programming language; Firefox is written in C++, for example, as well as Photoshop, and nearly every Microsoft product. By paying attention to variable names in span.cpp, even a non-programmer might be able to discern that this code scans the player’s city map and calculates a number of critical statistics: population density, the likelihood of fire, pollution, land value, and the function that drew Alan Kay’s attention to Micropolis, a neighborhood’s crime rate.

The manual tells us what this code does. But what does it mean? In the most general sense, these lines generate information for game engine about the game’s own state. The first several lines provide the scan mechanism, as the existing crime rate map of the player’s city (crimeRateMap.MAP_BLOCKSIZE) is methodically checked along the X and Y axes. This process alone highlights the quantitative over qualitative nature of computing. The map — and therefore, crime rate — can never be understood by the computer holistically, absorbed and interpreted all at once as a player might see it. Instead, it is checked granularly, numerically, point by point. The computer sees the city as a grid of discrete spaces, even though cities certainly aren’t experienced that way by their occupants. The scan mechanism raises a question that we may never have thought to ask before, namely, what is it like to be a city from a computer’s perspective?

The implications of understanding a cityscape as a dataset become clearer when other aspects of span.cpp are examined. In line 418, the crime rate variable Z starts off at a baseline of 128. This at first seems to be an arbitrary choice, but it is not random at all. The number 128 is (obviously) exactly half of 256, which is (less obviously) the highest 8-bit binary value (2^8) available on the original SimCity platform, the Commodore 64. Line 418 is a historical clue, providing a glimpse into the computers of the era. The heart of the Commodore 64 was its MOS Technologies processor, the 8-bit 6502 chip. The 6502 is now legendary for its role in home computing in the 1980s. Released in 1975, the 6502 or some tweaked version of it powered the Atari VCS, the Apple I and Apple II, the Nintendo Entertainment System (NES), and of course, the Commodore 64 [Bogost 2009, 12]. By developing SimCity as an 8-bit program tailored to the 6502 CPU (even though 16-bit computers and videogame consoles were beginning to arrive on the scene), Will Wright guaranteed that ports of the game would be compatible with the majority of home computers of the time. But why choose 128 as the baseline crime rate, rather than 0? From a baseline of 128 the crime rate can either go up or down; 128 allows the crime rate to fluctuate negatively or positively without having to deal with negative numbers. But the rate can only ever fluctuate within a predefined limit. Line 422 makes sure of this, using the clamp function of C++ to define the ultimate range of Z (from 0 to 250). In effect, SimCity specifies a maximum crime rate. Crime in SimCity is, like the discrete coordinates of the city, a rigidly defined quantity.

Immediately following the establishment of 128 as baseline in line 418, the land value variable (previously defined in line 415) is subtracted from Z, creating a direct causation between land value and the crime rate. This formula is complicated in the next line, as the population density is added to Z. Finally, with line 421, the number of police stations lowers Z. Track these additions and subtractions from Z, and it’s exactly as the manual explained: crime is a function of population density, land value, and police stations, and a strict function at that. But the code makes visible nuances that are absent from the manual’s pithy description of crime rates. For example, land that has no value — land that hasn’t been built upon or utilized in the player’s city — has no crime rate. This shows up in lines 433–434:

Because of this strict algorithm, there is no chance of a neighborhood existing outside of this model. The algorithm is totalizing and deterministic, absolutely so. A populous neighborhood with little police presence can never be crime-free. Crime is endemic, epidemic.

Land value is likewise reduced to set formula, seen in this equation in lines 264–271:

These lines stipulate that land value is a function of the property’s distance from the city center, the type of terrain, the nearby pollution, and the crime rate. Again, though, players will likely discover this algorithm for themselves, or else read about it in the manual, which spells out the formula, explicitly stating that “the land value of an area is based on terrain, accessibility, pollution, and distance to downtown”  [Bremer 1993].

Beyond highlighting how the computer reads the city as a set of data points, looking at code of Micropolis serves as exit point from the seemingly totalizing power of simulation, which is reinforced by both the manual and gameplay itself. Recall Sherry Turkle’s now classic work, Life on the Screen, about the relationship between identity formation and what we would now call social media. Turkle spends a great deal of time discussing what she calls the “seduction of the simulation” [Turkle 1995, 71]. Turkle has in mind exactly the kind of simulation whose code appears here, the Maxis games such as SimCity, SimLife, and SimAnt that were so popular 15 or so years ago as well as MUDs and MOOs, text-based precursors to virtual worlds like Second Life. Turkle suggests that faced with engaging, immersive simulations, players can respond in several ways. On the one hand, players can surrender themselves totally to the simulation, accepting whatever processes are modeled within. Turkle calls this “simulation resignation.” On the other hand, players can reject the world of the simulation entirely — what Turkle calls “simulation denial.” These are stark opposites, and our reaction to simulations obviously need not be entirely one or the other. Turkle proposes a third, ideal response: “understanding the assumptions that underlie simulation” and demanding “greater transparency” in simulations, whether they are popular videogames or real world planning simulations [Turkle 1995, 71].

Years after Life on the Screen, one would be hard-pressed to argue that simulations have become more transparent. If anything, they are more prevalent and yet more invisible, a situation Bogost diagnoses — riffing on Derrida — as simulation fever, a compulsion to render any and all real world processes as a simulation. Bogost explains that a simulation is “a representation of a source system via a less complex system that informs the user’s understanding of the source system in a subjective way” [Bogost 2006, 98]. Just as the most detailed map can never match the territory it represents, so too is the simulation bound to be irreconcilably impoverished compared to the system it simulates. Moreover, note Bogost’s use of the word “subjective,” which suggests a kind of crack in the exterior of the simulation. Awareness of the subjective nature of simulations can expose what Bogost calls the simulation gap, his own version of Turkle’s third response to simulations. With every simulation, Bogost argues, there is a “gap between the rule-based representation of a source system and a user’s subjectivity” [Bogost 2006, 107]. Exploring this gap is, for Bogost, the most productive way to overcome simulation fever. Bogost observes that simulations are “not exactly like textual or electronic archives” [Bogost 2006, 108], so the simulation gap must be understood by means different than those used to interpret literature or poetry. He imagines that “working through simulation fever means learning how to express what simulations choose to embed and to exclude” as well as learning how “to relate their rules to their subjective experiences and configurations” [Bogost 2006, 109]. But this is what a close reading of code reveals: simulations are indeed texts. The code itself expresses what “simulations choose to embed and to exclude.” The close reading of code by non-coders can act as a critical intervention into the simulation gap. Code exposes the guts of the simulation. Reading code exposes the gaps of the simulation. While the manual may explain processes and playing may set them in motion, neither provides the kind of traction gained by seeing the code. Reading the code turns the simulation into a textual object. And as a textual object, it can be taken apart, even tweaked and recompiled with our own algorithms.

When we crack open the code like this, we may well find surprises that playing the game or reading the manual will not tell us. Remember that though code does what it says, it also says things it does not do. Marino calls this characteristic of code its “extra-functional significance” — meaning-making that goes beyond the purely utilitarian commands in the code [Marino 2006]. Extra-functional significance means the code participates in a system of signs beyond those executable by the machine. This extra-functional significance may arise in the layout of the code, which forms meaningful patterns recognizable to the human eye but which are irrelevant to the program’s interpreter. Or perhaps in the developers’ choice of variable names, such as the “FeministWhore” variable that was discovered in a piece of code in the Steam version of the zombie survival horror game Dead Island [John 2011]. Or, quite likely, in the comments developers leave in code.

Returning to the example of SimCity and Micropolis, consider the code for disasters.cpp. Anyone with a passing familiarity with SimCity might be able to guess what disasters.cpp does. It’s the routine that determines which random disasters will strike a player’s city. The entire 408 line routine is worth looking at, but to illustrate the extra-functional significance of comments in code, examine the section that begins at line 109, where the probability of the different possible disasters is defined:

In the midst of rather generic biblical disasters (22% chance of fire in line 113 and 22% chance of flood in line 117), there is a startling excision of code, the trace of which is only visible in the programmer’s comments. These full-line comments in lines 119–123 can be identified by the double slashes that precede them:

These comments reveal that in the original SimCity there was a 1 out of 9 chance that an airplane would crash into the city. After 9/11 this disaster was removed from the code at the request of Electronic Arts.

Playing Micropolis, say, perhaps as one of the children in the OLPC program, this erasure would likely escape notice. It escapes notice because the machine doesn’t notice — the comment stands outside the algorithms of the game. It’s only visible when we read the code, a clear argument for treating code as a textual document rife with non-performative functions. We could raise any number of questions about this decision to elide 9/11 from Micropolis. There are questions, for example, about the way the code is commented. None of the other disasters have any kind of contextual, historically-rooted comment, the effect of which is that the other disasters are naturalized, even the human-made disasters like the Godzilla-like monster that terrorizes an over-polluted city in “case 8” (line 131). There are questions about the One Laptop Per Child program and the white-washing of American history for global audiences. There are questions about the relationship between simulation, disaster, and history that call to mind Don DeLillo’s White Noise, where one character tells another, “The more we rehearse disaster, the safer we’ll be from the real thing….There is no substitute for a planned simulation”  [DeLillo 1985, 196].

And finally, there are questions about corporate influence and censorship — was EA's request to remove the airplane crash really a request, or more of a condition? How does this relate to EA’s more recent decision in October of 2010 to remove the Taliban from the latest version of Medal of Honor? In this case, a controversy erupted when word leaked out that Medal of Honor players would be able to assume the role of the Taliban in the multiplayer game. After weeks of holding out, EA ended up changing all references to the Taliban to the generic and unimaginative “Opposing Force”  [Bogost 2010]. At least twice, then, EA — and by proxy, the videogame industry in general — has erased history, making it more palatable, or as a cynic might see it, more marketable.

While these social and historical questions are exactly the kind that critical code studies seeks to ask, it’s important to step back and consider the epistemological status of comments in code as well. Comments are ignored by the machine interpreter and readable by humans, but not exactly legible. They are visible only if one is able to view the source code. They are not intended for the end-user, but with the right tools, the end-user might find them. Comments in code thus exemplify McGann’s notion of the social private text — and although McGann is primarily discussing poetry, his definition of a text as a “laced network of linguistic and bibliographic codes” would certainly include computer code [McGann 1991, 13]. “Texts are produced and reproduced under specific social and institutional conditions,” McGann explains, “and hence that every text, including those that may appear to be purely private, is a social text”  [McGann 1991, 21]. Code is certainly produced in a specific social and institutional context, one might even say regime — for example, as a developer for Electronic Arts, coding eight hours a day, six days a week [Wark 2007, 44].

Code is a social text, even the comments that no one other than another developer is meant to see. Questions of voice (who speaks), address (to whom), and intention (and why) all arise, and because these questions have similarly occupied literary scholars, it’s tempting to transpose lessons from narratology onto the study of code and comments in code. Even early considerations by computer scientists of the role of comments in code acknowledged the centrality of these narratological questions. A 1976 study of the practice of commenting in code observes that comments require the programmer to approach the program from at least two simultaneous points of view — the coder and the documentor. This study divides comments into two categories of intention: “functional comments” that describe what a piece of code does and “operational comments” that explain how the code performs the function [Sachs 1976].

More recently Jeremy Douglass has convincingly characterized comments in code as a type of paratext, “continuous with and yet set apart from the source” code. Douglass likens code that is commented to a “parenthesis for a different reader”  [Douglass 2010] — a typographical metaphor that underscores the essential textuality of comments. Summarizing the way software developers have tended to think about comments in code, Douglass notes that comments serve as either documentation, specification, or metadata. These are all ways of Taylorizing the process of software engineering. Yet with Micropolis, it is clear that code comments can serve as either entry or exit points to the game, connecting it with social and historical contexts in a way that has nothing to do with software engineering.

It is tempting to think of code comments as a kind of textual marginalia — the notes, corrections, and even doodles that authors and readers add in the margins of texts. Patrick Murray-John, a software developer who also holds a doctorate in Anglo-Saxon literature, has suggested that comments in computer code might have imperfect analogs in the medieval division of marginalia into separate categories. As Murray-John notes, medieval scholars distinguished between lectio and enarratio [Murray-John 2011]. Lectio refers to aids for reading at the level of comprehension — notes and marks that help a reader make the text legible (originally for the purposes of reading aloud). Enarratio refers to marginalia that actually help readers interpret the text on a rhetorical and symbolic level — or, to extrapolate to the world of software engineering, on a procedural level. To lectio and enarratio we might also add, as Whitney Trettien suggests [Trettien 2011], emendatio, comments that correct or even offer improvements to the existing text (such as might be found in an open-source project, with one developer making suggestions on another developer’s code). These medieval categories of textual annotation do not map perfectly onto categories of comments in code, of course. More than a one-to-one correspondence, these categories can provide a starting point to begin to differentiate between kinds of comments in code. All comments in code are extra-functional, but not all comments in code are extra-functional in the same way. Categories such as lectio, enarratio, and emendatio can highlight the range of extra-functional significance found in code comments. This range is exemplified in the code of JFK: Reloaded, a game that perfectly embodies the contradictions between the playable algorithms of a game and the internal and usually invisible signifying structures of code.

Traffic’s 2004 JFK: Reloaded is premised upon a player’s ready resignation (to use Turkle’s terminology) to the simulated world, in this case Dallas, 1963. The game is rooted soundly in an identifiable — and for many of its outraged detractors — experienced event: the assassination of President Kennedy. The videogame is a first-person shooter in which that first-person happens to be Lee Harvey Oswald. The goal of JFK: Reloaded is to reenact the shooting at Dealey Plaza with as much fidelity as possible to the findings of the Warren Commission Report (i.e. Oswald acted alone, firing three bullets from a single rifle, from the sixth floor of the Texas School Book Depository).

Upon its release in 2004, Traffic labeled JFK: Reloaded a “docugame” and most critical readings of the game continue to see it as some form of interactive documentary. Tracy Fullerton places the game squarely within Michael Renov’s classic definition of documentary media, as the game “interrogates” the past [Fullerton 2008]. More recently, Bogost, Ferrari, and Schweizer suggest in Newsgames that JFK: Reloaded is a very specific kind of documentary. Bogost et al. describe three different “playable realities” that documentary videogames can simulate in the name of experiencing or understanding the past: a spatial reality, in which players explore the physical environment of a historical event (a recent example would be Osama Bin Laden’s Abbottabad compound, modeled in Counter Strike: Source); an operational reality, which recreates specific events, hewing to the historical record; and a procedural reality, which models “the behaviors underlying a situation, rather than merely telling stories of their effects”  [Bogost et al. 2010, 69].

According to this framework, JFK: Reloaded presents an operational reality. Players recreate in a structured, limited way (and guided by their own knowledge of the assassination) the essential operations of the assassination: waiting for the motorcade from a hidden perch, sighting the rifle onto Dealey Plaza, and firing into the presidential motorcade. However, as Bogost notes in Persuasive Games, a work that precedes Newsgames, there is more to JFK: Reloaded than the simple attempted recreation of a historical event. It is nearly impossible to “win” the game, by which I mean match the Warren Commission findings. This impossibility, Bogost suggests, contributes to the game’s procedural rhetoric, a kind of procedural reality layered upon (or beneath) the more explicit operational reality. As Bogost puts it, “the developer’s stated goal [of reaffirming the Warren Commission Report] was a ruse”  [Bogost 2007, 132–133]. And in fact, I would add, the game highlights its proclaimed goal’s exact opposite — the improbability of the Warren Commission’s findings.

Whether or not the procedural rhetoric of JFK: Reloaded supports or refutes the Warren Commission Report, it’s possible to find traces of another narrative by examining the code of the game. To be more precise, consider the comments that appear in one of the two WAD files that comprise JFK: Reloaded’s game assets. An acronym for Where’s All the Data?, a WAD file is a collection of individual sounds, sprites, level information, NPC (non-playable character) behavior, and other often customizable game data. Originally used in id Software’s Doom (1993), WADs or similar composite files are now commonplace in many PC games.

In the case of JFK: Reloaded, opening up the core000.wad in a text editor reveals mostly binary codes that look like junk (because they ought to be opened in a hexadecimal editor rather than a plain text editor). But beginning with line 224,070, there is a chunk of plain text code that resembles XML structured data, accompanied by full-line programmer comments.[3] For example, the following lines specify the actions that should occur when a generic character is fatally hit by Oswald’s rifle:

The code comments — the marginalia — in JFK: Reloaded’s WAD file at first blush resemble enarratio, not only helping readers to make sense of the individual lines of code that follow the comment, but also offering an interpretative gloss on the code. But quickly the comments move from enarratio into a perverse reworking of the fourth category of medieval annotation — judicium, or judgments upon the “aesthetic qualities or the moral and philosophical value of the text”  [Parkes 1999, 90]. For example, in the following snippet, Jackie Kennedy’s actions are defined:

The comment provides the context for these lines of code (enarratio) but the casual use of the overtly sexual phrase “money shot” is an implicit judgment (judicium) not on the code, but on the historical event itself. A phrase inexorably linked to pornography, “the money shot” comment is sudden, unsettling, and, like all comments in code, extra-functional. While it’s tempting to suggest that the comment sheds some light on the developers’ attitude toward the subject matter (what we’d call the author’s “tone” in literary studies), it is not necessary to do so. The comment is structurally unnecessary, but that doesn’t mean it doesn’t mean. Its rhetorical excess spills over, making this supposedly private text palpably social. A money shot commonly refers to the climactic scene of male ejaculation in a pornographic film, so named by the pornography industry because it’s typically the most expensive scene to shoot. It is also, as Linda Williams argues, the “most representative instance of phallic power and pleasure” in a hard-core film [Williams 1999, 95]. Williams positions the money shot as a dense collision point between commodity fetishism, visual desire, and anxiety over women’s “invisible and unquantifiable pleasure”  [Williams 1999, 113]. In more ways than one, the money shot is “a substitute for what cannot be seen”  [Williams 1999, 95].

The money shot comment in JFK: Reloaded reenacts this substitution and reverses it. Consider the comment closely: “Jackie cradling JFK before the money shot.” While Kennedy is nominally the target in JFK: Reloaded, describing the fatal gunshot as a money shot substitutes Jackie as the intended target. In heteronormative pornography, it is the man who delivers the money shot and a woman who receives it. Jackie thus becomes an unwilling participant in a death scene that is pornographic in nature, while the player is given license to fulfill the role of the male performer in a pornographic film. In other words, imagining Oswald’s bull’s-eye as a money shot makes it okay to try to hit Jackie. Jackie Kennedy is not collateral damage but in fact was the target all along. Furthermore, like a money shot in a hard-core film, the event is commodified and repeatable. Yet the programmer’s comment also reverses the usual dynamic of a money shot, which makes visible (ejaculation) what would otherwise be hidden in intercourse. In the case of JFK: Reloaded, though, it is the money shot comment itself that is meant to be hidden, off limits to the player. But it’s still there. It means something. It cannot not mean something.

A textual imagination must reckon with the comment. Once it is known, it cannot be unknown. To ignore the comment means overlooking the kind of evidence that historians and textual scholars have long used to create a more complex understanding of our cultural heritage. At the very least — the very, very least — the strictly objective perspective that we falsely associate with documentary media dissolves here. The misogynistic tone of the comments becomes even more troubling in the following snippet of code, which defines Nellie Connally’s actions when her husband, Texas Governor John Connally, is shot:

In three lines of code commentary, the developers at Traffic absolutely undermine the entire stated pedagogical project of their docu-game. Their outwardly respectful “interactive reconstruction of John F. Kennedy’s assassination” is undone by inaccuracies (the suggestion that Connally “croaks”) and misspellings (Nelly for Nellie, “desparate”) but even more so by the explicitly pornographic and misogynistic reframing of this traumatic event. This comment marks the second time a grieving woman protecting her injured husband is portrayed in JFK: Reloaded as transgressively sexual in a moment of pain and suffering. While the <concerned> variable initiates an in-game routine appropriate for the situation, the hidden code retells the story almost as a snuff film. The governor’s critical wound is met with arousal, and Nellie’s desperation is sexual, not emotional. Simulating the direst of situations — a national tragedy but also a personal one — this first-person shooter collapses sex onto violence. They are indistinguishable from each other, but only in the comments.

Given the rhetorical excess of these comments, it’s worth thinking about them as more than paratext. I want to suggest the idea of paracode. In textual studies, of course, para-, as in paratext, is what Genette calls the “threshold” of the text, the “zone between text and off-text”  [Genette 1997]. Paratext includes all the textual apparatus at the edge of a book — indices, acknowledgments, and so on. Paracode likewise includes the apparatus at the edge of code, the comments chief among them. But there’s another meaning of “para” I want to evoke. It comes from the idea of paracinema, introduced by the film theorist Jeffrey Sconce. Paracinema is a kind of “reading protocol” that valorizes what most audiences would otherwise consider to be cinematic trash [Sconce 1995]. The paracinematic aesthetic redeems films that are so bad that they actually become worth watching. Following Sconce’s work, the videogame theorist Jesper Juul has wondered if there can be such a thing as paragames — illogical, improbable, and unreasonably bad games. Such games, Juul suggests, might teach us about our tastes and playing habits, and what the limits of those tastes are [Juul 2009]. Along the same lines, paracode is code so excessive or remarkable that it becomes productive to fully engage with it. The example of the missing airline disaster in Micropolis is a noteworthy example. The algorithm for the disaster is there, present in the code, but commented out, in a kind of Derridean erasure. The paracode leaks out from the code, and it is up to cultural critics to make sense of it.

The paracode of JFK: Reloaded is even more startling. In addition to undermining Traffic’s official rationale for the game, the paracode complicates the arguments of the critics who defended the game. Access to the code allows us to write a revisionist history of JFK: Reloaded. Some might argue that the marginalia of the game, which was never intended to be available to the player, should not guide our interpretation of the game. But this is precisely why code must become a site of engagement for humanists. Recall McPherson’s argument that not only is code a hidden marker of social relations, code hides the means by which itself operates. As I have demonstrated here, approaching code on a textual level as opposed to a procedural level exposes some of these transparent dynamics. In the final analysis, my exploration of this particular pair of games — Micropolis and JFK: Reloaded — is secondary to the broader questions of critical code studies. What does an attentiveness to code, or even comments in code, mean for literary scholars and cultural historians who study digital artifacts? Code is too important to be left to coders, and it will increasingly be necessary for humanists to develop some degree of what Michael Mateas has called “procedural literacy.” An accomplished new media designer himself, Mateas describes procedural literacy as “the ability to read and write processes, to engage procedural representation and aesthetics, to understand the interplay between the culturally-embedded practices of human meaning-making and technically-mediated processes”  [Mateas 2008, 1]. Like any reading literacy, procedural literacy has different thresholds, each requiring greater proficiency. I have argued elsewhere for the notion of computational competency over literacy [Sample 2012], but the point remains: even the most modest efforts to “engage procedural representation” can yield rewarding results. In the examples of Micropolis and JFK: Reloaded we encounter programmer comments that in no way help us to understand what Bogost would call the procedural rhetoric of the games. Yet, they do help us to develop an understanding of the games as cultural objects and of coding itself as a cultural practice. Especially in the case of JFK: Reloaded, the comments are an expression of the male-dominated, conquest-driven milieu of contemporary gaming and coding. At the very least, they show that the “inside” of software does not always match the “outside.” And ultimately, a thorough engagement with the textual condition of software reveals that procedural literacy must not be strictly limited to reading or writing code, but must also extend outward to language and cultural practices.