[MUD-Dev] Evolutionary Design

[John Buehler]

J C Lawrence posted:

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

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

An *excellent* introductory paragraph.

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

Much of this applies to any interactive product.  If the product
requires interaction by the consumer, then the designer must
anticipate the consumer reactions to whatever it is that the product
does.  This is very applicable to software.


> The Evolutionary Process

Also known as iterative design.

> The Death of the Ego

Another important point.  In order to see things clearly, one must
take one's own ego out of the equation as much as possible.  Good
rule for life, actually.

> Step 1: Focus on a fundamental activity

This is what I always consider the Grand Vision.  If you pick a
fundamental activity for your game, that will determine the eventual
game that you get out of it.  People's reactions to that fundamental
activity will determine what you can and cannot have in your game if
it is going to continue to operate in a way that players find
natural.

> Step 2: Play the Game

No argument there, although the designer has to realize that he or
she is a niche market.

> Step 3: Observe the Game

Microsoft has a thing called a Usability Lab where customers go into
a room and use the product.  All the while, folks watch what they do
and often record their interactions with the product.  Because the
products are not social, the disappointments and frustrations aren't
broadcast to others.  The are usually indicated by no more than a
pause, a frown or a quizzical look.

The technique that Daniel presents is a very good one for small
scale operations.  As a software designer, it always drove me nuts
that I couldn't see and interview customers working with my product
that was in its external test phase.

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

Preach it, Daniel!

Daniel has lots of observations about how he tackled his board game,
but I wanted to observe that a designer's world view always goes
into the design.  If you believe that risk and reward are the sum
total of being, then you may well make that the focus of your game.
If you believe that moral issues are the sum total of being, then
you may well make that the focus of your game.  And so on with
exploration, economics, intrigue.

> The Life Cycle of an Evolutionary Design
> Stage 1: Prototyping
> Stage 2: Balancing
> Stage 3: Equilibrium

This matches the typical software application's design process.  I'm
sure most people who are planning just about anything realize that
this is how it goes.  You come up with an idea, refine it until the
refinements become uninteresting and then you lock it down.

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

And when somebody examines their world view, thinks that they know
what is fun, and goes off and starts from that basic tenet, that's
when we get a 'visionary'.  Who knows where that basic idea will
lead in terms of entertainment.  Probably not the designer, because
all that's on the designer's mind is that basic tenet.

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

Here Daniel is talking about a fundamental activity, but it doesn't
cover how that activity appeals to the players.  It's just an
activity that they can understand.  His world view will govern how
stacking is presented to the players.  Do they cooperatively stack
or competitively stack?  Is there a risk/reward structure behind
stacking, etc.  The game may find an audience and they may enjoy it
tremendously, but if they do, stacking will be an aside as to why
they enjoy it.

> 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

My suggestion to game companies is to hire experienced software
engineers who actually know what they're doing.  If I were to say
one thing to a software developer, it would be "Know Thy Software".
The value of Extreme Programming, and many other techniques, is to
ensure that the people building the software know what they're
doing.  That they can keep track of the tasks that they're doing.
Often, this means having multiple brains on a problem so that they
are checking with each other, talking and making sure that they
understand what they're doing.  If they understand it, they can
appraise its accuracy to what they're trying to do.  Incremental
changes can be understood, so that's another technique to use.  Bugs
come from lack of understanding.  Period.

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

And by managing change, the people involved keep track of
understanding what they're building.  When people lose track of what
they're building or it becomes something other than what they think
it is, bad things happen.  When bad things happen, greater
misunderstandings develop and it can easily spiral out of control.

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

Heh.  I hate to think what percentage of the software industry's
dollars go poof due to this phenomenon.

> 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?

Understanding reality goes a long way to ensuring that you know what
you're doing.

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

Note that software engineers have been building products on a large
scale for a couple of decades now and there is still no standard
process for us.  I think that's partly because of the fact that
there is no clear winner in the choice of process.  I think it's
also partly because the articulation of process to those who pay the
bills is a very difficult thing.  Not until some big companies adopt
processes that are obviously effective will the industry start to be
swayed.  I'm fairly certain it will be an evolutionary process of
adoption.  :)

JB

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev