|
 Features
Soapbox:
What Ever Happened to the Designer/Programmer?
Computer
gaming is unique among art forms in that it has undergone a transformation
from a solo medium to a collaborative one. For the most part, theater
has always been a group effort, and novel writing has always been a solitary
activity. However, since the early 1980s commercial computer games have
changed from being developed by a single designer/programmer/artist in
a room alone with a computer into projects undertaken by large teams in
similarly large offices.
This change
has had a number of significant effects on game development: management
has become much more of an issue; games have become considerably more
expensive to develop, limiting the quantity and type of games that get
made; the games have changed from representing a distinctly personal vision
to that of a group; and the position of lead designer/programmer has been
distributed between two separate people. While the first three of these
effects may be inherent to the way that computer games have changed as
a medium, the last change seems to have come about accidentally, and,
to my mind, is not a change for the better.
On one hand,
it makes sense from a management perspective that development tasks be
divided in the most logical way possible. On cursory inspection it might
appear that designing gameplay is an entirely different discipline from
actually implementing it. But on the other hand, there are many advantages
to including a multi-talented designer/programmer on a team, regardless
of the team's size.
A designer who programs will be able to implement the design he or she
has in mind perfectly, resulting in time saved both communicating that
idea to a programmer as well as reducing the amount of rework required
to get that idea working optimally. Furthermore, any programmer knows
that coding a game is full of "little" decisions that no amount
of designer forethought is going to be able to anticipate, yet it is these
programmer choices that ultimately establish the elusive "feel"
of a game. All good designers know that - regardless of their own skills
- if the programmers working on the game don't have a good sense for gameplay,
the final game is not going to be worth a damn. Who better to make sure
this "feel" is correct than a programmer who truly understands
the game's design?
Designer/programmers have the further advantage of better understanding
a game's core technology, leading to thorough exploitation of that technology
to create a superior game. Designers with a weak technical background
will often fail to understand what can be accomplished trivially and what
is nearly impossible to pull off. Indeed, some programmers will use this
fact against unsavvy designers, claiming that tasks are impossible merely
because they don't want to add them to the game.
It's a sad truth that designers who cannot program are at the mercy of
the game's programmers and what they feel like adding to the project.
Though a designer/ programmer may not add every last feature to the project,
if the gameplay is not turning out as hoped, at least a designer/programmer
can step into the code and adjust it until it's perfect. Furthermore,
designers who can add features to games themselves are much more at liberty
to experiment with the gameplay and to try out bizarre ideas that no one
thinks will work. In the end, such quirky ideas may turn out to be the
best elements of a game.
Despite the many advantages of having a designer/programmer, few companies
today seem to use them. When I was looking for a new job two years ago,
I found no studios who were interested in hiring someone who would both
design and program games. In part this may be because programmers are
so rare that those a company does find need to be programming constantly
and not spending half their time working on levels or writing design documents.
Perhaps there are fears, again from a management perspective, that having
a designer/programmer concentrates too much power and responsibility in
a single individual.
But if one looks at the industry's most revered designers, one will find
that a significant number of them started out as programmers - Richard
Garriott, Chris Roberts, Steve Meretzky, Jordan Mechner, Dani Bunten Berry,
and Tim Schafer, to name just a few. Furthermore, a similarly impressive
list continue to program on their projects to this day - Sid Meier, Peter
Molyneux, Ed Logg, BrianReynolds, Jason Jones, and Eugene Jarvis. I was
fortunate enough to interview Sid Meier for my book, Game Design: Theory
and Practice, and questioned him about how he could possibly have
time to be lead designer and lead programmer on his projects when so many
teams divide that position between two individuals. His immediate answer:
"Well, I think they probably spend half their time talking to each
other, which is something I don't have to do."
The breakout critical and commercial success of Roller Coaster Tycoon
is a prime example of the perfect synergy of the designer/programmer.
Chris Sawyer was not only the lead designer/programmer on the project,
he was the only designer and the only programmer, making the game's development
extremely reminiscent of projects from the early 1980s. It seems that
Sawyer's filling of both roles gave the game its very personal feel, a
unique vision that is a huge part of the game's appeal.
Of course, few commercial games are small enough in technological and
gameplay scope to be developed by a single person, but having a designer/programmer
on the team can be a boon for any project. Though it's indisputable that
many great games have been designed by people who have never programmed,
it appears that designer/programmers have a distinct advantage at creating
compelling interactive works. Game studios would do well to consider this
when assembling their development teams.
______________________________________________________
|
|
|
|
|
