5. Not Taking Advantage Of Placeholders
Placeholder assets and code are used a lot in this industry, yet placeholder
use often greatly diminishes once production starts. It is
understandable. If a developer is working for a publisher, it's very
important to show progress. Going from a nice shiny vertical slice to
builds filled with jerky animations and flat-shaded backgrounds can look like a
Internally, team members,
particularly artists and animators, generally prefer working on final assets
than low-quality ones that will have to be replaced later. Producers generally
prefer something done once rather than twice. Unfortunately under-use of
placeholders reduces final game quality and slows down the design
The basic scenario goes like this: a designer
wants to see an asset in game -- be it a 3D model, an animation, a gameplay
mechanic, etc. Rather than wait a few hours for a placeholder, he must wait a
week for the finished asset. If what he receives isn't as fun as he had
imagined, that will be a week of work wasted.
To avoid this from happening,
long approval processes are often implemented with the intention of weeding out
all but the best ideas. In practice the approval process can shear off all but
the least risky elements of the idea until it's lost its originality.
instead of trying out an idea with a placeholder and moving on, the designer
must wait a week to receive a final asset that is often far less interesting
than what he would have discovered through experimentation with
Working without placeholders wastes time in many ways. Levels made up of
hundreds of 3D meshes take longer to load and test than those that are made of
simple BSPs. They take much longer to modify because they're made of 100's of
pieces instead of a few simple shapes.
Finally less experienced mission
designers will waste time showing off their interior decoration and lighting
skills when they should be focusing on making fun gameplay. Some flat-shaded
textures, a pool of placeholder 3D objects, and a watchful eye of an artist to
make sure things are architecturally sound should be all a mission designer
needs to make fun environments.
A placeholder-heavy game design process requires a lot from a lot of
people. It requires a studio that can shuffle artists to other duties
while the design team settles on what they want for the "final"
It requires faith that the higher-ups (be they an external
publisher or an internal studio head) are not as superficial and can appreciate
the value of a fun, if ugly, level filled with placeholders. If you don't have
this faith, outside playtesting can be used to quantify the "fun" in
lieu of showing polished graphics.
6. Allowing The Story To Control The Game
In television and film a writer writes a script and hands it off to a
producer. The crew then uses the script as a map for telling a story to
the viewer. This process can work for video games so long as the main purpose
of the game is to tell a story to the player.
Games such as those in the Final Fantasy series as well as many
JRPGs and adventure games can succeed on a great story alone. If the main
purpose of your game is put your player into the middle of a highly interactive
experience, than this method is inappropriate.
If your game is Halo, Call of Duty, or God of War, the script should be shaped around the gameplay and not
the other way around. Things such as level design, play mechanics, and
pacing are the most important factors. If these things aren't solid, no
amount of storytelling can pick up the slack. This is not to say story
isn't important, but rather the writer should be flexible enough to change the
story based on what presents the player with the most compelling interactive experience.
Giving the story priority over other elements of game design can lead to
trouble. A classic example is the 2003 title Enter the Matrix.
The plot of the game and its live-action
cutscenes were made to weave in and out of the movie The Matrix Reloaded; the movie's creators
were heavily involved.
The result was levels that made sense from a story
perspective but had no purpose from a gameplay one. Furthermore the dev team
was stretched thin creating three different game types -- in car, on foot, and
in hovercraft -- because the story demanded it.
I once worked on a third-person action project with a script that was handed
down to us by a Hollywood writer. While an interesting story, it conflicted
with a lot of the gameplay elements that had been designed. The script called
for levels in intimate locations with a handful of enemies when the game
mechanics were set up for huge firefights large cover-filled locations.
The game had been designed with
a partner in mind that the player could give orders to, but the script
demanded that the player should be alone for a large part of the game's
second half -- destroying the learning curve. The cancellation of the
project was largely due to the design team being forced to follow the Hollywood
The story of an action game should be the responsibility of a game writer. A
game writer is someone who's written for games before or at least is a gamer
himself. A game writer will be with the team full time and understand why
his story needs to be reworked continually.
He won't get flustered if the
design team decides the airport level makes more sense in the beginning of the
game rather than in the end. Writing for games is not the same as writing
for films. Simply cutting a Hollywood man a check to deliver a script is not the way to