Please note that I don't update this web site anymore. You can visit my new personal blog at

Emergence Is A Fad

Friday, April 29, 2005

Chris Crawford has written an article about emergence in which he claims that emergence is the current fad in game design. Chris argues that when a system behaves in a way that wasn't anticipated by the designer, it's a bug, not a feature. Personally, I think that emergence can be of value to game design. I also think - and this might be similar to the point Chris is trying to make - that there are people who have an unrealistic idea of what emergence is and what it can do for you.

Emergence is not about making your game do unexpected things. If Windows, through some combination of the amount of text files on your hard drive, the temperature of your CPU, the number stored at address 0x00a03df8 of the virtual memory of the active process and the alignment of Jupiter's third largest moon with Sirius, produces a perfect doctoral dissertation for you, that's not emergence, that's dumb luck and, I must agree, a bug instead of a feature.

People who live by the rule 'new equals cool' probably shout 'emergence' every chance they get nowadays and everytime something random or unexpected occurs they'll go: "Cool, an emergent system!" If enough people start doing this then, yes, emergence will become a fad.

Emergence is a tool and tools need to be applied judiciously. Emergence is about simple rules creating complex systems, about local behaviour creating global patterns. This doesn't mean you should just knock some random rules together and hope that an interesting game will emerge. Instead, you should think about which patterns you want to create and then try to come up with rules that bring forth these patterns. The win you get with this approach over more conventional methods, is that you still decide what happens in your game, but you don't define how it happens, creating more freedom of expression for the player.

Abstraction is essential if you want to find emergence. Selecting the right patterns for your game requires you to be able to think abstractly. Creating rules that will produce the patterns you have selected, requires you to abstract the essence of the patterns into rules. Abstraction is not something that comes easy to human beings, so you'd better test your assumptions. I think it's a great idea to iterate throught the rules a multitude of times and then perform statistical analysis on the results and see if the rules really lead to the desired pattern. Thanks for the idea, Chris. And yes, if you want to interpret the results, you need to be able to turn those abstract numbers into actual gameplay in your mind. Abstraction is key.

Emergence is something new in game design, something to be explored. We don't yet know exactly how we can use it. We don't yet know where and when we should or shouldn't apply it. To me, finding that out is a compelling challenge.

Back to blog index


GBGames says:

While I can't claim to have done research on emergent gameplay, must you always try to create the patterns you desire? Isn't it sometimes more fun to try random rules, hypothesizing what may happen, but be willing to explore something you didn't think of? Quake's rocket jump was something that wasn't planned by the designers. It was just something the players discovered was possible with the rules governing the physics of the game. The Game of Life had patterns emerge from simple rules, and I don't believe the designer had those patterns in mind, so these unexpected things weren't necessarily bugs, were they? In Super Mario Bros 3, there was a level where you weren't supposed to get to without the frog suit, but you could do it if you swam towards the current from the right direction and speed. That's a bug. "The most exciting phrase to hear in science, the one that heralds the most discoveries, is not 'Eureka!' (I found it!) but 'That's funny'" - Isaac Asimov Isn't it possible that you'll miss out on good emergent gameplay if you insist that something you didn't intend is always a bug? But I agree that the other extreme of always assuming unexpected things to be emergence is wrong.

Friday, April 29, 2005 5:40 PM

Joost Ronkes Agerbeek says:

Quake's rocket jump may not have been forseen by the designers, but that doesn't make Quake and emergent system. As I see it, the only difference between Quake's rocket jump and your Super Mario 3 example, is that the makers of Quake had the good fortune that their 'oversight' wasn't detrimental to gameplay, where the makers of Super Mario 3 had no such luck. My point is not that unexpected things should be avoided at all cost; Asimov's quote is very apt. But you can't design a system to exhibit unexpected behaviour. It's a contradiction. Emergent systems can't be defined as systems that do unexpected things. Emergent systems exhibit patterns that emerge from rules. Note, I'm talking about emergent systems only, not about systems (games, in our case) in general. Of course, there is some fun to be had in just trying out a couple of rules and see where that takes you. It's questionable whether that's really design, though. Conway's Game of Life probably falls into this category, although I don't really know what John Conway had in mind when coming up with his rules. So, in essence, I agree with you; unexpected behaviour can be a good thing, like in the case of Quake's rocket jump. I just don't think it has anything to do with emergence.

Friday, April 29, 2005 9:17 PM

Wouter Lindenhof says:

First to make sure I have it correct: Emergence is the proces that makes (many) simple rules into one huge complex rule that can have result that were not expected(?) or/and(?) calculated(?) using the simple rules. About Quake Rocket Jump (QRJ): I don't think is a bug of part of a development of Emergence. Simply because it applied to the rules given. It didn't bring back unpredicted results. When the rocket is fired and the rocket hits a object the rocket explodes. When a rocket explodes all objects than are allowed to move by Physics will be forced away from the center off the explosion (with a certain algorithme). This is a logical outcome which could have been calculated and was not unexpected. The reason why anyone could call it emergence is because the output was thought of by the creaters. But it was possible by the simple rules. I don't think Emergence is really possible since everything can be calculated. But that's only when my definition is correct. (other wise if I have been filling useless webspace^^)

Monday, May 2, 2005 10:23 AM

Joost Ronkes Agerbeek says:

And I'm paying for that webspace, mind you! ;-) Emergence occurs when a small set of simple rules lead to complex behaviour. For example, smoke particles move according to the relatively simple and predictable Newtonian laws. There are a lot of smoke particles in a cloud of smoke, however, and because they all interact (i.e. collide) with each other, it is impossible for us to predict the behaviour of the cloud as a whole. This means that determinism (the fact that the behaviour can theoretically be calculated beforehand) doesn't preclude emergence. I'm bound to explore emergence further in future postings. Hopefully all becomes clear in time, not in the least place to me. :-) I wouldn't call the rocket jump emergent, because there is no simple rules, complex behaviour here. Nevertheless, if the designers didn't foresee this possibility, the rocket jump is unexpected from their point of view. Similarly, the bug in Super Mario 3 was simply a result from the rules the programmers put down in their computer code. The effects of these rules could have been calculated (and actually where by the computer that ran the game). Still, the behaviour was unexpected and, in this case, it was a bug.

Monday, May 2, 2005 8:51 PM

Tell me what you think

Since I'm not updating this site anymore, I disabled comments. You can visit me at my new site: