Game Development Reference
In-Depth Information
A game designer's task has much in common with that of the Wrights.
Like an airplane, a game is a system. It serves a different purpose, but the
process of inventing it is fundamentally the same. Game designers are
inventors of machines for generating experiences.
The Wrights' process sounds a lot like iteration. But it's clear that the
three-part iterative loop is a criminal oversimplification of what they did.
The Wrights tested often, but not on any fixed schedule. Their process
was organic, with many different actions interacting and overlapping.
Their approach changed every day in response to their needs. The same
applies to game designers. Some days we must plan. Other days we must
ruminate, calculate, draw, or invent a new knowledge-creation method.
Invention isn't a repeatable assembly-line process. It is an ever-changing
intellectual frontier.
So the diagram of iteration I showed you earlier is wrong. Real game
design is more organic, like this:
And the process becomes a thousand times more complex when
teams grow beyond a handful of people. Knowledge creation is madden-
ingly fluid and fine-grained. It bubbles up in every developer, every second
of every day. Every thought a designer has creates knowledge. Every time
an artist leans back and squints at a scene to get a different view of it,
he creates knowledge. Each time a programmer runs the game for five
seconds to check the feel of an interface widget, he creates knowledge. An
iteration loop can't direct this, and nobody could lay it out on a schedule.
It's unfathomable.
That's why, as designers, we must remember that we can only direct
the broad strokes of the process we're running. The reality is always more
organic and complex than our conception of it.
