Carts Tapes Discs Drives
This paper was originally presented at the Society for Textual Scholarship Conference, Penn State, PA, March 18, 2011.
Today I want to speak about videogames as objects of textual scholarship, granting them the same keen eyes, ears, and hands that we are accustomed to giving books and manuscripts. Pac-Man is a particularly interesting specimen, familiar enough to most people to yield surprising insights when we begin to unbind its leaves.
Pac-Man was ubiquitous in the arcade heyday of the 1980s and persists, even now, in hundreds of revisions and re-releases. The game was born in Japan, designed by a young employee of Namco named Toru Iwatani. He, along with a nine-man team, developed the game over the course of a year, between April 1979 and May 1980. Iwatani thought arcades were dominated by violent war- and science-fiction-themed shooting games and sought to create an experience more appealing to non-gamers, especially women. In my favorite quote from a recent interview, he says,
When you think about things women like, you think about fashion, or fortune-telling, or food or dating boyfriends. So I decided to theme the game around “eating” — after eating dinner, women like to have dessert.
Thus Pac-Man came to be, resembling both a slice-less pizza pie and a modified version of the Japanese character for ‘mouth.’ Perhaps in spite of himself, Iwatani was right: the game was popular with women, the Japanese, and especially Americans. Pac-Man sold over 350,000 units, making it the best-selling videogame of its time. Pac-Man the character reached iconic status, tied to countless merchandising deals, a Saturday morning cartoon, and even a hit novelty single.
One could make a strong argument that the definitive Pac-Man was created in 1980. It looks like the screen you see here: a muted blue maze on a black void, filled with edible dots, four of which are larger than the others; Pac-Man, in brilliant yellow, faces one of four cardinal directions; the ghosts, equally colorful, with expressive eyes, wait to give chase once they emerge from their central ‘house.’
This visual reference is important, even iconic, but it is also a single facet of a complex object we call Pac-Man.
Let’s take one step away from the screen. Consider the arcade cabinet, an impressive wooden frame meant to house the bulk of the CRT display, its glass cover, the game’s internal circuit board, power supply, wiring, and (most importantly) the coin collector. The frame’s structure and external design speak to its social and economic contexts—the vibrant outer label functions as a marketing device, while the cabinet’s vertical orientation compels you to stand while playing. The ‘cocktail’ version of the arcade cabinet is horizontal—you are seated, looking down at the display, and the game is meant to be shared by two players simultaneously, as the screen flips orientation between turns. This configuration also re-orients the social context–the cocktail Pac-Man was more likely to reside in bars or restaurants, where customers would come in groups and the flat surface of the game could double as a tabletop.
Already, at the level of physical structure, we see a differentiation in objects that has nothing to do with graphics on-screen. Historically, videogames have gotten the short shrift in this regard. They are treated as if the screen is the only, or at least the most important, part of the object worth studying. But the screen is only one part of a wider story, a story that includes the underlying hardware, the source code, the game’s packaging, distribution system, economic contexts, social relationships, user interface, and more. This common oversight is reflected in the poor state of videogame bibliography. Just ten years ago, games were regularly absent from citation lists. Even in The Video Game Theory Reader, an early entry in the videogame studies field, games had in-line citations such as ‘Pac-Man (1980),’ but were otherwise segregated from text sources. The situation has improved in recent years, but the best case scenario is something like: Namco. Pac-Man. Arcade. 1980. Here we have the publisher, title, platform, and year of release.
This example comes from Racing the Beam, a 2009 book by Nick Montfort and Ian Bogost that inaugurated the ‘Platform Studies’ series from MIT. As the series title implies, the authors are concerned with platforms, the ‘basic hardware and software systems upon which programming takes place, the ones that are the foundation for computational expression.’ Their specific focus is the Atari VCS, a weirdly constrained piece of hardware that was the basis for many unique creations and peculiar ports of popular arcade titles. For those of you unfamiliar with the term, a port is a word that describes both the process of transferring code from one platform to another, and the end result of that process. In the case of Pac-Man, there was a rush to carry over its arcade success to as many platforms (and thus consumers) as possible. Porting Pac-Man meant translating its distinctive graphics and gameplay to whatever hardware would support it (and, as we’ll see, even those that could not).
Pac-Man, like most arcade games, ran on dedicated hardware, meaning the circuits, joystick, buttons, cabinet, and so on, were configured specifically for its gameplay style, graphical and audio needs, and the economic constraints of the manufacturer. This is much different than today’s videogame hardware landscape, which is dominated by home or portable consoles like the Xbox 360 or the Nintendo DS. Developers now cater their code to those platforms, rather than building custom boards for each game they produce. That’s not to say that arcade boards were individually designed from scratch–instead, game publishers typically custom-fit mass-produced processors for their particular technological needs. Pac-Man ran on a modified Zilog Z80 CPU, which alongside the MOS Technology 6502, dominated the 8-bit microprocessor market. In addition to serving as Pac-Man’s core CPU, the Z80 appeared in Galaga, Dig-Dug, the original GameBoy, Sega Master System, ColecoVision, the Roland Jupiter 8 synthesizer, the Sequential Circuits DrumTraks drum machine, wireless sprinkler controls, Russian land line caller ID systems, breathalyzers, Seagate hard drives, and many other consumer devices.
Without sinking too deep into technical jargon, I want to highlight a few key specifications of the arcade hardware, especially in relation to subsequent ports. The display supported a resolution of 224 x 228 pixels. These pixels were grouped in 8×8 pixel blocks, arranged in a 28×36 matrix. Note how the screen is taller than it is wide. This vertical configuration was a challenge to reproduce on contemporary home consoles and even on today’s computer screens, where horizontal aspect ratios are the rule. The board also had just 2K of RAM, half dedicated to video information and half dedicated to color information. As Montfort and Bogost note in their chapter on Pac-Man, 1K of video RAM was not enough to populate the entire 28×36 playfield, so the video RAM stored references, rather than actual graphical data. In other words, video RAM pointed to a separate ROM location for both the 8×8 bitmap ‘tile’ displayed at any given coordinate and the colors used to fill that tile. This economical use of on-board memory allowed the re-use of a small amount of tiles to draw the entire maze. You’ll notice identical 8×8 sections repeated in various structures, like the bottom border wall. Twenty-six discrete screen locations are drawn with reference to only a single graphical element and its corresponding color. This is equally handy when tiles need updates on-the-fly. When Pac-Man eats a pellet, for instance, the reference at that given tile can swap from ‘pellet’ to ‘empty.’
In addition to its ‘character’ definitions, which comprise the game board, Pac-Man also support eight independent 16×16 sprites that may be moved around the screen without affecting the underlying graphics. Pac-Man and the ghosts are all sprites, who may each have their own shape, X/Y screen coordinates, and up to four colors. In addition, each sprite can be flipped horizontally, vertically, or both, allowing Pac-Man to change orientations without hogging additional memory.
Keep in mind that this hardware configuration is suited specifically to Pac-Man’s gameplay needs. The symmetrical configuration of the in-game architecture is an artifact of the video RAM constraints. The flat two-dimensional maze is drawn with a handful of repeated sub-sections. Using video RAM as references rather than discrete graphics locations allows the game logic to keep track of whether dots are eaten or not with low computational overhead. The sprite limitations also create an upper threshold for how many actors may appear on the screen at any given time. The color limitations likewise account for the vivid, iconic representations of Pac-Man and his antagonists. Yellow, red, pink, blue, and orange are stark against the muted game space. Each of these concessions, in turn, allows for more computation to be devoted to one of Pac-Man’s crucial characteristics: the unique gameplay behavior.
Videogames are driven by code. Code is a structured set of descriptions and instructions, or algorithms, a kind of computational recipe that governs how any given object in a game will interact with other objects, itself, or the space it resides in. When programmed well, algorithms give rise to the semi-mystical interaction between player and machine that piques our curiosity, drives our desire of mastery, or even or sense of exploration. In mainstream videogame criticism, this fusion of algorithm and interaction is often called a game’s mechanics. It’s a vague description of both an innate and practiced gestalt of how a game works, from the ‘feel’ of the controls to the types of in-game interactions that are valid or invalid. Videogame mechanics are like sound design in film–they come to the forefront when they are poorly implemented. Mechanics are ‘broken’ when a player feels like she doesn’t have direct control over her on-screen avatar, or the game is excessively difficult, or the game’s underlying rule system is opaque or inconsistent.
A key part of Pac-Man’s object-hood is the logic that drives the ghosts’ behavior, Pac-Man’s movement, and the interaction between those elements. In the 1980s, Pac-Man’s algorithmic behavior appeared either random or diabolically unfair. As gamers began to exhaustively play and master the game, it became clear that Pac-Man could be gamed–a host of patterns, much like opening strategies in chess, began to develop and disseminate, allowing players to memorize paths of ghost avoidance. Scores began to skyrocket. Books were published revealing techniques like the ‘Cherry Pattern,’ the ‘Mid-Fruit Pattern,’ and the ‘Ninth-Key Pattern.’ Still, without today’s access to the actual hardware and code, these were more brute-force hacks than algorithmic understanding. Millions of player-hours yielded useful techniques, but not computational mastery.
Today, thanks to online resources like Jamey Pittman’s comprehensive ‘Pac-Man Dossier,’ we can take a look at the logic that players intuited through countless hours of play. Again, without getting into too much technical detail, we can describe Pac-Man’s basic mechanics as follows: Pac-Man attempts to clear the screen of dots. Ghosts are released at timed intervals and give chase in order to obstruct this goal. Pac-Man may reverse the hunter/hunted relationship by eating one of four special energizer pellets, which allow him to eat the ghosts and send them back to their central container. The ghosts exhibit one of three mutually-exclusive behaviors: chase, scatter, and frightened. The first two occur in waves. Ghosts will chase Pac-Man for a specified amount of time, then cease their pursuit and head toward their designated home corners for a brief respite. The cycle is repeated unless Pac-Man eats an energizer, which ‘frightens’ the ghosts and forces them to momentarily scatter.
The key point here, as Pittman describes, is that, ‘Every ghost has a distinct method for calculating its target tile in chase mode, resulting in their unique personalities.’ Blinky, the red ghost, is the most aggressive, as he uses Pac-Man’s current tile position as his target. Pinky, in contrast, does not pursue Pac-Man directly, but selects an offset target four tiles away from Pac-Man in the direction Pac-Man is currently moving. The blue ghost Inky uses both Pac-Man’s current tile/direction vector and Blinky’s tile position. Finally, the orange ghost Clyde bases his movement on his current proximity from Pac-Man. If he is within eight tiles, he retreats to his scatter target in the lower left corner. At a distance greater than eight tiles, he pursues Pac-Man directly. This simple, dynamic system creates a complex and engaging set of behaviors that manifests more as anthropomorphic behavior than cold computer logic. And I think the emergent quality of this simple system is part of Pac-Man’s long-term appeal.
These algorithmic mechanisms are arguably just as essential to the porting process as the ghost graphics and the opening theme song. But code never makes a 1:1 transition between different microprocessors. Pac-Man’s code, in Z80 assembly language, must be rewritten to conform to the syntax of 6502 assembly, Javascript, or C. And further, more stringent transformations are necessary even within subsets of a single parent microprocessor. Both the Atari VCS and the Nintendo NES, for example, share a common lineage in the 6502, but their hardware constraints are drastically different.
Racing the Beam has an excellent account of the challenges faced porting arcade Pac-Man to the VCS, which had one-third the CPU speed, one quarter the available ROM space, one-sixteenth of the RAM, and no video memory. This means the background playing field had to be drawn scan line by scan line, rather than referenced in a tile format. Limited space for sprite graphics meant Pac-Man could only look left and right. The ghosts lost their tell-tale colors and personalities, but gained an eye-fatiguing flicker. Add to these technical challenges the fact that programmer Tod Frye had just six weeks to program the game. As you might notice from the screenshot, the resulting port, though Pac-Man in name, is far different in appearance.
The Nintendo port, in contrast, is a fairly faithful rendition of the arcade original. The NES’s adapted 6502 was still quite different than the arcade board, but it did share a tile-based graphics system, a multi-voiced sound chip, and enough sprites to populate all the players on the field. The main platform concessions are more subtle. The NES’s available color palette is different than the arcade’s, so the vibrant ghosts appear muted and difficult to distinguish. Pac-Man’s shifted hue makes him more cheddar wheel than cheese pizza. The basic maze configuration and ghost behaviors are intact, but the horizontal orientation of home televisions versus the vertical orientation of the arcade screen means that game statistics are swapped from their header/footer pair to a single sidebar.
Perhaps more interesting from a textual scholar’s perspective is the tiny yellow graphics fragment you can see in the upper left hand corner of the screen. This bit of errata is unique to the NES platform, a result of a common programming error where unused sprites were supposed to be set at X/Y position 0,0, but actually fell just outside the television’s overscan.
Even more notable is a code difference that few players ever see. In the arcade Pac-Man, there is an infamous killscreen, videogame parlance for an unbeatable, game-ending level, usually due to a logic error in the game’s code. In Pac-Man, the level counter is stored in a single byte of memory, so it’s upper limit is 255. When the player reaches the 256th stage, an overflow error corrupts the fruit-drawing routine and renders the entire right half of the screen as graphical garbage. This bug set a hard upper limit to Pac-Man’s high score and passed into mythical status among high-level players. However, in subsequent ports, there is typically no kill screen; players may reach the 256th stage and beyond.
A quick tour of Pac-Man ports across the decades shows the range of inconsistencies that manifest when platforms change, both visually and materially. Even within platforms, we have interesting variations, like the alternate box art documenting the legal confrontation between Tengen and Nintendo over the former’s unlicensed Pac-Man port. And lest we think that we’ve zeroed in on the essence of Pac-Man by isolating its algorithmic behaviors, always keep in mind that popularity breeds imitation, and the characteristic chase and evade style of gameplay quickly surfaced in a number of so-called ‘Pac-Man clones.’
The point in all of this is that Pac-Man is not just an abstract array of pixels shaped like a voracious pizza, hunted by ghosts. When we say Pac-Man, we mean one thing, but we designate myriad unique objects. They’re familiar, but certainly not identical.
A videogame is not just a visual artifact—it is a 4-way joystick, a body of code inscribed on a microchip, an algorithmic system, a discrete array of resistors and capacitors, an upright painted cabinet designed to collect quarters, a phosphorescent cathode-ray monitor, and a game-ending glitch.