GameDevMike

Raph Koster posted his list of 40 ways to be a better game designer. Looking over the list, I found some things on it I already try to do (#1 on his list, about prototyping with placeholder art, I blogged about recently), and other things I had never considered, but most I have heard/read about in one form or another and from different sources. What he has put together is a solid, sensible list built from his years of experience.

A couple of the items stood out for me, #18 in particular:

Algorithms, not static data
The best games have an algorithmic style of variation, where gameplay emerges out of the possible permutations; this is as opposed to games which rely on a supply of static puzzles you supply. Shoot for the former — you may not make it (which is fine) but you’ll probably be forced to be cleverer.

Unless I’m misinterpreting the passage, this is something called “emergence”, or “emergent behavior”. If I were making a list like Raph’s, I wouldn’t have included it. I never have viewed emergent behavior as an element that should be strived for. I’ve always seen it as a side effect of certain types of games, particuarly those in which multiple AI entities interact, and not something under the developer’s control.

Andrew Rollings and Dave Morris, in their book, “Game Architecture and Design“, define emergence thusly:

…emergent factors are those that arise from the interaction between several rules. Emergence, we might say, is that which makes the whole greater than the sum of the parts.

Clearly Rollings and Morris apply the term only to the postive form. In my eyes, when emergence manifests itself in a negative form it is often called a
bug and, in some cases, may be turned into an exploit by crafty players. Many manifestations of emergence will be caught in testing, but somwhere down the road, after you’ve released the game, players will find more, both good and bad. You can count on it.

So when I first read this point on Raph’s list I was a bit perplexed. Emergence is not something that can be implemented. Emergence, by definition, is unpredictable. How is it possible to design unpredictablility into a game? It seems that’s exactly Raph’s point.

Raph says, “Shoot for the former — you may not make it (which is fine) but you’ll probably be forced to be cleverer.” I interpret this to mean that emergent behavior should always be considered in game designs. Encourage the game rules to interact in ways you didn’t intend them to by creating the right environment in which they can do so. This is a wholly abstract concept that can’t be chiseled in stone and will be different for each game. There’s no guarantee you can succeed, but you will almost certainly need to view the game in ways you wouldn’t otherwise in the attempt (hence, being “forced to be cleverer”).

It’s possible that I have misinterpreted his intent behind that particular point (a case of emergent behavior itself), but even so I can now see how emergent behavior can be a conscience part of game design and not something that should be left entirely to chance.

Technorati Tags: game design, game development, Raph Koster, emergence, emergent behavior