|
 Features
An Architect's Perspective On Level Design Pre-Production
The
problems we experience late in the development cycle are often the
result of mistakes made early on. As an architecture student in
the early '90s, I've been there more times than I care to recall.
It always seemed like if I had a problem late in the project, it
was due to poor design planning in the beginning.
What
I learned while studying for my architecture degree wasn't so much
construction as design process: the study of taking an idea and
developing it to it fullest potential. After I graduated (and promptly
dumped the standard career route), I started work as a level designer
at LucasArts. I immediately noticed the parallels between architectural
design and level design, and for a videogame junkie with an architectural
education, this was an epiphany. It seemed the processes I used
in school could easily be adapted to level design, so I started
to focus on my design process as well as my designs. This article
describes these lessons I've learned about level design.
Although my examples in this article are based on the first- and
third-person shooter genre (because I just finished one such game
-- Star Wars: Bounty Hunter), it doesn't mean that this process
only applies to those types of games. No matter what game you're
working on, you can adapt elements of my level design process. Take
note of the process structure, not the literal examples, and see
how these processes could work for you.
Also note that the majority of my drawings probably contain a little
more artistic flair than is necessary. Draw at whatever skill level
you're comfortable with, or use an illustration program -- it doesn't
really matter. All that matters is that you attempt to represent
your work in the simplest and quickest manner early on so you always
keep your focus on the "big picture".
Design Reviews
A
classic mistake many architects make is designing for themselves
- not for the client. When a designer works for too long without
a review, the work can become too specific to that designer. In
graduate school, we tried to overcome that by continually conducting
design reviews. We had desk reviews once a week and design pin-ups
once a month in front of a committee. A review committee usually
included several professors, visiting professionals, and other architecture
students.
Design reviews are a forum in which the designer justifies their
work and then receive critique from the audience. This is a very
important step for the designer; it ensures that everyone is on
the same page during the design process. It might sound a bit threatening,
but after a few sessions you begin to see benefits.
To clarify, I am not suggesting you should design your levels by
committee. Review comments should be considered constructive criticism,
and everyone involved in this process should understand that. Listen
with an open mind to what people think about your work, and don't
be defensive. This is about impressions -- what someone thinks
of your work as it is, not what they think you should be
doing. (As long as you adhere to the basic design principles set
forth by the game's design document.) If you hear something you
don't agree with in a design review, be a professional. Take in
the feedback and think about what the reviewer was trying to say.
One of the hardest things for many architects and level designers
to accept is that the design isn't theirs - it belongs to everyone
on your team. Your teammates know that their best work will be going
into your levels, and if the levels are poorly implemented, then
the game as a whole will suffer. That's a lot of responsibility
for the level designer, if not the greatest responsibility during
production. Bruce Shelly of Ensemble Studios summed it up best:
"Unless you are planning on buying one million copies of this
game for yourself, you better make sure your work has broad appeal."
Research
Before Design
This
heading may sound obvious, but it's important to state. Make sure
you know what you're making before you dive in. All too often, level
designers start modeling before they really know what game they're
making, and this results in lots of throwaway work. Take time and
do some research. This is the phase where you put yourself in the
right mindset and get familiar with the core issues of the design.
Here's where you should start your research:
The design document. Hopefully you have a design document
or a project visionary who can articulate the core issues of the
project. Read it or speak with this person and understand what you
should be trying to achieve. Absorb this information completely
and clarify any questions you might have. A level designer's responsibility
is to take the design baton and run with it in all of your levels,
not sprint off on your own.
Other games in the genre. Read, watch and play everything
you can find related to your game's genre. Do whatever you think
will help you get in touch with the spirit of the project. If it's
a first-person military-style shooter, don't just play other games,
get yourself some camouflage pants and paint ball gun and see what
it feels like to be in the thick of combat. Watch a series of military
action films every night for a week, read books on military strategy,
go to military web sites, and read interviews with veterans. Become
an expert in the genre.
Learn from colleagues. A tool I find very useful for research
is Game Developer magazine. The postmortems and design articles
are an extremely valuable resource for the game development industry.
Read what worked and what didn't work from your colleagues and learn
from their experiences. There are also several books on game design
theory and methods that you should consider. Remember you don't
have to re-invent the wheel with every new project.
Know the technical specs. It's important to study the technical
specs of your project. The engine and tools you're going to use
will have a vast effect on the design of your levels. You need to
be as familiar with them as possible. If your team is developing
the software as you go, keep in regular contact with the programmers.
Meet with them often, and make sure some of them participate in
your design reviews.
Brainstorm
Brainstorming
sessions are very important for level designers to conduct. Not
only should you discuss the design document in detail, you should
clarify the kind of game you're going to make. In the early stages
of the design process, it's fine to run a little wild with ideas.
Get everyone together and attack the design. Note which subjects
you fixate most upon: they are probably the most important issues
and should be considered as topics for your next brainstorming session.
In these sessions it's good to have open dialog, but make sure it's
directed and stays focused on level design issues. Often brainstorming
meetings go off on tangents that aren't necessarily related to your
game. I suggest appointing a moderator who can make sure things
don't get off track. Talk about the key gameplay concepts and how
you can best work them into your levels. Use a whiteboard or some
paper you can take notes on during the process.
The Level
Doc
After
your brainstorming sessions and research, you are usually bursting
with ideas for your levels. Instead of diving into level construction
right away, take the time to write them down. A favorite quote from
my professors in school was, "if it isn't on the wall, it doesn't
exist". What they were trying to teach us was that you must
be able to point ideas somewhere on paper - either drawings or words.
This concept is as true with level design as architecture.
This
level document (or "walkthrough document") should cover
all the ideas you have conceived for each level, so anyone who reads
it will know exactly what you'd like to do within each one. Think
about the experience a player will have within the level, and convey
this to the reader. This is an important document for you to use
throughout the entire duration of the project - you'll need to refer
back to it to remind yourself of your core ideas.
Concepts:
"What's your point?"
Level
design concepts should leave the player with memories of distinct
moments in a game, not just a blur of repetitive gameplay. My architecture
professors in school would always ask us, "What's your concept
here?", "What's the big idea for your space?", "What
am I taking away from this experience?" These questions were
intended to focus us on our projects and give our designs some definition
beyond a series of rooms connected by hallways. This can be applied
to level design, too: take some time and try to identify what you
really want the player to experience in your level.
Gameplay diagrams as concepts. For each level of Star
Wars: Bounty Hunter, I had several small concepts and one big
concept that unified the level. For example, one level was described
as "Escort Zam to Safety". Anyone who has designed a level
has probably been given a simple sentence like this and told to
make a level. That's a big concept.
Smaller concepts can be used to break up the gameplay into distinct
events beyond the basic game mechanic. (Some designers use "mini-games"
for this.) One analogy to describe this would be Jazz musician in
a quartette. When a Jazz musician plays, he has to follow the song
as it is written for the most part. This is called "staying
in the groove" and it's what gives identity to the piece. But
during the song there are certain opportunities for that artist
to express himself through solos. This allows for variation in the
piece without a complete departure from the overall song and keeps
things from getting too repetitive or predictable.
As I worked on my past few games, I noticed that there are always
opportunities to use smaller gameplay concepts outside the usual
mechanics. These ideas ranged from simple combat layouts to more
involved gameplay scenarios (see Figure 1). Eventually, I compiled
a list of these diagrams and kept them handy as a sort of grab bag
of gameplay ideas.
Once
I have constructed some diagrams like this, it's time to take some
of them and do some quick prototyping in the game engine to test
them. Get other people to play them, get their feedback, and toss
the designs that don't get favorable reviews. This is the only time
I work in 3D mode before I draw my maps, so I try not to get too
attached to the computer.
Some diagrams I used for Star Wars: Bounty Hunter were a
little more involved. For example, my second level was a dreaded
"buddy" level. It had an NPC that would follow your character,
Jango, around the level, and the mission would fail if the player
left her alone for too long. One problem with this was that Jango
had a jetpack, but the NPC didn't. This posed a challenge because
we didn't want the player to have to walk all the time just to stay
with NPC. Consequently, one gameplay concept I came up with was
to make a series of jet pack obstacles for the player to solve.
Then the player could convert these obstacles into safe walking
areas for the NPC.
For example, the NPC and the player would reach a raised bridge
that crosses a chasm. The NPC can't follow because the bridge is
raised, so the player must fly across the chasm and lower the bridge
from the other side. This is simple, but it's also a distinct event
based on a core concept.
On my third level, someone on our QA team, David Felton, gave me
a great concept: "Falling is fun," he remarked. So, I
made an entire section of a level where Jango just falls. Using
the game engine's physics and Jango's jet pack, the player have
to slow down their decent enough so they don't fall into death traps,
while at the same time directing the fall to a series of slides
leading to the next chambers. Again, this is a simple idea that
produced a distinct, memorable event outside of the usual gameplay
mechanics.
______________________________________________________
|
|
|
|
|
Introduction
