Evolutionary Design

Published January 18, 2002 by Daniel Cook, posted by GameDev.net
Do you see issues with this article? Let us know.
Advertisement

A practical process for creating great game designs

 

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 interrelated 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 environments. 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 cutscenes 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 a 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 ensue.  Thank goodness. 

I used the following requirements:

  • Rules consisting of a single page
  • 5-minute learning curve
  • Average play session of one hour
  • Must entertain a wide range of people
  • 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 to predict how a complex system will behave when you make changes to its 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 gameplay 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:

  • Pick up a room: Remove token from a castle stack and add to your giant stack
  • Drop an item: Remove a token from your giant stack and place it on an adjacent stack
  • 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:

  • 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.
  • Focuses game balancing: If the designer can make the core activity enjoyable, then 90% of the game is enjoyable.
  • Provides a solid foundation for additional rules: Every spell in Giants and Castles is based on 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.

  • Let other people play the game and then observe them.
  • 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 gameplay.

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 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 through systems governing the transfer of resources.

In Giants and Castle, I had four major resources:

  • Rooms
  • Treasure Rooms
  • Spells
  • 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 gameplay.

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 a 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.

  • 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'.
  • 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.

  • 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.'
  • 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.
  • 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 gameplay 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 gameplay 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.

  • 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.
  • 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.
  • 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.  Longtime 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 gameplay. 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 gameplay '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' gameplay.  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 playtesting 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 gameplay 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 correspond 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 months 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 gameplay 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:

  • Technical requirements for getting artwork into testing as soon as possible
  • Rough background story that gives artists conceptual details to draw from. 
  • A general artistic theme that will fit the game
  • 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 grassroots 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 an 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: 

  • Large tracts of plot
  • Dozens of intricate game systems
  • 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.

  • They made stuff, including seemingly random maps, characters, and weapons
  • They messed about with their creations
  • They tossed things that didn't work
  • They kept on doing this for the length of the project
  • 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 cancelled, 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.

  • A process creates common language so group members can accurately discuss elements of their mutual activities.
  • The team can justify scheduling time for essential tasks that often get lost in the rush of development.
  • There are concrete expected results listed for each step, so everyone knows the goal of their activities.
  • 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/

 

This article originally published to GameDev.net 18th January 2002.

Cancel Save
1 Likes 0 Comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement