Bitwise

by David Auerbach

  In other words, the stats of D&D aren’t just a tool for playing a game. They function as the interface to make the gameplay more deeply meaningful to a player. The stats assist in representing that player’s character, who in turn plays the role of the character the stats describe. Jon Peterson describes the core appeal of role-playing games as offering players the ability “to discover a persona worth embodying” via “modeling imaginary people.” When labels and numbers are piled atop one another in service of describing people, whether in MBTI, MMPI, OCEAN, DSM, D&D, or any other system, their folk ontologies offer us personae to play.*7

  The limits of D&D were, in large part, the limits of the Dungeon Master. A DM could keep track of only so much data about the players and the creatures they encountered. So while D&D expanded, the number of factors in play at any one time didn’t. This acted as a hard limit on just how complex the underlying mechanics of a game could be. The human work required to bring D&D closer to the complexity level of “reality” would be not just time-consuming, but hopelessly tedious. Computers, however, thrive on tedium.

  Deterrence and Détente

  Now learn how very frail an image is.

  —LUCRETIUS

  As originally conceived, the mechanics of D&D-like tabletop role-playing games had to be transparent to players: the numbers and arithmetic had to be obvious and in plain sight, so that what happened in the game made sense. D&D was extensive yet mechanically simple. The danger of having overly complex and rigid rules is twofold. First, they make the Dungeon Master’s job a nightmare, stifling creativity while demanding meticulous analysis of player actions. Second, they make it harder for players to understand why their actions are having the effects they are having, because the calculations are opaque. If a player gets whomped by an orc, the player should have been able to assess the danger of the situation ahead of time, even if the exact numbers are unknown. D&D keeps cause and effect clear.

  But with a computer acting as the Dungeon Master, entire layers of simulated reality can be opaque to the players, just as in real life we go about unaware of the semiautonomous workings of our body’s systems and the chaotic processes of the weather. With the management of a computer, the behavior and appearance of a harlot no longer need to be obtained from a single number between 1 and 100, but can be determined through a more complicated model of personality and the social world, incorporating economics and genealogy.*8 It need not be a harlot; it could just as easily be a monster, or a corporation, or a nation.

  My introduction to these more complex models came through a classic simulation game of the 1980s, Chris Crawford’s Cold War geopolitical simulator Balance of Power. Originally published in 1985, it was critically acclaimed, even garnering a review from Jimmy Carter’s deputy national security advisor, David L. Aaron, in the New York Times. Aaron took note of the game’s simplifications, but praised it for being both compelling and educational. In taking on the role of either the United States or the USSR, a player tries to win over some of the eighty non-superpowers either directly or indirectly. If you meddle too much in your opponent’s sphere of influence, they would object, at which point you could either back down (at the cost of “prestige,” which was more or less your score in the game—your ability to influence world affairs), or you could…escalate. The computer in turn would either back down or escalate, and DEFCON 3 would turn into DEFCON 2, which would turn into DEFCON 1. I remember the screen that greeted me when DEFCON 1 was reached:

  The result of a game of nuclear chicken in Balance of Power

  Anyone who played the game saw this screen a lot. In my first game playing as the United States, I sent troops into Iran to fight for the rebels, oblivious to more or less every geopolitical consideration, and saw the Soviets immediately object. Boom. Then the Soviets sent troops into a civil war in Brazil, which I thought absurd. They didn’t back down. Boom. Aaron had a similar experience: “A dozen tries later, I was still destroying the earth with depressing consistency….The more I played Balance of Power, the more my self-destruction stemmed from an unwillingness to back down in a crisis.” Every conflict was a Cuban Missile Crisis, and the chief lesson of the game, inasmuch as there was one, was that in a nuclear world, one should pick one’s battles extremely carefully.

  My greater fascination, though, was with the book Crawford wrote that explained the math the computer used to determine whether to push its luck. The computer player’s logic was based on a calculation of Outrage over a particular player action:

  Suppose that a crisis erupts over some truly insignificant action, such as economic aid to Nigeria. Players often find to their dismay that the computer will escalate right up to DefCon 1 in such situations. Why, they complain, would the computer destroy the world over such a trivial issue?

  The answer is, because you would destroy the world over such a trivial issue. The computer analyzes the conflict and finds that its Outrage over the issue is small, such as 22. It finds, however, that the human pleasure over the issue is even less, such as –18. When it adds the two numbers together, it gets a +4 result and concludes that it is justified in taking a firm stand. If the human can ask, Why would you destroy the world over a measly 22-point crisis? the computer is even more justified in asking, Why would you escalate to DefCon 2 over something that was worth only 18 points to you? It takes two to make a fight.

  I was interested not only in the algorithm, but also in how Crawford had chosen to calculate outrage based on six other variables:

  Slight elements of randomness were used to make the game nondeterministic, but the model was tight. It was the product of Crawford’s mind, but it was a mind that had read George Kennan, Henry Kissinger, and others, and had then engineered a playable model of the dynamics they described. The game felt mechanical, yet it showed that such mechanical models could do more than approximate how hard a barbarian could bash an orc—they could also present abstract psychological and political concepts. The geopolitical environment that evolved over a game of Balance of Power felt nearly organic. Its limitations were primarily those of the computers of its time. There was only so much space on a floppy disk and only so much processing power on the computers for which Balance of Power were written, and the complexity of its geopolitics was limited by the requirement that the game spend seconds, not minutes, calculating the effects of the player’s actions each turn.

  The Quantified Dwarf

  Our empirical language can only be understood as an incoherent and fragmentary schema of an ideally coherent language.

  —WILFRID SELLARS

  The computational limitations that Balance of Power faced are no more. Computers are over ten thousand times faster now than they were in 1985. Data-processing capacities are not quite unlimited, but when it comes to simulations, computers now offer the ability to construct worlds that do not reduce to a handful of equations, but are complex ecosystems in and of themselves. The average computer role-playing game today is far richer algorithmically than Balance of Power or D&D. “Physics engines” provide realistic modeling of three-dimensional motion. Game action can take place in real time rather than requiring sequential, turn-by-turn choices. The drive for verisimilitude and precision, combined with the sheer computational power provided by PCs, has allowed for the creation of virtual worlds beyond what Gygax ever could have crafted by hand. These worlds contain quantitative systems so complex that their interactions can lead to counterintuitive and unpredictable results—even when the individual systems themselves have been coded logically and intuitively. Such worlds can begin to compete with our own—and imitate it.

  The mania for quantification reaches its peak in the game Dwarf Fortress, which, despite the fantastic name, is one of the most meticulously literal-minded simulations around. The premise is simple: the player is the overseer of a band of a few dozen drunken dwarves, who attempt to build and secure a safe homestead insid
e a mountain, navigating the dangers of natural disasters, hostile wildlife, invaders, and their own sheer irresponsibility and incompetence. The player issues orders, but the dwarves themselves are autonomous entities who act based on hidden psychological modeling. They may obey, disobey, lose hope, cheer up, eat, drink, fight with one another, reproduce, make art, panic, and (rather frequently) die of their own volition. You lose when all your dwarves die; the game has no success conditions other than continuing to survive. The brainchild of auteur Tarn Adams, who estimates the game will take another twenty years to complete, Dwarf Fortress makes no concessions to commerciality or accessibility and subsists through the support of a group of diehard fans, who see the game as the ne plus ultra of strategic simulations.*9 Its level of complexity would be impossible on the tabletop, but a computer can model a dwarf’s body, determine whether an attack has bruised the dwarf’s arm, collarbone, or kidney, and factor that into the ongoing game state, even if the player is not made aware of these conditions.

  Tim Denee’s schematic of his Dwarf Fortress “Oilfurnace”

  The design goal of Dwarf Fortress is to create a fantasy world that behaves as the real world does. The game has its own internal models of physics, biology, agriculture, weather, bodies, creature motivations, and even chemistry, so that when a surprising event occurs, it will nonetheless make sense in that it relates to something a player would expect from that situation in real life.

  The standard interface of Dwarf Fortress. The seven happy faces are dwarves.

  Dwarf Fortress’s realistic combat simulation, down to modeling of individual toes

  Dwarf Fortress takes the life-simulation approach the furthest of any game, and in doing so shows where such approaches break down. In particular, it illustrates the problems that can arise with computational models based on folk taxonomies. Balance of Power’s limitations are felt in the sheer number of factors left out (trade, treaties, religion), but the limitations of Dwarf Fortress emerge through the interaction of the innumerable factors it includes. The same complexity that gives convincing richness to the world also lets that world spin out of control past its creator’s intentions.

  Dwarves may be seized by the urge to create, leaving engravings on the wall for future explorers to find after a settlement has died out. The engravings, computed by algorithm from a fairly large set of possibilities, reflect the dwarf’s psychological state and past experiences, such as a “masterfully designed image of a dwarf…The dwarf is screaming.”

  A procedurally generated engraving by a dwarf

  The infamous chronicle of the “Boatmurdered” fortress tells of a miserable clan surrounded by wild and angry elephants that have a habit of killing dwarves. A group of players took turns running the fortress. Early on in the game, one player constructs a mechanical doomsday device that, when released, floods the entirety of Boatmurdered’s surroundings with lava.*10 A subsequent player triggers this device in desperation after his dwarves accidentally break through the aquifer beneath the entire area and flood the outside terrain, in the hopes that the lava will evaporate the water. It does, but in doing so, scalds and kills elephants and dwarves alike, leaving a deadly cloud of steam and the purple miasma of decaying corpses.

  Lava meets the floodwaters, producing a white and gray cloud of steam and burning everything alive.

  All this activity plays out on top of Dwarf Fortress’s byzantine world-modeling algorithms. Adams’s intent is for the systems of the world to be constructed generally rather than specifically. That is, rather than coding up the behavior of water and lava separately, Adams constructed a generalized fluid dynamics model for the game, from which the flow of any liquid under different situations of pressure could be derived. Likewise, weather is not just something that makes objects and creatures cold and wet, but emerges from an entire meteorological model that can produce fog, rain, snow, and all the major types of clouds, depending on the underlying conditions. These models collectively create a believable, primitive environment in which each aspect is modeled with sufficient realism that the interactions between these systems are also realistic—most of the time.

  Dwarf Fortress’s sheer number of interacting subsystems can produce unpredictable and surprising results, as in this example:

  Once, a town’s executioner had to execute a criminal with his teeth because he had lost both of his arms. He ended up biting the other dwarf’s arm off and the command to spit the arm out never fired, so for years in-game the dwarf walked around with an arm in his mouth.

  Execution-by-biting-limb is not a bug, since the criminal was indeed executed—only the failure to spit the arm out is. I can hazard one guess as to how this happened. The death sentence demanded that the executioner “attack” the criminal until the criminal was dead. The complex attack logic looked first to what weapons the executioner could use, but found that there were none because the executioner had no arms. The attack logic then turned to teeth and biting as an attack form, possibly seeing it as more deadly than kicking or head-butting. Yet after the executioner killed the criminal by biting the arm off, the executioner failed to spit the arm out because the situation was not typical combat. Normally, combat would result in other dwarves observing the fight, maybe getting involved, getting angry, etc. But in dwarf society, as in our own, an execution is a special case of combat in which others are not supposed to get involved. It is regulated by an implicit law.*11 Rather, executions were most likely designated as special case events, and certain mechanisms in dwarves that would normally cause them to react in violent ways were switched off. One of these disabled combat mechanisms, however, also affected whether the executioner would spit out a limb after biting it off—as outside of combat, a dwarf wouldn’t end up with an opponent’s limb in his or her mouth. So the special case produced a previously unknown bug. This is only my guess, however. Perhaps the arm simply wasn’t coded as something that needed to be spit out.

  Adams himself describes exactly such a case involving cats getting drunk and vomiting. This bug (what in software terms might be called a “corner case”) demonstrates, acutely, how seemingly logical computer models can produce illogical behavior when joined together.

  I added taverns to fortress mode, so the dwarves will go to a proper establishment, get mugs, and make orders, and they’ll drink in the mug. And, you know, things happen, mugs get spilled, there’s some alcohol on the ground.

  Now, the cats would walk into the taverns, right, and because of the old blood footprint code from, like, eight years ago or something, they would get alcohol on their feet. It was originally so people could pad blood around, but now any liquid, right, so they get alcohol on their feet. So cats will lick and clean themselves, and on a lark, when I made them clean themselves I’m like, “Well, it’s a cat. When you do lick cleaning, you actually ingest the thing that you’re cleaning off, right? They make hairballs, so they must swallow something, right?” And so the cats, when they cleaned the alcohol off their feet, they all got drunk. Because they were drinking.

  But the numbers were off on that. I had never thought about, you know, activating inebriation syndromes back when I was adding the cleaning stuff. I was just like, “Well, they ingest it and they get a full dose,” but a full dose is a whole mug of alcohol for a cat-sized creature, and it does all the blood alcohol size-based calculations, so the cats would get sick and vomit all over the tavern.

  People helped me with this. We were all looking and figuring out, “What the heck is going on here?”, and that was the chain of events. It’s like doing the detective work to figure out that entire chain of events is what happened. You can see how adding just a tavern that gave the opportunity for spilling alcohol, which was really uncommon before, now all the spilled alcohol starts to form in one location where something could start to happen. You activate bugs and little parts of code fr
om eight, six years ago where you just didn’t balance the numbers because it didn’t matter. You don’t want to spend time doing balancing that doesn’t matter, because then you lose a couple of days doing something for no reason.

  What’s crucial here is the combination of meticulousness and intuition—the same combination evident in Crawford’s book on Balance of Power. Adams is comprehensive to an extent that would make Gygax blush, and programming requires him to fix and flesh out his mechanics in far greater detail than Gygax ever had to, but many of those details are constructed off-the-cuff. This is not true in every case: in the instance of weather and fluid mechanics, Adams did a great deal of research into physical laws and how they should function. But in the cases of human and animal behavior in particular, Adams compromises. In the cat vomit case, Adams underspecified a number of commonsense mechanics. Each in the series of mechanics, from cats’ paws soaking in alcohol to cats licking paws to cats throwing up drunk, makes sense in isolation, but when combined, they produce a ridiculous result. Adams describes the process as one of manually determining every possibility:

  There are so many interlocking systems now, and when you say, “interlocking system,” I mean, sometimes it’s these random events like the cat thing where it just happened to work that way, but more often the interlocking is you manually make the spokes and little gear teeth. That’s what you’re doing. You’re adding each little one that fits in with every gear you could think of. There’s more gears that would fit in too if you remembered they were there, and you just do as much as you can. Every system probably relates to every other system in some way. Those just haven’t all been realized yet….You don’t have to find every connection but you just don’t break the game so bad that it falls apart.