I finally had some time to play some of the “weirder” games out there-and I must say I found a favorite: Dwarf Fortress! It is hard to believe that an ASCII-based simulation can offer so much depth in gameplay. If I was to pick only one factor that distinguishes DF from other games (besides the obvious “geek appeal” its MS-DOS style interface creates) it would have to be the emergent, very complex interactions that the dwarves have with each other and their environment. In this article I will discuss the concepts of complexity and emergence citing DF and other games as examples…
Although the Dwarf Fortress developers, Tarn and Zach Adams, have chosen a minimalist mathematical model to simulate the physics of the environment “water, rocks, lava flow, etc.), and a multi-layered, but rather simple model of personal needs and interactions for the denizens of the world, DF allows you to create an astounding variety of cool traps and interesting building configurations and the interactions between the dwarves and their environment “seems” to be more complex than anything I have seen before!
How does DF manage to create so many “aha” moments, when many AAA titles fail miserably to do so, and how can we define a framework that will allow for the creation of an emergence-oriented game design methodology? First we need to define the concepts of complexity and emergence.
Following the tradition of all introductions, I will start by a rather boring, but necessary definition of the key terms we will be addressing. A system, can be defined as collections of “objects” or “rules” that work together and convert certain inputs to certain outputs. This definition can fit anything from an airplane to a computer game, and indeed, anything can be viewed as a system, as long as we break it down into inter-connected inputs, processing modules and outputs.
Contrary to popular belief, a complex system isn’t just a large set of interconnected components. Complexity, in a sense, does not address the size of a system definition, but rather its behavior over time. E.g. though a car consists of many components, the engineers have tried to make its behavior as simple and predictable as possible over a wide range of conditions. That’s because as a driver, you don’t want to discover that your car might do a backflip if you push in the cigarette lighter while driving at exactly 160 mph! On the other hand, we can come up with systems
that consist of simple rules, but show complex behavior over time. Cellular automata for example, have the potential for immense complexity, though their components are very simple mathematical models. [http://llk.media.mit.edu/projects/emergence/]
Now that we have discarded system size as a measure of complexity, we will need to find new measures of figuring out what makes a system “complex”. One broadly accepted property of complex systems is “emergent behavior” [http://en.wikipedia.org/wiki/Emergence]. Scientists describe emergent behavior as unexpected behavior that arises as a result of the interactions between multiple subsystems of a complex system. These behaviors, by definition, were not intended by the designers of the system, and in most cases are even more interesting to the observer, than the intended features of the system. E.g. many of the features of Conway’s Game of Life such as Glider Guns, could not have been foreseen by Conway when he first proposed his CA rules.
Even though definitions for emergence vary from system to system, and across fields of research, the above definition is good enough for our purposes.
2. Emergent Gameplay vs. Emergent Behavior of Game Systems
There are two other distinct, but related terms that I will use throughout this article, and I would like to offer a simple definition for each right away. First, the term “emergent gameplay”:
Gameplay is said to be emergent, when players start using the systems incorporated into the game “e.g. combat system, physics, damage calculation, etc.) in ways that they were not meant to be used.
Sounds a lot like “breaking” the game? Not necessarily! Sometimes, the emergent gameplay (e.g. rocket jumping in Quake) adds an important skill/puzzle factor to the game, that might make it even more interesting than the designers originally intended!
I would like you to read following quote from a Harvey Smith of ION Storm Austin that I found on the IGDA website:[http://www.igda.org/articles/hsmith_future.]
“Emergence: In Deus Ex, we found that players[-] were using an emergent strategy that had never occurred to us. One of the unit types “an MJ12 soldier character) exploded upon death. Our idea was that this would cause the player to react strategically, switching away from a pointblank weapon when fighting this unit. In a more traditional game systems model, we would have created an explosion entity with an explicit relationship to the player, damaging the player if he was within range of the explosion. However, in our more flexible system, we simply spawned a generic explosion with properties related to concussive/ballistic damage. Players figured out that they should lead this unit near a locked container before delivering the final blow. When the explosive unit blew up, it inflicted damage on the locked container, opening it up. We did not plan this or even foresee it – it just worked. In this way, players were exploiting the system in order to open locked doors and safes without spending any lock picking resources. We were delighted!”
This is a classic example of emergent gameplay, and very much existent in DF as following quote shows:
“Some people will purposely open a water reservoir that is more than one deep. The water shoots out fast because the entire second layer suddenly searches for an opening. You can get super fast flooding that way. Somebody had a goblin trap where they’d drop water on the gobs, and it happened to be outside in the arctic so it would immediately freeze and the gobs would die.”
Another example of emergent gameplay in DF is using lava moats to protect your dwarves from intruders and/or kill attackers. The screenshot below shows one such lava moot a player designed:
Besides emergent gameplay, there is another type of emergence integrated into many systems in DF though. We will call this “emergent behavior of game systems”, and it reflects the fact that the game systems can be designed so that interesting interactions between them occur, without needing to specifically incorporate those behaviors in the design (i.e. code them in).
In a sense, this second kind of emergence can only be distinguished from emergent gameplay, if we take the player out of the game system, and define him/her as an outside input to the game systems. If we do merge the two, and see the players as part of the human-game system “and there are good reasons for doing so) then the distinction between the two types of emergence blurs.
Here is an example of the emergence of interesting interactions between the different environment sub-systems in Dwarf fortress from a player, “Marlowe”:
“I managed to get through an aquifer for the first time, got some nice workshop and accommodation spaces chiseled out underneath, and then decided to do some exploratory mining DIRECTLY UNDER THE AQUIFER. I didn’t realise that an aquifer will flood if you undermine it. I got a damp stone warning, but ignored but because I assumed it was just another one of those harmless situations like digging under a pool. Wrong! It was impressive to see the water flood down my up/down staircases in a torrent of mist, but also heartbreaking. I abandoned like a big chicken. It retrospect, I probably could have walled off the breach if I’d been determined enough.”
This is an emergent situation, and is cool in itself, because it resonates with the player’s perception of the real world, where the sheer complexity of events, causes this kind of interesting emergent behavior. The fact that DF has a simple semi-realistic fluid dynamics mechanism “you can read about it in the Gamasutra interview) allows for some amazing unplanned situations to arise “flooding, moots, water traps, frozen enemies, etc.) even if the player does not intend them, as it is clearly the case in the quoted example.
3. Do we Need Emergence in Games?
Having defined the two main types of emergence in a game, it is clear that the first type, namely, emergent gameplay cannot be designed for. As a developer and designer, it is entirely out of your control how the players will your game subsystems.
We can, and in my opinion, should, strive to increase the potential for the second type of emergence in our games. My own experience as a player and developer have brought me to the conclusion, that emergent behavior, though shunned by many designers because of its inherent unpredictability, makes a game a lot more fun to play and adds a lot of “aha!” moments. Players have seen more than enough of their share of scripted events, and both emergent gameplay and emergent behavior, if they don’t break or unbalance the game utterly, can be great incentives to keep playing a game over and over, and as such they provide a large added value to players.
Having said this, is there any way to design for maximal emergent behavior? How can we be sure that interesting moments will ever arise if we cannot implicitly script them? How “complex” should our game systems be in order to allow for emergent behavior? How can we make sure that the emergent behavior we tried so hard to “engineer” is not ill-perceived by the players, and finally, having designed our game sub-systems, how can we gain a measure of the potential for emergent behavior in our game? I would love to hear cases of emergent game play and game systems where the emergence “makes” or “breaks” a game to be discussed in future installments of this article.
This series of articles is all about finding answers to these questions. In the course of these articles, I will reference mathematical models and definitions due to the large amount of research already available on the complexity of purely mathematical models and I will provide links where you can read up on some of the concepts. Complexity and emergence inherently defy quantification, so I will try to avoid mathematics as much as possible and rather define a qualitative framework for emergence-friendly design of game systems. The second article in this series, will discuss how to design game systems, in order to maximize their potential for emergent behavior. Read “Designing Games for Emergence“.