[MUD-Dev] Evolutionary Design

J C Lawrence claw at kanga.nu
Tue Jun 11 22:47:43 CEST 2002


From: 

  http://www.gamedev.net/reference/design/features/evolution/

--<cut>--
			      Evolutionary Design
	      A practical process for creating great game designs
				 by Daniel Cook
			   http://www.lostgarden.com/


Table of Contents

  Introduction
  Board Games and Novel Writing
  Giants and Castles
  The Evolutionary Process
  The Death of the Ego
  Focus on a fundamental activity
  Play the Game
  Observe the Game
  Identify Problems with the Game
  Common Economic Issues
  Common Psychological Issues
  Create new rules
  The Life Cycle of an Evolutionary Design
  Expanding the Evolution Metaphor
  Using Evolutionary Design for computer games
  A Proven Technique
  The Benefit of a Process
  References

Introduction

Game design, in its most pure sense, is the creation of the rules that
govern the gaming environment.  At the base of every finished game is a
game design.  Strip away the techno-geek graphics and the ambient
sounds.  Strip away the marketing hype.  You are left with a set of
rules driving minimalist iconic representations.  A strange miracle
occurs. People enjoy playing the game. Yes, people enjoy playing Tetris,
Net Hack, and pixilated games from the early 80s.  Developers even enjoy
playing the primitive prototypes used to test their ideas.  Why? 
Because the rules that govern the gaming world create an entertaining
experience regardless of the eye candy piled on top.

The successful creation of these rules is not magic. We've seen process
charts for art asset creation.   There are dozens of development
strategies for producing quality code.  This essay attempts to derive a
game design process, a coherent set of interelated practices that help
ensure quality design.

First I made the relatively safe assumption that people exhibit
predictable responses to reproducible situations.  Next, I noted how
game designers create a given psychological situation in the player's
environment that cause players to respond in a variety of desirable
ways.  I recorded proven practices that help create these enjoyable
gaming environment . Finally, we organize the practices into a highly
disciplined iterative process that dramatically improves the 'fun' of a
game project.  For lack of a better term I call this process
Evolutionary Design.

Board Games and Novel Writing

The practices of game design are derived from intimate experience with a
wide variety of game projects. The core principles that drive a simple
arcade game like Pac man should also be evident in a sophisticated tour
de force like Deus Ex.  With this thought in mind, I analyzed the design
process of a lowly board game.

"A board game", you cry.  "Such a thing has no cut scenes or fuzzy logic
NPCs!"  I concede there are differences.  Writing a novel requires a
variety of additional techniques not found in a short story. Still, the
rules that build a good short story are found in abundance in a novel. 
If a designer can successfully create the minute-to-minute user
experience in Donkey Kong, then he or she has a powerful foundation for
creating a much longer involved game such as Mario 64.  A board game is
lot less complex than Donkey Kong, and as such it is a perfect vehicle
for discussing game design fundamentals.

The questions I ask in computer game design end up being the same
questions I need to ask in board game design. What makes the player want
to play another few minutes? What is an efficient process of rule
creation?  What are the pitfalls of balancing a game and what are
techniques that help avoid these pitfalls?  If my board game produces
answers that parallel useful solutions for video games, then perhaps we
have stumbled upon a set of universally helpful design tools.

One should never be afraid to discuss 2,000 years of massively
successful non-electronic gaming in the same breath as Doom XXV.  


Giants and Castles

To derive the design process, I built a board game called Giants and
Castles. The basic concept is that you are a giant who wants to build a
beautiful golden palace.  Unfortunately, you are a giant and building is
not exactly your strong point.  Using your impeccable giant intuition
you decide to clomp over to a nearby valley full of pre-built human
castles. With a nod of your hat to the local lords, you rip out their
treasure rooms and lug them back to your home.  With a little balancing,
you toss together a spectacular palace in no time.

As luck would have it there are several other giants wandering about the
board searching for treasure rooms.  Mass destruction, panicked
exploration, and grand larceny ensues.  Thank goodness. 

I used the following requirements.

   o Rules consisting of a single page
   o 5 minute learning curve
   o Average play session of one hour
   o Must entertain a wide range of people
   o Must have a concept that is instantly appealing.

Other than the limited rule set, these requirements could easily be the
foundation for most modern mass-market video games.


The Evolutionary Process

Design is the creation and modification of the rules governing a gaming
system.  The quality of the overall system of rules is the result of
balancing the rules against one another. The process of balancing a game
is merely the creation and modification of rules while continually
evaluating the effectiveness of the resulting system.   This view of
design suggests that good design can be created through an inherently
iterative process.

   1.  Create rules (Initially this will be the fundamental activity)
   2.  Play through the rules.
   3.  Observe how players react to rules
   4.  Identify problem areas with rules
   5.  Return to step one in order to create new rules that address the
   problems

This process will slowly evolve a game towards a more enjoyable state. 
You can think of the rules as the DNA of the complex emergent system we
call the game.  The fitness of the game in each generation is determined
through play and analysis. At the beginning of the new cycle, rational
mutations on the old rules are created and tested once again.


The Death of the Ego

Note that there is very little sense of an overarching 'vision'.  At no
point does the designer say 'the project requirements lists 35
pre-described weapons so we must have them." Instead, the act of playing
the game suggests additional rules and gaming systems that would be an
improvement.

Isn't the purpose of the designer to have a grand vision that describes
every element of the finished game?  Unfortunately, though there are
optimistic designers who believe in this technique, in practice it tends
to fail. 

The basic problem with 'grand vision' game design is that it is
incredibly difficult predict how a complex system will behave when you
make changes to it's rule set.   In Giants and Castles, I removed a
major system of rules. I had great reasons and 'in theory' everything
should have worked out perfectly. Three fourths of the way through every
subsequent game, the spell card system was completely broken.  No one
had enough resources to cast spells, and people were holding onto dozens
of cards.  Due to a rather intricate emergent behavior of the system, my
carefully designed rule change broke the game. 

Emergent behavior consists of patterns present within a system that
result from the atomic interactions of the elements that make up the
system.  In the classic cellular automaton simulation Life, one can
observe patterns of growth, expansion, and death similar to an
ecosystem.  However, the rules governing the simulation make no mention
of these patterns. They deal solely with the interactions of one cell
with its neighbors.  The higher-level patterns are the result of dozens
of interactions between many cells.  All games rely on emergent behavior
to define their play.  The designer creates simple rules, and the
complex interactions of those rules determine the game play patterns.

If I were an omnipotent designer, I would have predicted the exact
result of my changes.  However, most of the time, I am not omnipotent
and my understanding of emergent behavior is limited.   By making
incremental changes and then immediately testing those changes, you
minimize the unexpected disruptions to the system. This increases your
ability to make rational improvements.


Step 1: Focus on a fundamental activity

Giants and Castles is a game about stacking items.  Some of the actions
in the game include:

   o Pick up a room: Remove token from a castle stack and add to your
   giant stack

   o Drop an item: Remove a token from your giant stack and place it on
   an adjacent stack

   o Jump on top of another giant: stacking one giant stack on top of
   another giant stack.

There is spell casting, inventory management, exploration, and a half
dozen other meta-game activities that occur.  Everything revolves around
stacking.

Think of other games that have simple easy to understand rules that
describe what you do 90% of the time you play.  Super Mario Brothers is
primarily a game about jumping.  Quake is about moving and shooting. 
Populous is about flattening land.  The Diablo II post mortem has this
comment; "First, we make the game playable as soon as possible in the
development process. Our initial priority was to get a guy moving around
on the screen and hacking monsters. This is what players would be doing
most of the time, and it had to be fun."

There are some impressive benefits to this design strategy

   o Ease of learning: Most fundamental activities are so simple they
   can be taught in under a minute.  This means the player is able to
   jump into the game immediately.

   o Focuses game balancing: If the designer can make the core activity
   enjoyable, then 90% of the game is enjoyable.

   o Provides a solid foundation for additional rules: Every spell in
   Giants and Castles is based of variations on stacking.  By subtle
   expansions of a fundamental activity a rich and complex set of rules
   can emerge.  Look at your activity and map out the various
   permutations of player actions.  In Super Mario Brothers, the player
   could jump on top of something.  The designer extended the rule set
   so that this natural permutation of the core activity became "Attack
   enemy".
     

Step 2: Play the Game

After every set of rule changes, play the game.  The most common error I
hear designers make is that they do heavy design at the beginning of the
project and fail to test until the last month or two.  The result is a
confused tangle of rules that confuse the player.   Those designers who
attempt to correctly balance the game end up spending massive amounts of
development resources fixing the system's underlying flaws.  Perhaps if
they had started testing when the game was young, the problems would be
much easier to fix.

After each iteration on the game's rules, I would get together a group
of people and play Giants and Castles.  Before I began playing, I was
convinced that my shiny new set of rules would work perfectly.  The sin
of Grand Vision struck.  The first time I played and the next 20
iterations after that proved me wrong.

There are a couple styles to playing the game and both have their
benefits.

   o Let other people play the game and then observe them.
   o Play the game yourself

Letting other people play the game results in an objective overview of
how people are reacting. However the outside observer tends to miss many
of the social details.  Games involve a player acting and reacting
emotionally to the environment created by the game rules. Many of the
trends and undercurrents are completely invisible unless you are in the
game interacting with the rules and feeling your psychological responses
to the situations that emerge.


Step 3: Observe the Game

Observing is the act of collecting data about player reactions to game
play.

I used a crude yet remarkably effective method of observing the game. 
While playing the game, I watched my fellow players.  Whenever there was
frustration or boredom, I asked why.  I also asked people to make
suggestions if they noticed something that felt odd or could be
improved.

Every single time someone mentioned something no matter how trivial, I
wrote it down.  I never argued and told them 'the way it was supposed to
work.'  Such 'expert' behavior merely confused the issue and damaged
their trust in me as an impartial observer.   The more I wrote things
down and publicly showed I was listening, the more intelligent responses
I received.

I also would ask clarifying questions.  "Could you give me an example?" 
"What do you mean by that comment?"   Often a vague feeling of
discomfort would rapidly crystallize into a specific issue with one of
the game rules.

I wrote down my own thoughts and feelings as well.  Given the temporal
nature of any psychological response, it was important to capture
observations immediately.   When I waited to record my observation
later, they were not as useful in determining issues because I had
already let my expectations bias the data.

Admittedly, Giants and Castles is a 60-minute long multiplayer game
where personal testing is logistically trivial.  However, I have great
faith that a variation on this technique is possible with in-house
testing of game sections.  The use of web forums, open and closed betas
can glean valuable knowledge from outside testers.


Step 4: Identify Problems with the Game

Identifying problems is the act of asking the right questions about that
data.

What makes a game fun?  The au naturel designers of the world shrug and
respond,  "Fun makes a game fun!  Fun, fun, fun!"  And I want to slap
someone.  Though I have a great respect for intuition, I believe you can
attain amazing results when you mix intuition with a healthy dose of
analytical thought.

When balancing Giants and Castles, I chose two heavily documented fields
to explain why people act the way they do when playing a game. The first
is economics.  Every game has resources, and there are standard economic
rules associated with the behavior and management of those resources. 
The second is psychology.  Psychology tells us that players demonstrate
standard emotional and social responses to particular environmental
cues.

Questions derived from these two disciplines informed my actions in the
"Create New rules" phases of the design process.


Common Economic Issues

Economics is a marvelous though incomplete metaphor for understanding
the behaviors of complex systems.  The premise is simple.  Every
individual has needs and wants.  Through the exchange of resources,
individuals seek to maximize their happiness (or utility).  Though
economics has difficulties explaining exactly how a person will act in a
given situation, it is remarkably accurate at explaining how to
influence groups of people though systems governing the transfer of
resources.

In Giants and Castle, I had four major resources:

   1.  Rooms
   2.  Treasure Rooms
   3.  Spells
   4.  Action Points

Action points were the equivalent of time.  Each player had the same
amount and you either used it or lost it before the next player's turn. 
Rooms were the currency of the game and were used to purchase spells, a
resource.  Treasure rooms were also a special resource, though in times
of trouble you could use them as currency just like a normal Room. 

Given this economic definition of the items in the game, I could ask the
following questions as I observed game play.

Surplus or scarcity?

Are there too many spells in the player's hand?  Are there enough rooms
present for all players to cast spells?  At one point I had too many
treasure rooms, so their value decreased in the eyes of the players. 
Instead of fighting over each one as if it were the last, players simply
assumed there would be another.  Adjusting the supply of resources is
perhaps the most common balancing technique.

Are players willing to spend resources?

I noticed players were unwilling to spend action points picking up a
room that would only end up being spent on a spell.  The opportunity
cost of casting spells was high compared to benefits gained from using
action points to explore. I added several spells that allowed players to
pick up stacks of rooms. Now players cast spells regularly.

What are resources change hands for other resources?

Why would the player use a spell card? Why would a player pick up a
room? I noticed a small economy within the game.  The most effective way
of gathering treasure rooms was moving tokens quickly. People valued
spells because spells allowed for rapid movement of tokens.  However, in
order to cast spells, players need rooms.  The result was a web of
dependencies that I took into account when creating rules.

Who owns resources?

Each resource had ownership rules.  Carrying a room, placing a treasure
room on castle, and holding a spell in your hand were all types of
ownership. Many of the interesting game dynamics came from the fact
other players could steal rooms from one another.

Common Psychological Issues

Where economics provides insight into the practical elements of game
design, psychology gives us tools for manipulating the player's
emotions. The following questions help hone the enjoyment level of the
game.

What are your rewards?

Rewards are positive reinforcement that makes the player feel
pleasure. In general, there are two basic reward types, attention based
rewards, and ability based rewards.

   o Attention: A token, or social response that recognizes past
   accomplishments. This is the equivalent of someone giving the player
   a pat on the shoulder and saying 'good job'.

   o New Abilities: An opportunity to perform a valuable action

These can be mixed.  For example, in Age of Wonders, units gained medals
for their experience in combat.  The reward both recognized the player's
investment in the unit and gave the unit skill bonuses that let the
player use the unit in new ways.

The amount of psychological pleasure, or value, of rewards is dependent
on a wide variety of factors, but there are several key ones.

   o Economics: Most rewards are valuable because they let the player
   manipulate resources that have a certain value within the game
   economy. This is why economic balancing is so important.  If the game
   economy is broken, then expected rewards are devalued, positive
   reinforcement decreases and players find the game 'boring.'

   o Player investment: The more effort a player puts into an action,
   the more valuable the resulting reward.  In Giant's and Castles,
   every treasure room was economically worth the same amount.  However,
   occasionally players would spend an extraordinary amount of time
   pursuing a single treasure room.  When they finally secured it, they
   were positively beaming with pleasure.  Because of their time
   investment, the hard-to-get treasure room was far more valuable than
   the easily found treasure rooms.
     
   o Social response: How people respond to the player constitutes a
   reward.  In Giants and Castles, I had a player who would constantly
   jump his token on top of another player token so that he would be
   carried around. There was very little player investment or economic
   value to the action, yet he loved doing it.  Why?  Because the other
   players laughed.  He was being rewarded with a form of
   attention. Admittedly, social response is a stronger reward in board
   games than in single player computer games.  In multiplayer games,
   however, the value of social responses can dominate all other forms
   of reward. Games like Ultima Online spend much of their design
   efforts adjusting social response reward structures.

What are the reward schedules?

If I were asked to pick one element that makes a game addictive, I would
choose reward schedules.  A reward schedule is how often the player is
awarded.  Getting a new unit every mission in a game like Starcraft
constitutes a reward schedule. Gamasutra has a great article called
Behavioral Game Design on reward schedules that should be mandatory
reading for all game designers. While rewards cause players to feel
enjoyment, reward schedules keep the player motivated and excited about
continuing to play the game in order to reach the next reward.

I find that staggered reward schedules tied to the player's investment
work best.  Imagine a set of rewards given approximately every thirty
seconds, every minute, every 5 minutes, every ten minutes, and every 20
minutes.   The result is that the player is constantly bombarded by
positive reinforcement.  However, the 20-minute reward is inherently
more valuable than the 30 second award because the player must invest
playing time in order to achieve it.  Many players will become numb to
the pleasures associated with 30-second rewards, but will still play for
several minutes longer to reach the 'larger' reward. Sid Meier used this
technique to great effect in Civilization.  How many players were bored
with killing a single unit, but kept playing to finish construction of
the Wonder they started 20 minutes ago?

In Giants and Castles, I used several overlapping reward schedules. 
Approximately every 5 minutes, someone discovered a new treasure room. 
Every turn they got a shiny new spell to cast.   Every 10 minutes they
got a powerful card that allowed them to change the balance of power.  
There's the overarching goal of winning that is timed to occur
approximately 30 minutes from the start of the game. 

There is certainly room for improvement.  I'm missing 1 minute and 30
second rewards so initial game play feels a bit slow.  Only in the last
half of the game when all reward schedules are fully active do players
really light up and begin playing the game passionately.

Are interesting decisions being made?

This is an old standby of game designers everywhere, but it is also
important to emphasize.  Imagine a player can choose between two option
A and B.  There are several possible outcomes

   1.  A results in a beneficial effect in the emergent game system that
   is always obviously superior to the result caused by B.

   2.  A or B cause the same result in the emergent system.

   3.  Choosing A changes the complex emergent system in a different way
   than B. The results of either A or B are useful to the player given a
   particular in game situation.

Decision-making costs player time. By presenting the first two options
to the player, you force them to waste energy making a trivial
decision. There is only so much player time you can expect your game to
receive.  If you aren't spending that valuable resource on improving the
value of your reward schedules, then the reward schedules suffer and
once again, the game is boring.

I had an ingenious idea with Giants and Castles.  Instead of dice, I
would use movement cards.  Players draw movement cards that tell them
how often they can move in a turn.  Each turn, they manage their
remaining cards and play one that fits the situation best. Every single
time, players ended up playing the movement card with the highest
allowable movement points.  It was the obvious right choice.

I tinkered with the movement system for a while until I realized that
movement was a dumb thing to force the player to think about.  So I
removed movement cards and gave everyone a fixed number of moves. 
Voila, the game play improved as players focused on more important
activities.

What are the social connotations of player actions?

Players are fundamentally social and emotional decision makers.  Notice
how, in the discussion on rewards, economics only matters in that it
helps determine the value of ultimately psychological benefits.  Though
simple reward based models of human behavior are exceedingly useful in
game design, people are also heavily influenced by their social
perception of a situation.   

In Giants and Castles, removing a room from the top of another Giant's
stack was seen as stealing.  Some players felt this was an immoral
activity.  Others delighted in the fact they could do a socially
unacceptable act without punishment.  This social conflict caused
meta-game discussion that truly enlivened most gaming sessions.

Does the game use setting correctly?

There are stages to a player's interaction with a gaming system

   1.  Players mechanically perform game rules with no knowledge of how
   their actions alter the game.
     
   2.  Player attempt to fit the results they witness into existing
   schema (mental patterns for dealing with known situations).  They
   then react in a pre-programmed manner as dictated by their schema.

   3.  Player create new schema and optimized responses to unique game
   situations.

The game's setting heavily influences the first two stages.  Setting
consists of the contextual clues that tell the player what sort of world
they should expect to operate within.  By setting up the right
contextual cues, the designer can quickly activate pre-existing schema
in a player so that they 'instinctively' know how to play the game.

In Giants and Castles, there were many examples of setting.

   o The background story tells players they are giants and defines the
   other tokens as castles.  This instantly sets up expectation of the
   crude behavior and rough and tumble game play.

   o The board game artwork of a green field with castles sets the
   expectation that they are in a concrete world with predictable
   physical rules.  Players instantly realize they can walk about the
   game board, interact with castles and each other.

   o The size of the pieces set up expectations of the scale of those
   actions.  The player might easily expect giant might easily pick up
   the top of a castle.

Board games have extremely minimalist settings compared to computer
games.  Most of the time and effort that goes into computer game goes
into making beautiful art resources, improving AI, and creating a plot
that influences player perceptions.  This is all setting.

Toss setting out the door completely and you have a game that is just as
enjoyable to play, but takes more effort to appreciate.  Instead of
easing the player into the game system using their predictable
expectations, players must build an extensive foundation of experience
in order to derive the workings of the game system.

Many abstract war games exhibit this issue.  Long time players swear
they are the most enjoyable games they've ever played.  Yet a casual
gamer doesn't have the time to invest a thousand hours building the
schema necessary to enjoy the game's subtleties.  In today's high paced
mass-market environment, requiring a high initial level of player
dedication is suicidal.   The result is an understandable emphasis on
setting.

The most common mistake of modern games is that they mistake setting for
game design.  A great plot does not make a great game.  Nor does a great
player model or animation engine.  These merely provide contextual
support for the game's reward system.  If the rest of the game design is
broken, a multi-million dollar investment in setting will still fail
produce an enjoyable game.

In Giants and Castles, I was fascinated by the game's plot.  I wrote a
huge background tale full of romance, dramatic characters, and ancient
prophecies.  I envisioned my name in lights, "Author and Story Teller
Extraordinaire." 

Players became confused.  All the setting information led them to expect
a world that dealt with romance, characters and ancient prophecies. 
With the wrong or extraneous schema activated, they tried to do things
that the game rules didn't support and became frustrated with learning
the game.  In the end, I simplified the plot so that it existed merely
to support game play. The game improved.

Some intellectuals struggle with the dichotomy between narrative and
interactivity. Game designers are first and foremost creators of
enjoyable game environments.   They are storytellers only when this
secondary activity facilitates the player's intuitive interaction with
the game's rules.

Is the end game exciting?

In a competitive situation, the gaining of resources will increase a
player's ability to win.  In chess, for example, minor advantages turn
at the beginning of the game turn into major advantages at the end of
the game.  A player who is ahead by a pawn or two can often declare the
game won far before checkmate occurs.  Unfortunately, this means the end
of the game is often boring.  I call this form of game play 'divergent'
because players end up at radically different competitive levels as time
progresses.

In Giants and Castles, I explicitly aimed for a competitive end game, so
I created spells that helped ensure 'convergent' game play.  The further
ahead a player gets, the more rules and social forces pull the other
trailing players up or push the leader down.  The result is an exciting
end game with everyone in the running for victory. 

I provided spells that players could use to knock down the leader.  The
key element: Players choose to balance the game.  Mario Kart uses a
similar technique with the shells that slow down the leader. Because
this is a player-controlled balancing mechanism, it does not feel
arbitrary.


Step 5: Create new rules

The final step is to create rules that fix the problem areas.  This is
where a game designer brings their own artistic flair to the craft of
design.  You must know the system intimately so that you can understand
the general effect of small rule changes.  There are no magic bullets
since the solutions needed are typically unique to the specific gaming
system.  There are design patterns that are useful, but that is a
subject far beyond the scope of this article. 

The best I can give you are some rules of thumb that usually apply:

Take risks

If you are playing and testing on short iterations, there is only so
much damage you can do before you figure out that you screwed up.  If
you see a need and you have a creative solution, try it out. 

Be willing to remove existing rules

To paraphrase a writing rule, balancing is the act of cutting away
everything that is non-essential.  If a rule is not helping, kill it,
regardless of how much effort you've put into making it work.

Focus on incremental changes to existing rules

Often a game sub-system needs to be tweaked, not rebuilt from scratch.

Be wary of changes that add unnecessary complexity

A simple fix is often just as good as a massively complex system. Pac
man uses a power up system consisting of a single dot.  The designer
could have implemented an RPG style experience system instead, but would
it have done the job at hand any better? 

Changes should reflect identified issues

If you toss a system into the game with no expectations of what role it
will play in the various reward systems, you will pay the price.  You
end up with a set of unrelated game rules that need to go through
extensive balancing before they actually work.


The Life Cycle of an Evolutionary Design

Once you've created your initial rules, played the game, observed,
identified issues and created some more rules, you are ready to repeat
the process all over again. After enough repetitions a solid enjoyable
game will emerge. 

I've noticed several stages in the evolution. 

Stage 1:  Prototyping

At first there are very few rules, so each change has a huge effect on
the game.  Giants and Castles originally was a game about digging up
treasure in the Amazon.  After play testing a couple rounds, minor rule
changes caused an entirely new set of game mechanics to emerge.  I got a
few comments from players, but mostly this stage is driven by careful
designer analysis.

Stage 2: Balancing

Next, the game settles into a 'conceptually interesting but practically
boring' stage. The rules seem to be in place, but the game is just not
all that enjoyable to play. This is where the meat of balancing occurs. 
Players have copious opinions because they can sense the general idea of
the game, but they are typically frustrated by the details.  I took time
to listen to my players.  They saw things that I would never have
commented on because I was too caught up preserving and nurturing the
intricate web I had created.  Slowly, the game became more enjoyable.

Stage 3: Equilibrium

Finally, the comments become sporadic, and players spend less time
complaining and more time having the time of their lives.  Your game has
reached equilibrium.  The web of rules support and reinforce one
another, so that adding or tweaking a rule has little effect on the
system as a whole.  In Giants and Castles I added another card to the
spell deck during the final iterations.  In previous iterations, such an
action had radically changed the flow of the game.  This time, the game
play was nearly indistinguishable. An economic term for equilibrium is
'the point of diminishing returns on design.'  Congratulations, you have
a mature game.


Expanding the Evolution Metaphor

Imagine a hill.  The high points on the hill are areas of great player
enjoyment.  The low points make players miserable.  The evolutionary
process is often called a hill-climbing algorithm.  Your initial game
idea is a point on the side of the hill.  Each iteration of the design
process, you stop and "Ask which direction should I move to increase
player enjoyment?"  Slowly, but surely your game will climb the
hill. The equilibrium point of evolutionary design corresponds to the
peak of the player enjoyment.

Evolutionary dead ends

What happens if there are multiple hills?  Unfortunately, a given game
design can only climb one hill.  If the closer hill was also the shorter
hill, then someone who is climbing the other hill will end up with a
more enjoyable game.  The result is called a 'local maxima', and it
points out a cruel hard fact of game design.  Some starting ideas will
lead to a game with a low enjoyment level, no matter what the skill of
the designer or the development team. 

Why there are clones

Now imagine an entire landscape of potential game designs with huge
mountainous peaks that corresponds to massively enjoyable games, and
thousands of smaller peaks that correspond to less enjoyable designs.

A few talented, visionary game designers hit upon a seed that climbs
those mountainous peaks. They stand at the top with their incredibly
enjoyable games and the world sees a success story. These are games like
Wolfenstein 3D, Dune 2 and Ultima Online.

And here's the rub.  Original ideas take a lot of effort and money to
balance and there's a good chance they only end up climbing one of the
smaller hills. Designers are interested in making the most enjoyable
game given their limited resources.  Many designers want to survive to
make another game.  If they can start at a point near a known success,
there's a good chance they can build a game that climbs an equally tall
mountain.

The result is a huge number of companies clustered around a similar
design foundation. And here be clones.  Not because designers are
stupid, or because marketing people are greedy.  Clones happen because
smart people make optimal decisions that result in the most enjoyable
game they can imagine given their resources and need to avoid risk.

Building an original game

It takes a diligent and lucky team to discover a new mountain to climb. 
Thankfully for designers who enjoy original games, the process is
extraordinarily simple.  First pick an enjoyable fundamental
activity. You could wake up tomorrow with a new way of moving a
character on the screen, and think "I could imagine a simple game using
that concept."  Now begin iterating on the design.  Play the game. 
Observe how people react.  Come up with new rules that make your idea
more enjoyable. Over time an enjoyable, original game will emerge.  If
you don't succeed, try again.

Giants and Castles is my fourth board game design.  It is reasonably
original since I know of no other game that uses its core mechanic of
stacking.  In the landscape of game designs, it climbed a medium sized
hill and I'm not sure if it is possible to take it higher.  The other
three designs were flops that made it through one or two iterations
before I realized I was 'polishing a turd'.  Still, I only lost a week
worth of effort exploring three new ideas.  Such a process is remarkably
more cost effective compared to spending millions on a shiny new game
only to find the underlying premise is flawed.


Using Evolutionary Design for computer games

A board game is a simple example of evolutionary design in action. 
Computer games offer a whole new set of difficulties involving
technology and content development.  Imagine attempting to test your
game design when it takes 6 month for the graphics engine to show
something on the screen and 4 more months before there is enough art to
describe the environment.

How do you integrate evolutionary design with software development and
content creation constraints?  I don't have a short answer, but I've
experienced some powerful, proven techniques that may one day lead to a
unified iterative game development process.

Adapt an agile software development process like Extreme Programming

There a relatively new type of software development process called
Extreme Programming.  The goals are similar to evolutionary design.  
Development occurs in short iterations and all code is constantly
tested.  The goal is to manage change.  I've worked within this system
for about a year in a non-game project that required the co-development
of a 3D engine, an editing environment, and content.  So far I'm
impressed.  Modifying the process to include game play testing in
addition to code testing could place evolutionary design in the context
of a proven software development method.

Use standard formats for art and then adapt the technology to the
results

There are proven methods for efficiently creating artwork involving
concept artwork, modeling, animation, etc.  Such activities require
extensive planning.  Evolutionary design poses an interesting dilemma
because it intentionally avoids abstract upfront planning so that it can
adapt easily to the reality of the situation.

I have a heretical theory, and mind you this comes from someone who has
been painting and illustrating for much of my life.   Suppose you were
to test art like you test game design and code.  You would get back
comments like "It needs to be pretty.  It needs to have a coherent
style."  You would hardly ever get back "The art caused the game to fail
because the character had goatee instead of a full beard."

Why?  Because the only function most art has in a game is to help create
the setting.  Art needs to be attractive, evocative and vaguely related
to the game concept.  Everything else is up to the vision and talent of
the artist and the technical requirements of the engine.

During the first few iterations, the game will rapidly solidify.  At
this point the designer should be able to describe the basic setting
requirements.  The team can decide upon:

   o Technical requirements for getting artwork into testing as soon as
   possible

   o Rough background story that gives artists conceptual details to
   draw from.

   o A general artistic theme that will fit the game

   o The first batch of content artists should start working on.   For
   example: "A cool player character that fits the theme and background
   story."  Or "Some monsters."

If possible, create high quality artwork and then constantly evaluate
how that information is getting into the game engine.

I'm glossing over two particularly tricky content related elements.  The
first is the user interface.  This requires numerous iterations of both
design and content.  The second is map building.  Maps are heavily
content dependent, but they are part of the game design.  There are ways
one can separate map functionality (game design of map skeleton) from
art creation (making map building blocks) and application (prettifying
the map skeleton by applying art resources).  However this requires an
intricate robust process that is heavily dependent on the tools and
people available.


A Proven Technique

Evolutionary design is not an original concept. Similar ideas have been
called iterative design or prototyping for many years. Dozens of
companies practice grass roots processes that are evolutionary design in
spirit if not in name. 

For my first game design, I worked with a small company called Epic
Megagames on a project named The Circle.  As a enthusiastic designer
fresh out of college, I led a small team that fluctuated between 3 and 5
people for the chaotic two-year length of the project. I was a fervent
believer in intelligent game design, and proceeded to write a concise
hundred-page design document describing everything.  To call the design
ambitious would be an understatement.  In no particular order, the
document included: 

   o Large tracts of plot
   o Dozens of intricate game systems
   o Detailed character art.

There was another project at Epic named Unreal.  The Circle used the
same Unreal engine and authoring tools, but the Unreal team went about
the development process in a very different manner.

   o They made stuff, including seemingly random maps, characters, and
   weapons

   o They messed about with their creations

   o They tossed things that didn't work

   o They kept on doing this for the length of the project

   o For a long time, Unreal had no design document.  Eventually they
   settled for a rough description of levels and weapons.  I'm not sure
   how much they actually used them.

The Unreal engine was in a constant state of revision.  Content created
one month would fail to load inexplicably the next. The documented
limits were not the actual limits, and the only way to find out was to
break the editor through accidental stress tests. Projected features
never materialized, and the completion of the engine was always
estimated at a year away. 

Two very different projects had two very different endings. The Unreal
team managed to figure out the limitations of the engine and create the
most enjoyable game possible given the constraints.  One could say they
evolved their game to fit what they were given.  The Circle team would
try to build the ultimate inventory system, or the ultimate movement UI,
completely ignoring the state of the engine.  Months were wasted on
textures for areas that were impossible to build. For two years, the
Circle team carefully built the items in the design document only to
realize they were unworkable.

In the end, The Circle was canceled, and Unreal went on to fame and
fortune.  While there were other issues involved, the design methodology
contributed greatly to the final result.

I hear tales from around the industry.  Blizzard mentions that one of
their most important design activities is playing the game. Sid Meier
discusses his test bed philosophy of trying out game designs. Peter
Molyneux expounds upon the prototypes that help him polish original
ideas. Each appears to build 'fun' into their game designs throughout
the entire development process. Is it really surprising that players
worship the games these developers produce?


The Benefit of a Process

In conclusion, I'd like to tackle why an explicit process like
evolutionary design helps the industry. 

With Giants & Castles, I stumbled upon the various iterative steps and
then codified them. Once I began following the rules, my design
proceeded more quickly and the modifications I made were better. The
Unreal team also stumbled upon the basic concepts.  However, they had no
steps to follow and large amounts of effort were wasted due to
disorganization, lack of communication, etc. 

A process turns implicit and instinctual knowledge of what works into a
repeatable series of steps that improves a group's ability to manage
their project.

   o A process creates common language so group members can accurately
   discuss elements of their mutual activities.

   o The team can justify scheduling time for essential tasks that often
   get lost in the rush of development.

   o There are concrete expected results listed for each step, so
   everyone knows the goal of their activities.

   o Each step can be improved by checking the actual results against
   expected results

The hope is that codifying observed successful design practices would
help other game designers improve their own design processes.  Take the
evolutionary design concepts in this article.  Adapt them to the
situations you find in your unique work environment.  There's a very
good chance you will build enjoyable games.


References

Diablo II Post Mortem
  http://www.gamasutra.com/features/20001025/schaefer_01.htm

Extreme Programming
  http://www.xprogramming.com/
--<cut>--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list