7

Inventing Graphical Logics

The word “video” appears in “video games” for a reason. Even though text-only games have a fond place in my heart, and certainly sound-only games exist, there is no denying the central place of video screens. It is on video screens, and using other elements of television technology, that video games came to prominence in our culture. The public space of the arcade and the private space of the television-connected home console were where a new generation of games reached a broad audience—and where designers did the most work to bring new experiences to that audience.

David Sudnow’s Pilgrim in the Microworld1 is an early book about getting deeply connected to game screens. It describes Sudnow—an academic phenomenologist and passionate jazz pianist—bringing his skills of keen observation, critical thinking, and dedicated practice to the world created by the video screen, its computationally driven objects, physical game controls, and his own actions. As Sudnow discusses, that world is not inside the screen. Rather, as he learned to play, and as each person learns, “we traverse the wired gap with motions that make us nonetheless feel in a balanced extending touch with things.”2

What happens when we traverse that gap? Sudnow describes the virtual paddle controlled by Breakout players (figure 7.1) as like a part of a player’s body, akin to a knuckle or the fully physical extension of a baseball bat:

When you’ve got the paddle properly in hand it’s a different kind of thing, not really a thing at all, but an extension of your fingers. You bring the so-called second section of the paddle beneath the ball in the same way you can move the back of your hand toward a cup in front of you so the knuckle of your index finger touches it. You don’t have to look at that knuckle. . . . When a paddle or a bat is incorporated by the body, becoming a continuation of ourselves into and through which we realize an aim in a certain direction, such implements lose all existence as things in the world with the sorts of dimensions you measure on rulers. They become incorporated within a system of bodily spaces that can never be spoken of in the objective terms with which we speak of objects outside ourselves.3

Figure 7.1

In Breakout, the player controls a paddle moving across the bottom of the screen, bouncing a ball against a wall at the top of the screen. Each bounce removes a brick from the wall. Each color-coded layer of the wall, when reached, makes the ball bounce faster than the layer before. Eventually, successful play requires that paddle positioning be done by reflex, operating the controller and the spatial model through the “system of bodily spaces” Sudnow describes, rather than through conscious planning. (Image of Breakout taken by the author during play on the Stella emulator, version 5.0.2.) (Atari, Breakout, 1978.)

What Sudnow is describing is the experience of having deeply learned the playable model of space in a game. Once it is learned, we cease to think about it, instead thinking of the actions we wish to take within it.4 When it is learned, much of our ability to play within it is transferred from that game to similar games, just as most of our ability to drive transfers from car to car.

Once we can play within a game’s model, that becomes the foundation of further experiences. Most books about game design focus on introducing challenges and goals to push players past what they can easily do within models. Later chapters of this book will instead discuss what additional meanings have been, and can be, layered atop the experience of virtual space.

But this chapter will look beneath the surface. It will examine the operational logics that form the foundation for the playable models of space we see in most games.5 It will look back at how these logics were introduced into video games. In the process, it will tell a story that is familiar to many with an interest in the history of video games. Yet by telling the story differently, through the lens of logics and models, I believe we can shed additional light on four topics.

First, this chapter will trace the development of continuous, two-dimensional spatial models in video games—not to engage in a fetishization of “firsts” but for what their development can expose about the importance of aspects of these games that have commonly received less attention. The tracing reveals the importance of gravity, an aspect of these models that is little discussed. Second, through this process, this chapter emphasizes something too often forgotten: the work of game design innovation is not the exclusive province of sketchbooks and software but also of wiring diagrams and electric relays, and the latter’s affordances and limitations have shaped our history. In particular, I recount two attempts to develop video game designs for wide audience–oriented hardware (comparatively inexpensive television technology), versions of which designs had previously existed in research labs (where they could employ computers far more expensive than could be deployed to wide audiences). This will not only provide another chance to discuss inventive approaches to logics—covered earlier in chapter 5—it will particularly be an opportunity to look at the importance of implementation to invention. Third, this chapter will call into question one of the most famous “just so” stories6 of video games: that of Computer Space7 flopping due to its complication, whereas Pong8 succeeded due to its simplicity.9 Finally, this chapter will offer a specific example of what is required to construct a playable model, discussing the combat models that so often accompany real-time continuous spatial models.

Continuous Spaces and Graphical Logics

Of course, games of the sort Sudnow describes are not the only ones that are played in a virtual space. The very earliest video games, decades before arcades and home consoles—such as Christopher Strachey’s 1951 M. U. C. Draughts10—presented spaces of some sort. But like the tabletop game Strachey emulated (known in the United States as Checkers), the spaces in these games were discrete. They were divided up into non-overlapping spaces, and each game action involved moving a piece from one discrete space to another, with no in-between position available or meaningful.

The works that introduced games as a cultural force, instead, had models of space that felt continuous. The first hit video game in the computing subculture—Spacewar11—created the experience of smoothly flying a ship through space.12 The first game well-known by broader culture—Pong—allowed players to smoothly move paddles to intercept a ball that, itself, moved smoothly through the space.

For this feeling of continuity to exist not only requires that there be many potential positions in the virtual space (so many that moving between them creates a feeling of continuousness) but also that time is ongoing.13 Games like Strachey’s, on the other hand, also operate in terms of discrete time—one player moves, then the other moves. And this sort of spatial model, with discrete space and time, is not only common in video games that emulate board and card games. It is also commonly seen in genres such as strategy games, simulation games, and puzzle games.

For us to understand the core mechanics of games—the key actions that players take—we have to understand the logics and models that are their foundation. For example, “jumping” is a core mechanic in many games. But the possibilities for player action and game response make jumping fundamentally different in a game like Strachey’s (with a discrete spatial model, built using appropriate versions of logics) and a game like David Crane’s Pitfall!14 (with a continuous spatial model and different versions of logics).15 Though Crane’s game came three decades after Strachey’s, the importance of this difference made it possible for Pitfall to become a highly influential early entry in the platformer genre.

Which brings us to the title of this chapter. There are three key graphical logics: collision detection, movement physics, and navigation (the last being another name for control logics, when used in spatial models). Each of these could be implemented in many ways, including as part of discrete spatial models. But I (and others) use the phrase “graphical logics” to refer to these logics when they form the foundation of continuous spatial models, presented visually. This is now usually done with the tools of computer graphics—such models are, in a sense, “computer graphics made playable” (though, as this chapter will describe, they have not always been implemented this way).

These logics are key to many of the experiences that have defined video games as we know them. In particular, they undergird the continuous, two-dimensional spatial models upon which video games grew into an important cultural and economic force, as with coin-op games of the 1970s such as Pong. Expanding the uses of such models, as described in chapters 8 and 9, has been central to the work of those pushing the meanings of games in new directions. And, of course, these models have an essential role in conventional games today, as seen in mobile phone titles such as Angry Birds,16 which have made video game play ubiquitous.

Collision, Movement, and Physics: Tennis for Two

The history of computing is a funny thing. Innovative hardware and software are made up of reusable parts, or made for machines with other uses, and then may be disassembled or overwritten without leaving a trace. What history we know of video games, like other areas of computing, is the result of the happenstance of preservation as much as deliberate archiving and investigation.

Raiford Guins is probably the person who has spent the most time investigating the history of the game now commonly called Tennis for Two.17 As Guins discusses in his 2014 book Game After,18 it’s not even clear how the game got that name—which seems to have appeared about four decades after the last time anyone played the original. Luckily, the game was also investigated in the 1980s, as part of a long series of video game lawsuits initiated by Magnavox, which itself created greater interest, leading to the preservation of documents and conducting of interviews that have helped us understand some of its history. As Guins reports,19 these documents include diagrams of the original plans for the circuits, as well as notes indicating that the plans were revised in practice, but do not include any documentation of the revisions. So the original game cannot be entirely recovered. Still, we know things about it, both from documents of the time and from attempts to re-create it since.

Tennis for Two was certainly not the first video game. I currently believe that honor belongs to Strachey’s M. U. C. Draughts (which I have given that name because I believe its lack of a name is part of why it has not been credited more widely).20 But I also believe that Tennis for Two holds a very important place in the history of video games: it is the first video game with a continuous model of space, and it introduced versions of the key operational logics of collision detection and movement physics that are appropriate for building such models.

Tennis for Two was created by William Higinbotham, Robert V. Dvorak, and David Potter as a demonstration for the 1958 visitors’ day at Brookhaven National Laboratory (BNL).21 It presented a simplified side view of a tennis court on an oscilloscope screen, with a visible ball, net, and groundline but invisible racquets. Two players used simple controllers, each with two inputs: a button for determining when to hit the ball and a dial for determining the angle. In footage from the documentary When Games Went Click22—taken of a re-creation led by Peter Takacs, Gene Von Achen, Paul O’Connor, and Scott Coburn23—when the ball hit the net or ground it would bounce back (figures 7.2 and 7.3).

This bouncing is particularly important, because it is here that we see the collision-detection logic at work. All the elements of a logic (as discussed in chapter 1) are in place. The game state is presented on the oscilloscope, showing the ball colliding and responding to that collision. The display is controlled by analog computation, carrying out the abstract process—“when the boundaries of two virtual objects intersect, declare the intersection”—enabling the response.24 The gameplay experience is of being able to drive the game’s collision detection over and over, learning how it operates in the spatial model of Tennis for Two. Taken together, these clearly fulfill the communicative role, “Virtual objects can touch, and these touches can have consequences.”

Figure 7.2

Scott Coburn, Peter Takacs, and Gene Von Achen who, together with Paul O’Connor, reconstructed the retrospectively named Tennis for Two for its fiftieth anniversary in 2008. As Diane Greenberg reports, “Using Higinbotham’s original plans, Takacs and his colleagues rebuilt the game with vintage parts, including mechanical relays and germanium transistors that first became commercially available in the 1950s. The original 1950s model analog computer that was made from vacuum tube circuits had to be simulated using modern integrated circuit chips.” (Image courtesy of Brookhaven National Laboratory.) (Greenberg, Diane. “Celebrating Tennis for Two with a Video Game Extravaganza.” The Bulletin, Brookhaven National Laboratory, October 31, 2008. https://www.bnl.gov/bnlweb/pubaf/bulletin/2008/bb103108.pdf.)

Figure 7.3

In a re-creation of Tennis for Two, the ball, net, and ground are visible, but the racquets are not. Re-created for the New York Historical Society Museum’s exhibition, “Silicon City” (2014–2015). Re-creation consisted of a simulation of an oscilloscope displaying an emulation (by Ben Johnson and Peter Takacs), reconstructed controllers (by Adelle Lin), and exhibition design that “enlarges” the original oscilloscope (by Jeanne Angel, working with the show’s exhibition and graphic designers, John Esposito and Kira Hwang), with consultation from Raiford Guins. (Image courtesy of Raiford Guins; Raiford Guins, “Tennis for Two at the NY Historical Society Museum,” Raiford Guins (blog), November 19, 2015. https://raifordguins.com/2015/11/19/tennis-for-two-at-the-ny-historical-society-musuem/.)

Interestingly, as Nathan Altice pointed out to me in conversation,25 it is less clear that collision detection supports the key mechanic (or gameplay “verb”) that it will in future Pong-like games. This mechanic is returning the ball when it is served or returned by the other player. Because the paddles are invisible, it is hard to argue that collisions with them are communicated, so the logic is unfulfilled. It is this that most strongly gives the sense that Tennis for Two is not yet a mature version of a Pong-like game.26

The other logic introduced by the game (in a version appropriate for playable models of continuous space) is movement physics. This logic communicates that virtual objects move according to physical laws, sometimes in ways beyond the direct control of players. The abstract process evaluates the rules that apply in order to determine future positions of virtual objects. Of course, in the case of Tennis for Two, these rules were not written down mathematically or as software, but rather assembled in physical components. For those interested in understanding the logics of video games deeply, looking at early games is helpful, in part, because it broadens our thinking about how logics can be implemented. Electric relays can be where an innovative game designer does her work, not just lines of code.

One interesting thing about Tennis for Two is that it doesn’t have objects that players can move around the visual space. Rather, every movement shows players an example of what happens when the ball moves with particular force at a particular angle. The game state presentation is always showing how the forces of physics are shaping the arcs, bounces, and remaining momentum of the ball. And this is key to the player learning the spatial model and developing the ability to effectively use the game’s two key mechanics: serving the ball and returning the ball.27

Tennis for Two also illustrates another important idea about operational logics: they can be implemented in different ways, which shapes the resulting gameplay experience and playable model. For example, the movement physics logic in Tennis for Two is implemented in a way that includes gravity and wind resistance, which are often absent from later games (like Pong). The implementation of these forces threads through all aspects of the logic. For example, in Tennis for Two (and many other games) the implementation of gravity adds an abstract process: all unfixed elements not attached to a fixed element, or not on the “opposite” side of a fixed element, have attraction toward a point or region of the space, of which there may be more than one.28 The communicative role is that one or more elements (the bottom of the screen in Tennis for Two, the central star in Spacewar) is a source of gravity. This issue will become key in our discussions of Spacewar, Computer Space, and Pong.

Tennis for Two’s innovation was not in using analog computation to present images on the screen, or even in using collision detection and physics. As BNL’s account tells us, “The computer’s instruction book described how to generate various curves on the cathode-ray tube of an oscilloscope, using resistors, capacitors, and relays. Among the examples given in the book were the trajectories of a bullet, missile, and bouncing ball, all of which were subject to gravity and wind resistance.”29 But using these elements to construct video games’ first playable model of continuous space and designing the first example of a Pong-like game (which would go on to great commercial success) were certainly very significant innovations.

Higinbotham and his collaborators also employed an inventive approach to implementation—particularly, implementation of the visual display. Versions of this approach would later become very important to game developers in other resource-constrained contexts, such as the Atari VCS (as described by Nick Montfort and Ian Bogost in Racing the Beam30). This approach is using a single visual output to draw multiple objects on screen, by changing its position quickly. BNL employee Peter Takacs, who led the re-creation of Tennis for Two, describes this: “Higinbotham used the transistors to build a fast-switching circuit that would take the three outputs from the computer and display them alternately on the oscilloscope screen at a ‘blazing’ fast speed of 36 Hertz. At that display rate, the eye sees the ball, the net, and the court as one image, rather than as three separate images.”31

Tennis for Two’s gameplay was novel and compelling enough that visitors lined up to experience it. However, it seems unlikely that serious thought was given to opening up the experience to a wider group. The game was composed of a large, heavy amount of hardware, driven by an analog computer. This was before the spread of digital computation made such experiences much easier to distribute—because they could travel as software for machines already configured with display screens, rather than as schematics for assembling and configuring an analog computer and additional hardware. That moment of software distribution for a landmark game came, instead, with Spacewar—the game that introduced the fundamental combination of a continuous spatial model, a combat model, and scenario/level design to the computing world.

Navigation, Combat, and Scenario Design: Spacewar

In 1961, Digital Equipment Corporation (DEC) occupied an unusual place in the computing landscape. Though it was a sizable company selling very expensive machines, it was also seen as a radical upstart, challenging the computer orthodoxy overseen by the dominant International Business Machines (IBM).32 DEC was selling a vision of interactive computing, or working directly on a computer, that now seems everyday, but was an abrupt break with the tradition of delivering programs to computer operators (perhaps as trays of punch cards) and then waiting patiently for a reply after the scheduled run of one’s program. What DEC was selling wasn’t brand new, however. It was an experience pioneered in universities, government labs, and other research organizations—such as the MIT labs that were home to the legendary Whirlwind and TX-0 computers.

In the summer of 1961, the three people who conceived of Spacewar—Steve “Slug” Russell, J. Martin Graetz, and Wayne Wiitanen—were all working in the IBM computing paradigm (at Harvard University’s Littauer Statistical Laboratory).33 Then Graetz was hired at MIT by electrical engineering professor Jack Dennis, a recent PhD who was in charge of the department’s computers, and Russell returned to MIT’s Artificial Intelligence Group.34 Dennis gave students and staff remarkable latitude in using the computers,35 including the TX-0 and, particularly, the PDP-1 computer donated by DEC in September of 1961.36 Russell, Graetz, and Wiitanen came up with the concept for Spacewar while brainstorming what to do with the Type 30 Precision CRT display that was scheduled to be installed a couple months after the PDP-1. They wanted to outdo the existing demonstration programs for the Whirlwind and TX-0, which included a bouncing ball, a mouse that would traverse user-constructed mazes, a tic-tac-toe game, and Marvin Minsky’s generative animation program Tri-Pos (better known as the “Minskytron”).37

The first version of Spacewar was completed by Russell in February 1962. Two visually distinct ships could rotate and thrust to move across the screen in a manner governed by relatively realistic physics (momentum is key to playing Spacewar). In creating this much, Russell had already introduced another key logic for playable spatial models: navigation. Further, the two ships could fire projectiles at each other and destroy each other when there was a collision between a projectile and a ship—introducing video games’ first mechanics of combat in continuous time (figure 7.4). The wedding of these two experiences—of continuous spatial movement and combat in continuous time—became an extremely important, almost dominant, approach as video games developed further.

Focusing on Spacewar’s introduction of the navigation logic, we can see what an important difference it makes that the racquets in Tennis for Two are invisible. For a model of any domain to be playable, it must support interaction.38 That is, there must be a control logic available to players that changes the state of the model in a way that is presented to players. For continuous spatial models, the key control logic is navigation. Even a game as simple as Pong gives players the ability to navigate paddles up and down the screen. But because of the nature of Tennis for Two’s paddles, the introduction of navigation to continuous space video games fell to Spacewar.39

Figure 7.4

In a game of Spacewar, the “Needle” ship approaches the central star (right) while the “Wedge” ship fires two photon torpedoes, shown as dots brighter than the background starfield (left). Screenshot showing DEC PDP-1 display during Computer History Museum PDP-1 restoration project, as featured in “Story of Spacewar!” (Courtesy of the Computer History Museum, image number 102695600.) (Plutte, “Story of Spacewar!”)

The abstract process for navigation in this type of model could be stated as moving one (or more) virtual object(s)—and/or the rest of the virtual space apart from the object(s)—so that all the elements of one are progressively offset relative to the other, based on a player-controlled input, for as long as that input is in effect. The communicative role could be stated as the player controlling the type, and/or direction, and/or timing of the movement of a virtual object with which she identifies. (Both the abstract process and the communicative role would be different for a navigation logic in a different sort of spatial model—such as the first-person 3-D spatial model of DOOM or the link-based, textually represented model of the Crowther and Woods Adventure.)

The implementation of navigation requires that some process is “listening” for input from the player and, also, that some process can make a representation of something under the player’s control change position in the space of the model. Of course, the player’s control can be partially indirect, as when the player acts together with a physics logic. This is the case in Spacewar, where the player’s primary mechanic for movement is thrusting. The player holds down the thrust control for differing amounts of time, and the ship is rotated to different angles to provide input to the physics logic that (together with the other forces already in effect) determines where the player’s ship will navigate. Indirect control is also present in other types of games. For example, in platforming games players can often let go of (or walk off of) ledges, with the expectation that physics will take them “down” in the model’s space.

Learning to perform navigation, both directly and indirectly, begins with players identifying what represents “them” in the game state presentation, then experimenting with interface controls to learn how the navigation mechanics operate. As players become more fluent in navigation, they are increasingly able to choose actions to take in the game’s spatial model (ones that they desire and ones that the game supports) and anticipate the potential results. Player understanding may initially be considered and deliberate. But as Sudnow and others discuss, in most cases it quickly becomes a bodily understanding, with the things that represent us in continuous space games (and the interfaces that bridge our actions and theirs) coming to feel like extensions of our own bodies and “decisions” about how to act made at a preconscious level.40 If we fail to make this transition, many games (including Spacewar with a competent opponent) move far too quickly for us to succeed. Brendan Keogh—building on the work of Sudnow, N. Katherine Hayles, Henri Lefebvre, James Ash, and others—writes of this as “embodied literacy.”41

At this point in Spacewar’s development it might have been considered complete—except for one glaring problem. Over time, it wasn’t a very compelling experience. It was an exciting demo, but not something with depth, something that would pay off players’ investments of time and consideration. As Graetz writes:

Up to this point, Spacewar! was heavily biased towards motor skills and fast reflexes, with strategy counting for very little. Games tended to become nothing more than wild shootouts, which was exciting but ultimately unrewarding.42

Spacewar lacked an interesting gameplay scenario, what is often referred to as level design (though games such as Spacewar obviously are not divided into levels). It didn’t lack primarily in terms of the logics it implemented for play, though the further development of one of these was key to its next step. Rather, Spacewar lacked an interesting situation for play. It lacked a selection and arrangement of elements that would matter in terms of its models and mechanics, shaping patterns of play, opening new strategic possibilities and new skills needed to exercise them.

The solution was twofold. First, Dan Edwards expanded the physics logic of Spacewar to include gravity. Second, a large star was introduced in the middle of the play area, with a gravity well encompassing the entire area.43 Colliding with the star, like collision with a projectile, caused immediate death (which would happen relatively quickly if players applied no thrust to their ships at the start of a game). As Graetz explains:

The star did two things. It introduced a player-independent element that the game needed; when speeds were high and space was filled with missiles, it was often sheer luck that kept one from crashing into the star. It also brought the other elements of the game into focus by demanding strategy. In the presence of gravity, both ships were affected by something beyond their control, but which a skillful player could use to advantage.44

The first fruit of this new scenario was a maneuver called the “CBS opening”—because the paths of two ships executing it resembled the television network’s eye-shaped logo (figure 7.5). Skilled players, rather than immediately thrusting away from the star, would fire short blasts directing their ships to fall into the gravity well and whip around the star. This proved to be the fastest way to build up all-important momentum.45

Spacewar was complete by the end of April 1962 and was first shown publicly at MIT’s Science Open House in May. Its creators expected a crowd, and they got one. By summer the group that completed it was drifting away from MIT, but the game had taken on a life of its own. As Graetz reports, “Program tapes were already showing up all over the country, not only on PDP-1s but on just about any research computer that had a programmable CRT.”46 Unlike Tennis for Two, which could not be distributed as software, Spacewar was on its way to becoming the world’s first hit video game.

But Spacewar’s rapid spread wasn’t simply due to labs sharing tapes with each other. As historian Henry Lowood writes, the game “was shipped by DEC with PDP computers as a test program to verify their operation after new installations. Spacewar became a fixture in university and industrial laboratories of the 1960s and 1970s.”47 Spacewar was a perfect demonstration of the vision of personal, interactive computing that DEC was selling—so DEC not only distributed it, but selected it to be one of the first things seen after each successful DEC computer installation.

Further, as a testament to the depth of strategy and skill that could be brought to the completed Spacewar, Stewart Brand (of Whole Earth Catalog fame) organized a “Spacewar Olympics” at the Stanford Artificial Intelligence Laboratory (SAIL) in 1972. The event was sponsored by Rolling Stone, and Brand published his account both in that magazine and in his later book, II Cybernetic Frontiers.48 This not only served to document the game’s popularity after a decade of play but also brought that popularity to another level of public consciousness.49

Figure 7.5

Whipping around Spacewar’s central star, through the use of momentum and gravity, creates a shape reminiscent of the US CBS network’s logo in this time-lapse image. (Image from Graetz, “Spacewar! Real-Time Capability of the PDP-1.”)

Yet there appeared to be no easy way to bring Spacewar to that public. The very fact that made it almost omnipresent in the computer culture was what blocked it from the wider culture: it was software for digital computers. Such computers were simply too expensive for any sort of commercial public deployment of games, even a decade after Spacewar’s creation.

Combat in Games

In video games that include combat, the combat models are most commonly designed to work with continuous spatial models (supported by graphical logics) and resource logics. For example, in Spacewar shooting torpedoes obviously requires movement physics and collision-detection logics for their flight (together with a control logic for determining when to fire). Less obviously, there is also a resource logic involved. Though Spacewar does not treat the amount of damage that each ship can take as a resource except in the most basic sense (a single collision with a torpedo destroys the ship) the number of torpedoes a ship can fire is a time-limited resource. As Graetz writes, “There was a fixed delay between shots ‘to allow the torp tubes to cool.’”50

But this sort of observation does not give us a broader sense of how combat models operate in video games. And in fact such a broader sense is not often put into words, even if we “know it when we see it”—as Joseph C. Osborn, Dylan Lederle-Ensign, Michael Mateas, and I discovered when we worked to explore this question.51 While it is generally taken as a given that combat is modeled by many games, we were able to find no discussions—in game design, game studies, or elsewhere—that tried to be specific about what this means across game genres.52 So we began with a close examination of how particular games implement combat, especially Super Street Fighter II53 and Final Fantasy.54

Looking for the common ground of combat between them, the traditional way of talking about game design, through focusing on mechanics, offers no help. In terms of mechanics, there is almost no overlap between the real-time, physically detailed punching, kicking, crouching, jumping, and special moves of Super Street Fighter II and the turn-based, physically abstract melee attacks, magic casting, potion drinking, item using, and running away of Final Fantasy. Another popular way of discussing game design, in terms of genre, is equally unhelpful. One of these is considered a fighting game and the other an RPG.

But we were able to look at how each game implements and composes operational logics to form a model of activity that players interpret as combat. (In chapter 4 I referred to this as meeting the “communicative and procedural obligations” to be understood as a playable representation of something.) First, at a relatively abstract level, the combat models of games involve multiple agents who are able to carry out violent acts toward one another in some space. The same logics may be used in other situations, as when players attempt to destroy inanimate objects, but this is not interpreted as combat.

At a more detailed level, combat models include means to determine what actions agents may take, whether they succeed, and to what extent. Different games satisfy these requirements using different logics, implemented and connected in different ways. Super Street Fighter II, for example, uses a “stance” entity-state logic—the player’s character standing, crouching, or jumping—to determine which attacks are available. It uses collision detection to determine whether normal attacks are successful but uses a temporal pattern-matching logic for special moves. It uses the state of the opponent—who may be blocking (also the stance logic), simultaneously completing an attack of greater strength, or in some other relevant state—to determine the extent of damage to the opponent’s health (a resource logic).

Final Fantasy, on the other hand, has different logics determining the availability of different types of attacks. A mage, for example, can only cast a spell that they know (a resource logic with differentiated items, similar to many inventory logics), can only cast it if they have enough magic points left (a resource logic with undifferentiated items), and can only cast spells at all if they are in an appropriate entity state (for example, not in a silenced state)—whereas different considerations would come into play if the mage attempted a melee attack. Similarly, rather than the success of melee attacks being determined by visible collision detection (and largely driven by player skill) as in Super Street Fighter II, the success of Final Fantasy attacks is determined by largely invisible chance logics (parameterized by character attributes, which can change over time)—making player skill in Final Fantasy battles more akin to skill at Blackjack than skill at Basketball.

These are two different approaches to deciding what actions agents may take, whether they succeed, and to what extent. In addition, to complete a combat model, a game must implement its logics such that combat actions have observable effects, must define the circumstances under which characters enter and leave combat, and must define how instances of combat themselves come to an end.

This outline of combat in games helps us know what we should examine when trying to understand a game’s combat model and when comparing it to the models of other games. And it also helps us understand when what we are seeing is not combat. For example, consider Molleindustria and Jim Munroe’s game Unmanned.55 This game stands out for both employing and interrogating combat. The player character is a drone operator who lives in the western US but remotely pilots military drones located in the Middle East. The game seems to be built on two models: a link-based dialogue/story model and a combat model of the sort just described. The dialogue/story model drives the experience of the operator talking to himself, his co-pilot, and his wife and son. The rest of the game consists of two representations of mediated violence: using the drone for tracking and shooting targeted people in the Middle East (figure 7.6) and playing a modern warfare-themed video game at home with the character’s son.

Figure 7.6

In the split-screen game Unmanned, the two panes are used to show different types of gameplay, as well as dialogue, character portraits, landscapes, and more. Here the left side displays choices in the link-based dialogue/story model and the right side displays missile targeting in what we might call its “hunting” (rather than combat) model. (Creative Commons image from molleindustria.org.)

But if we examine Unmanned using the idea of a combat model described here, it becomes immediately clear that only one of these activities actually represents combat. While the game-within-the-game employs such a model exactly, the drone operation portions have only one agent capable of taking violent action: the player character. This is therefore not a model of combat, but rather a model of something else—perhaps hunting. Only the state is capable of committing violence in this circumstance (of course, this asymmetry is the norm for state violence). Unmanned uses a combat model in its game-within-the-game precisely to emphasize what most military-themed games elide: the model of combat in games is not the model of much of the violence carried out by the US military—despite the rhetorical stance of games like America’s Army.

The Importance of Implementation: Computer Space and Pong

Lowood’s excellent article “Videogames in Computer Space: The Complex History of Pong56 tells the story of what happened after Spacewar’s unprecedented spread through the 1960s computer culture. He traces the converging paths of commercial video game pioneers Nolan Bushnell and Ralph Baer, and in doing so tells the story of how certain approaches to continuous spatial models—and the game designs they supported—became dominant in the early video game arcade machines and home consoles.

Bushnell’s story is the more famous. He graduated in 1968 from the University of Utah, where he later claimed to have played Spacewar, and moved to California to work for the technology company Ampex. This was not far from Stanford University, the future site of SAIL’s Spacewar Olympics and the likely site of Bushnell’s actual first exposure to the game.57 Working with fellow Ampex employee Ted Dabney, Bushnell sought a way to commercialize Spacewar—but the great expense of even stripped-down digital computers (such as the Data General Nova) made it seemingly impractical. Two others actually did this, but only in a limited manner, as Lowood reports: “[A] recently graduated SAIL student, Bill Pitts, and his friend Hugh Tuck built a coin-operated (coin-op) computer game, The Galaxy Game, for the newly released PDP-11/20, DEC’s first 16-bit computer. . . . [They] converted the PDP-10 version of Spacewar for this machine.”58 With a total expense of $20,000 (including computer, display, cabinet, and controllers) it was clearly not a route to reaching the broader public.

What Bushnell and Dabney came to realize was that the only practical route was to attempt to implement the key operational logics in hardware—using television technology—rather than in software for general-purpose digital computers. In pursuing this route, they were able to reproduce a good number of Spacewar’s key elements in innovative new implementations. For example, as Lowood writes:

[A] small number of diode arrays connected to logic gates produced the rotating images of rockets seen on the screen; the rocket images were clearly visible even in the pattern of diodes on one of the PC boards. . . . Bushnell’s rockets were essentially hardwired bitmaps that could be moved around the screen independently of the background, a crucial innovation that made it possible to produce screen images efficiently.59

This enabled the logic of navigation. However, other elements had to be stripped out, most notably reducing the physics logic to remove gravity—and with it Spacewar’s central star scenario design (figure 7.7). The result, Computer Space, was released in August 1971 by Nutting Associates. Computer Space failed to become a hit, while Pong was a great success the following year. This is one of the most discussed pairs of events in video game history, and the outcome is generally attributed to the complexity of Computer Space as compared with Pong’s simplicity.

For example, Mark J. P. Wolf writes, “The first arcade video game, Nolan Bushnell’s Computer Space (1971), failed commercially, because players found its controls difficult to understand and use, and it was not until Bushnell’s second effort, Pong (1972), which had a single control and simplified graphics, that the videogame as a commercial entity finally found success.”60 John A. Price offers a similar comparison, writing that Bushnell and Nutting Associates “released the world’s first commercial video game under the title of Computer Space in 1970. Only 1,500 of the machines were sold, in part because the game was too complex and too difficult to play. Determined to come out with a game that was not too complex, in 1972 Nolan Bushnell started the Atari Company. Their first game was a Ping-Pong game called Pong for the arcades. Pong was highly successful and it was widely imitated.”61 Montfort and Bogost tell the story in similar terms, observing that Bushnell sought a way to bring an experience like Spacewar to the public, and the result “was Computer Space, which arcade game manufacturer Nutting Associates released in 1971 to very limited commercial success. Complexity of play was part of the problem—the general public wasn’t accustomed to arcade games. . . . Pong solved the problem that plagued Computer Space—ease of use—partly by being based on the familiar game table tennis and partly thanks to the simplicity of its gameplay instructions.”62

Figure 7.7

Computer Space had the dueling spaceships of Spacewar—both in the original single-player version and a later two-player release—but without gravity and the central star. This was previously found to be a less-than-compelling experience when the original Spacewar was being developed at MIT. Unfortunately, Bushnell and Dabney do not appear to have known this, and Bushnell later blamed the limited success of Computer Space on its complexity. Image of Computer Space from a cabinet repaired by Ed Fries. (Image courtesy of Ed Fries.) (Fries, “Fixing Computer Space.”)

Interestingly, the common version of this story offers no source for the idea that it was over-complication that led to Computer Space not becoming the first hit video game. Those that do cite a source indicate that Bushnell may be a contributor to (or even the originator of) the idea. Wolf writes, in a different book from the earlier quote, “Bushnell attributed the lack of success of Computer Space to be partly due to the complexity of the game’s instructions and its gameplay mechanics.”63 Lowood quotes Bushnell as saying that “‘the typical guy in the bar’ was completely baffled.”64 Steven L. Kent writes in The Ultimate History of Video Games, “Bushnell admits that the instructions were too complex: ‘Nobody wants to read an encyclopedia to play a game.’ He also blames Nutting for marketing the game badly.”65 Tom Sito offers the same Bushnell quote, in his Moving Innovation: A History of Computer Animation, “the instructions were too complicated. ‘Nobody wants to read an encyclopedia to play a game,’ Bushnell confessed.”66 Sito writes this despite noting, on the previous page, that the more complicated Galaxy Game (discussed earlier) was being played by the “coffeehouse habitués” on the Stanford campus, only a few miles away from where Pong would become a hit.

There are, of course, many other reasons one might imagine for Computer Space not catching on as Pong did. Perhaps it was the fact that it was a single-player game at first, with a two-player version not introduced until 1973. Maybe the issue was cabinet design—as Guins notes, the wood grain design of Pong (as opposed to the fiberglass cabinet of Computer Space) was such that it would fit into many more contexts.67 Maybe it was a game scenario that, while compelling in the computer subculture, didn’t resonate with the broader public.

But a different explanation is suggested by the facts already discussed in this chapter. The design of Computer Space—essentially, Spacewar without gravity and the central star—was already known to lack compelling gameplay in February of 1962 when the game was still in initial development at MIT. While complexity may have been an additional issue, it seems likely that the key reason for the limited success of Computer Space is that the versions of its operational logics that could be implemented in commercially viable technology could not support a compelling version of Spacewar-style game design. As former Atari employee Jerry Jessop commented to the New York Times, “The game play was horrible.”68

Matt Barton’s account, in Vintage Games 2.0, is the only one I have found that directly discusses the gap between Bushnell’s preferred story and the realities of Computer Space gameplay:

Bushnell concluded that the game was too complicated for gamers accustomed to pinball. “The lesson was,” said Bushnell, “keep it simple.”

However, Computer Space’s failure is probably owed more to its dull gameplay than dull-witted players—as later, more successful efforts show.69

As Barton suggests, should we require further evidence that a game of Spacewar’s complexity could be a success outside the lab, we need only look at the story of Space Wars,70 a 1977 version developed by Larry Rosenthal for Cinematronics. As Barton and Bill Loguidice write, “Rosenthal’s key innovation was developing a special processor, which was cheap to make yet still sophisticated enough to run the full version of Spacewar!, complete with the gravity well and two-player dog fighting that made the original so compelling.”71 Rather than turning off audiences with its complexity, “it was a wonderful adaptation of Spacewar! and earned rich profits for Rosenthal and Cinematronics,” Barton and Loguidice conclude.

Looking again at the hardware for these early games may help clarify why Computer Space’s development resulted in its particular design. Lacking Rosenthal’s specialized processor, it appears that the implementable spatial models, and the gameplay they could support, were significantly determined by available television technology. Ralph Baer’s story, running in parallel with Bushnell’s, helps illustrate this. As Baer reports in Videogames: In The Beginning,72 in 1966 he was working at Sanders Associates and, while waiting for a bus, returned to previous musings about using home televisions as game devices. After some unofficial work by himself and Bob Tremblay, Baer got approval to pursue the project further, bringing in Bob Solomon, Bill Harrison, Bill Rush, and others. The team developed technology prototypes and games at the same time, including games with player-controlled objects chasing each other, “pumping” games in which players tried to raise or lower color levels (for example, one player trying to raise blue water behind a screen overlay of a burning house, while the other tried to lower red fire from the top of the screen), and multiple-choice games. But nothing seemed compelling enough to justify a home unit’s likely cost.

When Rush suggested a third, machine-controlled object (in addition to the two player-controlled ones) the Sanders Associates team quickly found themselves converging on the types of Tennis/Ping-Pong games that Higinbotham had pioneered (though Baer’s team was likely unaware of Tennis for Two). This might seem like a doomed project, given the discussion here. After all, gravity was as central to the design of Tennis for Two as it was to Spacewar—maybe even more so, because the fundamental gameplay of Tennis for Two was lobbing the ball back and forth, choosing the right moment in its parabola to hit the button and “return” the ball to the other player along another gravity-controlled arc.

The Sanders team didn’t invent video games (as Baer and others have suggested). But they did come to a crucial realization: that a compelling Pong-like video game could be created without gravity implemented in its physics logic. What this required was (literally) a different perspective from that pursued by the BNL team. Rather than the “side view” of Tennis for Two (as though sitting near the umpire, looking down the line of the net), the Sanders team adopted a “top-down view” (as though looking at the game from above, with the net stretched from top to bottom of the screen). When seen in this way, the gravity-defined arcs of the balls in such games would become much less salient, such that they could be abstracted away while still having the video game be interpretable as a procedural representation of the physical world gameplay.

This sort of gameplay turned out to be compelling. And without the need for gravity, it could be supported by relatively low-cost television technology. As a result, the Sanders team had an appealing game using components that could potentially be sold in a home consumer unit. This led to a licensing deal with television manufacturer Magnavox—which then produced the groundbreaking Odyssey, the first home video game system, released in 1972.73

The Odyssey system was first demonstrated in spring, but not released until summer—a gap that proved important. Bushnell attended an early demonstration and, shortly afterward, Bushnell and Dabney separated from Nutting and founded the company that would become Atari. They were soon joined by another ex-Ampex engineer, Al Alcorn, who Bushnell assigned to create a simple Tennis/Ping-Pong game—which he characterized as the simplest game he could think of. However, as Lowood writes, “When he tasked Alcorn with a ball-and-paddle game, his suggestion must have been influenced by what he had seen from Magnavox.”74

Alcorn’s top-down view game, christened Pong, was launched in a tavern later in 1972 and—as noted in multiple accounts quoted earlier—became an immediate hit, initiating the arcade era of video games. It presumably even helped drive sales of the Odyssey, which for a time was the only way to play a Pong-like game at home. In becoming such a great success, Pong demonstrated to the world that Tennis/Ping-Pong games are a design “sweet spot” for the kinds of simple, continuous spatial models that could be implemented with television technology. Many similar games from competing companies were launched in both the arcade and home markets in the coming years. (And it was Magnavox’s decision to sue these companies, Atari, and others, that led to the rediscovery of Tennis for Two.)

Logics and Models as a Historical Lens

With the launch of Pong-like games, the initial invention of playable models of continuous space (in continuous time) for video games was completed. Of course, significant inventive work remained to be done, and would shape the future of games when it arrived. For example, the rise of the FPS genre would only take place after the invention of the implementations that would allow for real-time 3-D spatial models on consumer-level hardware. As with Spacewar, pairing with a combat model would be important to the success of the FPS and others. And as noted in chapter 4, the underlying technologies and design practices would benefit from long-term military investment—some of it indirect—as seen in this chapter with the prominence of BNL and MIT’s TX-0 lab, both of which depended on military funding.

My main interest here is not simply to retell the story of these games, which is often told. Rather, it is to tell it with attention to the specifics of the versions of the operational logics that were actually implemented for these early games, how they were implemented, and what playable models and gameplay scenarios these enabled. Doing this here has revealed that one of the most widespread game history stories—of the complexity that kept Computer Space from Pong-like success—is at the very least partial, and more likely simply mistaken. By engaging the limitations of the television technology with which Computer Space was implemented, we can understand why its physics logic lacked gravity. By looking at the importance of adding gravity to the physics logic of Spacewar, and how it achieved compelling gameplay only after this addition, we can understand that it was likely a lack of compelling gameplay that led to the fate of Computer Space. We can’t know for certain how the story of Computer Space’s overcomplication became so widely accepted—but we can speculate that Bushnell, the source most often cited, would have been happier to have Computer Space known for overestimating its audience than for being uninteresting at its core.

At the same time, this chapter’s tracing of gravity’s role in early spatial models for games has revealed something further. While gravity was part of the physics logic of the earliest known Pong-like video game (Tennis for Two), it was established by the Sanders team that such designs could succeed without gravity through a change in gameplay perspective. Pong, the first hit video game, lifted this changed perspective from the in-process Magnavox Odyssey. In short, the story of Computer Space versus Pong is actually of one game design known to fail without gravity as part of its physics logic versus another game design known to succeed under such circumstances—the circumstances that faced all parties at the launch of the coin-op game era.

We need to start telling these stories differently. And it is my hope that we can also begin to use attention to the specifics of logics and models—and their implementations, even when these stretch beyond the comfort zone of software implementations—to reconsider other widespread stories about game history. That said, this book will not continue to focus on the history of inventive work with graphical logics, the playable models they supported, and the game genres those enabled. Rather, it will turn to the expansion of how the underlying logics were used, and the creation of models of space that are also meant as models of more.