[game_edu] Brenda Braithwaite's game_edu rant at GDC

[Mike Sellers]

On Tue, Mar 8, 2011 at 10:25 AM, Bill Crosbie <bill.crosbie at gmail.com>wrote:


> ...

> I do know that over the past four years of instruction that students who

> came in to the program already able to program were able to apply that

> knowledge effectively to design. Students that were trying to learn how to

> program were so focused on having to think in a structured manner that it

> was a greater challenge to do something innovative with game play.

>


This brings up another aspect of the question "should designers program?"
that I haven't seen addressed yet.

First, yes, I agree that understanding some degree of programming, and in
particular being able to communicate a design in technical terms, is a huge
asset for designers.  As Dan Cook recently said, all designs are fantasies
-- we see the reality only when they're implemented.

At the same time, in my experience at least, much of the mindset of
programming is in many ways antithetical to that of design.  If I'm filling
out a spreadsheet of unit types, or if I'm honing a combat or crafting
system, then yes, being able to think logically and procedurally is vital.
 But that's only a part of design.  The key to design is the ability to
think creatively about the user's experience.

Let me come at this from two angles.  First, in terms of MDA (if you don't
know this you definitely should), the Mechanics aspect in particular
requires solid logical, procedural thinking.  Dynamics benefits from this as
well, particularly in being able to predict emergent conditions (though we
as humans seem almost universally poor at this).  But the Aesthetics part --
what the player experiences and feels -- is wholly different.

Many game designers come at design from the Mechanics side and more or less
let the Aesthetics take care of themselves.  This belies a more programmatic
approach, I think.  Being able to consider the swirl of possible experiences
and aesthetics and pluck from them the mechanics and dynamics you want
requires a melding of creative and procedural thinking (that in many ways is
unique to game design).  But fostering one over the other leads to an
unbalanced view of design.

The second view on this, briefly, comes from my work in user-centered
design.  In traditional UCD, we spend a lot of time on user, task, and other
analyses before designing a solution.  What makes games unique is that
unlike all other kinds of software, games have no pre-existing, external
task.  A large part of game design is coming up with the users' tasks and
goals in ways that will make for an engaging, satisfying experience.  While
these must be reduced to code, certainly, it's been my experience that
approaching them too procedurally, too much from a coding POV, results in
lifeless ideas that do not make for good games.

Ultimately, the successful game designer needs to be able to think
creatively (within constraints, including technical ones) and then either
reduce that thinking to practice via code, or be able to work with those who
can.  These are not the same kinds of thinking however, and over-reliance on
one can reduce the ability to quickly move to the other.  It may be that we
have a generation of designers now who can't code and so are deficient in
that respect; but my suspicion is that the creative part is the more
difficult to identify and to teach.  We should not make the mistake of
telling designers to code in part because it is the more quantifiable and
identifiable behaviors associated with design.  Let's not ignore the more
difficult to quantify but ultimately vital aspects of creativity in game
design.

Mike Sellers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/game_edu/attachments/20110308/86b187af/attachment.html>