Dwarf NORAD: A Glimpse of Counterfactual Computing History
When most people think about the kind of super-high-performance games people build custom PCs for, they probably imagine some first-person shooter with fast action, huge explosions, and millions of polygons being rendered to the screen at real time. Few people would think of Dwarf Fortress, a game that is rendered with simple ASCII characters and in that, they would be remiss. As a recent Polygon article notes, Dwarf Fortress can bring most PCs to a grinding halt as it sucks up CPU power in order to generate hundreds of years worth of fictional history in a few minutes, and people do, indeed, build custom gaming PCs geared toward running Dwarf Fortress more smoothly. Although the game’s aesthetic may draw from early ASCII games such as Rogue, ZZT, and Kroz, Dwarf Fortress is far from being a “retro” game (it doesn’t, as Angela recently discussed, build on our memory of past games). In fact, like modern shooters with their coveted arsenals of polygons, Dwarf Fortress is a game that would have been technologically impossible with 1980s hardware.
As a game that is essentially a huge history simulator, there is plenty that I could say about Dwarf Fortress (and I have said a few things elsewhere). At the moment, however, I don’t want to focus on the game’s ability to create history, but rather on the ways in which the game as a whole defies history, or at least helps us imagine how computing history might have been different.
As I just mentioned, Dwarf Fortress is dramatically different from most modern videogames. Although it still requires plenty of processor power, that power is spent on crafting elaborate narratives, rather than complex physics simulations and graphics rendering. Why don’t more games take this route? Well, for computers, explosions are much easier to create than stories. In fact, computers can create explosions faster and better than even the best human animators could. This is not the case with storytelling. Computers are inherently better at things like simulating physics than at crafting narratives.
But did they have to be?
In his book From Sun Tzu to Xbox, Ed Halter (2006) makes a very convincing argument that many of the conventions in videogames that we take for granted can be traced back to constraints that were placed by many of the early developers of computing technology. As he notes, early computers like the ENIAC , with its stored memory and its binary language of ones and zeros, were created for purposes such as calculating ballistic tables. As computers advanced, their development continued to be shaped by large Cold War military projects, such as the Semi-Automatic Ground Environment (SAGE), which made large contributions both to the graphical capabilities of computers, through the creation of the “display scope,” and to the development of input devices, in the form of the light gun. A decade later, when Steve Russell was creating Spacewar! at MIT, the PDP-1 he was working on still looked remarkably similar to the original SAGE display scopes.
The most significant similarities between these early computers, however, was not their round display screens or their cabinet-like processors, but the way that they functioned. Since the beginning of the modern computing age, computers had been built for the purpose of tracking objects in space. The proclivity to compute and simulate real-world physics was built into their very design from the beginning. As such, it should come as no surprise that many of the first videogames like Spacewar!, Tennis for Two, and Ralph Baer’s Brown Box (that would go on to inspire Pong) all revolved around the basic mechanic of tiny objects moving around a screen and colliding with one another in physically accurate (or at least believable) ways. As Halter notes:
…the fact that these three early games all followed the bouncing ball was not a mere coincidence. Early designers had to work with the capabilities of the computers at hand; that simulating a projectile appears to have come naturally to three different inventors, completely independent of one another, suggests that there is something essentially basic in this design all three tapped into.
This inherent bent toward physical simulation has gone on to influence the development of every console and every game from Pong, to the Atari VCS, to Doom, to the profusion of shooters and simulators we have today.
As with Dwarf Fortress, many of the most interesting and influential games were not those that centered around the hardware’s inherent strengths, but those that worked within those constraints to create something that the system was not specifically designed for. One notable example is the Atari game Adventure, created by Warren Robinett. Adventure was inspired by older text adventure games such as Hunt the Wumpus, and Colossal Cave Adventure. Unlike the computers that these text-based games were played on, the Atari VCS was designed for action games, particularly two-player action games like Pong and Combat. The VCS could only hold two sprites in memory, designed primarily for the paddles, tanks, or other avatars of the two players (Montfort and Bogost, 2009). Although most single player games used one of the two sprites to represent the player, Robinett wanted to use them both for the items and enemies the player encountered in order to flesh out the game world. With no sprites to represent the player, he chose to represent the player with a “ball,” as the VCS had a special piece of memory dedicated to representing one for games like Pong. Thus, the protagonist of the game Adventure became a tiny square.
While innovative developers have created a great diversity of videogames in spite of the limitations often placed upon them by computer hardware, it’s often hard to imagine what videogames might have looked like under a different set of constraints. What would videogames have been like if the development of modern computers had been fueled by something other than the military? What if the ENIAC had been created to serve historians or artists, rather than artillery commanders?
Such counterfactual histories are hard to imagine for a number of reasons. While imagining a world where historians have millions of dollars to spend on developing a digital computer is difficult to fathom in its own right, it’s hard to imagine a computer that deals with something other than numbers. Computers are naturally mathy creatures. Physics, ballistics and other mathy fields are a much easier to pair with the development of the computer than fields in the humanities. Still, it’s important to note that while the ancestors of the modern computer mostly include abstract mathematical devices such as the abacus and Babbage’s difference engine, they also include devices such as the Jacquard loom. While the purpose of most other computing devices was to generate precise mathematical results, the purpose of Jacquard’s loom was to create detailed pieces of art. Writing a program for a Jacquard loom may have been somewhat mathy, but it certainly wasn’t math. What if the history of the computer had continued down this route? What if the purpose of early computers was creative expression first and mathematical complexity second, rather than the other way around? Could we imagine a history where narrative construction was the primary focus of videogames and physics simulation took a back seat?
In the end, the important thing isn’t what this hypothetical world full of digital Jacquard looms might have looked like, but realizing the often subtle ways in which the attitudes and assumptions of people a hundred years ago still influence the games we play. As developers, it’s important that we understand the underlying constraints and allowances that are built into the physical artifacts we use to create games. This is important not just so that we can take advantage of them, but also so that our games can overcome them.
Ed Halter, (2006). From Sun Tzu to Xbox: War and video games.
Nick Montfort and Ian Bogost, (2009). Racing the Beam: The Atari Video Computer System