March 11, 2008
EP 8.1: Eliza and SimCity
In the early 1980s, Will Wright was working on his first game: Raid on Bungeling Bay (1984). Wright was crafting an attack helicopter simulation, focused on flying over islands and open water, attempting to destroy a set of factories working toward the creation of an unstoppable war machine. Then, reflecting on the landscape editor he created for authoring the game, Wright had a realization: “I was having more fun making the places than I was blowing them up” (2004). From this the idea for Wright’s genre-defining game SimCity (1989) was born.
SimCity is a simulation game. Like a terrain editor, it is an interactive tool for defining spaces, specifically cities.1 Unlike a terrain editor, SimCity doesn’t simply wait for a user to do something. Time begins passing the moment a new city is founded. A status bar tells the player what’s needed next — starting with basic needs like a residential zone and a power plant and, if play succeeds for any period, ramping up to railroads, police stations, stadiums, and so on. A budding city planner can lay out spaces, but it’s up to the city’s virtual inhabitants to occupy them, build and rebuild, and pay the taxes that allow the city to continue to grow.
As cities grow, areas respond differently. Some may be bustling while others empty out, or never attract much interest at all. SimCity provides different map views that can help diagnose problems with abandoned areas. Is it too much pollution? Too much crime? Too much traffic? Players can try changing existing areas of the city (e.g., building additional roads) or create new areas with different characteristics. Observation and comparison offer insights. Why is this commercial area fully developed, while that one lies fallow? The answer is always found by trying something different and considering the results. And players who aren’t learning quickly enough through experimentation receive helpful feedback (figure 8.1).
Figure 8.1: In SimCity Classic (running here in the DosBox emulator) players who ignore graphical depictions of heavy traffic get other forms of feedback. The status bar provides some — above reading “Frequent traffic jams reported” — but they can escalate to warnings such as the one shown here.
In other words, the process of play with SimCity is one of learning to understand the system’s operations. Conversely, the challenge of simulation game design is to create a surface-level experience that will make it possible for audiences to build up an appropriate model of the system internals. As Wright puts it:
As a player, a lot of what you’re trying to do is reverse engineer the simulation. . . . The more accurately you can model that simulation in your head, the better your strategies are going to be going forward. So what we’re trying to [do] as designers is build up these mental models in the player. (Pearce, 2002)
As this comment reveals, the goal of a simulation game is quite different from that of a system like Eliza/Doctor, which plays on our expectations in order to disguise the simplicity of its operations. At the same time, a version of the Eliza effect is a necessary starting point, as Wright explains:
You’ve got this elaborate system with thousands of variables, and you can’t just dump it on the user or else they’re totally lost. So we usually try to think in terms of, what’s a simpler metaphor that somebody can approach this with? What’s the simplest mental model that you can walk up to one of these games [with] and start playing it, and at least understand the basics? Now it might be the wrong model, but it still has to bootstrap into your learning process. So for most of our games, there’s some overt metaphor that allows you approach the simulation.
To put it another way, what I will call “the SimCity effect” begins much the same way as the Eliza effect. The system initially functions as a procedural representation because of the expectations — or, as Weizenbaum and Suchman might put it, the work — of the audience. We come with many expectations of therapists and cities. Similarly, with both types of systems, the modes of interaction made available through their surfaces encourage a process of play. In Eliza/Doctor this is a series of linguistic exchanges, while in SimCity this is the animated representation of the city and the iconic tools available for altering it. Through these interaction surfaces, play begins to reveal the shape of the underlying systems — which differs from the audience’s mental model.
It is at this point that the two effects diverge. The Eliza effect breaks down. The initial impression encouraged at the work’s surface is revealed as utterly removed from the internal system model. As this happens, the system’s processes and data cease to operate as a representation of the ideas first presented on the surface. Eliza/Doctor stops seeming like a simulated therapist and instead seems like a textual transformation device. The only alternative is to severely limit interaction with the system — as in Garfinkle’s yes/no therapy experiment — so that its underlying shape is not revealed.
The SimCity effect leads in a different direction. The underlying model in SimCity is designed as a representation of a dynamic city — inspired, in part, by Jay Forrester’s work on urban dynamics (further discussed below). While initial engagement with SimCity is based on the Eliza effect, the elements presented on the surface have analogues within the internal processes and data. Successful play requires understanding how initial expectation differs from system operation, incrementally building a model of the system’s internal processes based on experimentation. Most players don’t end up with a sufficiently-detailed understanding to allow them to reimplement the SimCity system, but to get far with the game they must develop a working understanding of the underlying model of city operations. Wright’s groundbreaking design has made it possible for many players to not only develop this understanding of SimCity’s software processes, but also enjoy the learning involved. This success has also opened his work to some critique.
Notes
1Though an expansion focused on crafting the underlying terrain on which the city rests.
March 11th, 2008 at 2:55 pm
Yes, this passage was stimulating. On the one hand, you’ve got the naive user who sits down to Eliza with a preconception of the idea of a therapist and a preconception of what it means to communicate through typing — but probably no idea of what a text parser does). On the other hand, you’ve got the naive user who sits down in front of SimCity with preconceptions about cities, and with a pretty good idea of what it means to use a GUI.
Any GUI interface restricts the meaningful gestures the user can perform, just as the iconic display restricts the possible meanings that the image can convey. So the initial “surface” of the GUI is already a mental model, in a way that I don’t think the “surface” of Eliza is (at least not until the user has first noticed something fishy about Eliza’s responses).
The resolution of the information that goes into Eliza is a lot deeper than the information that goes into SimCity. Even if Eliza can’t actually understand all of that information, the fact that it’s there on the screen (or on the fan-fold printout) means that it was available for the user to refer to when interpreting Eliza’s responses. But yes, limiting the input to yes/no (or some other finite set of verbs) would replicate the restrictions of SimCity’s GUI.
On the other hand, SimCity is a much more complex program. Once you’re consciously aware of Eliza’s rules, there’s not much left to do, unless of course the leading questions guide you to a life-changing self-revelation. In SimCity you have to learn how the various resources interact over time.
The naive users who first played Eliza weren’t consciously trying to grok the rules of the text parser, but may instead have been very self-conscious about what might have been their first significant encounter with a computer. If we put SimCity in historical perspective, we can assume that most players of SimCity were familiar with GUIs, and were thus wiling to accept restrictions (such as the requirement to zone rectangular areas and not being able to put a railroad, street, and power line in the same space). The GUI has trained us to lower our expectations. But those restrictions break the illusion of being a “real” city planner just as much as Eliza’s gaffes break the illusion of talking to a real therapist.
From the references to expectations and differences in the next paragraph, I gather that you’re going to write more about this sort of thing, so perhaps I’ll stop now and wait until the next installment.
March 11th, 2008 at 11:04 pm
Actually, while I am going further in this direction, I don’t think I make the important point you have here — that a GUI is already a much more restricted interaction channel than free-form textual input. I’ll definitely want to add that!