McGraw-Hill - 2003 - Ultimate Game Design. Building Game Worlds - DDU02
McGraw-Hill - 2003 - Ultimate Game Design. Building Game Worlds - DDU 02
xx U L T I M A T E G A M E D E S I G N
Building Game Worlds
There are many reasons why the development of great gameplay frequently faces
many obstacles—as we’ll soon discuss. In order to succeed, game developers need to
be able to build up fun and addictive play into their games quicker and more surely
than ever before. Yet prototyping play mechanics and experimenting with many aspects
surrounding gameplay still poses several layers of challenge for many game developers.
It is still not very easy to prototype and experiment with game dynamics while keeping
costs under control.
With this firmly in mind, one of the most important questions this book tries to
address is: What might be required to make applied game design more feasible for
game developers in general? I try to offer up several answers.
I think that looking into applied game design in the way I’ve tried to for the purposes
of this book gives all budding game developers a chance to learn first hand about
design challenges, while asking established developers to think about solutions that
might help to ease some of the same challenges. I see this as a dialogue that might help
make more interesting kinds of gameplay possible.
Of course, as we’ll soon see in detail, it often comes down to the brute development
specifics: tools, smooth tool-to-engine interface, adequate ability to prototype and
experiment, beginning your development cycle with solid concepts that can be altered
and adjusted on-the-fly for improvement and refinement toward the fun zone, and
so forth.
Those game developers or middleware providers that succeed in supporting game
content construction in the most powerful and dynamic ways, thereby enabling
developers to build-in the best kinds of gameplay possible, will probably find themselves
on the top of the game sales charts. It isn’t a secret anymore that several of today’s
top-selling games are based on technologies like RenderWare that conceivably allow
game makers more time to flesh out exciting content details and worry less about
jumping over gargantuan technology hurdles. My point can be summed up here: if
content is king, it’s time to build the throne.
It’s in this spirit that the book was created. It’s time to ask tough questions and
find solid answers in the area of applied game design. It’s time to move away from
having to learn an entirely new design tool every 20 minutes. I know that if you use
the material assembled here as a starting point, you’ll soon find many ways to quickly
build or reinforce your understanding of the many forces that help to shape game design.
CHAPTER 1
Previsualization
1
game design process begins by synthesizing and harmonizing vari-
THE ous gameplay ideas and concepts. The very early stages of game de-
sign are, by nature, heavily conceptual. Game concepts have to be pulled down to
Earth and given shape and definition. These concepts, when working together to
form a gaming experience, will have to share a small boat on a large ocean. They will
be required to work together tightly and forcefully. Only when our game concepts
row the boat together in harmony will we achieve any exciting motion. A game that
seems “only to float” hasn’t achieved this harmony. In some cases, concepts that
might otherwise have worked out well are not given life in execution. Keep in mind
that professional game design always occurs in parallel with a multitude of con-
straints, objectives, and considerations.
In this chapter, we will focus on the initial stage of game concept harmony, some-
times called the previsualization process. Perhaps the best way to understand this
process is by discussing it in the context of an example. Thus, we’ll look at the “cathe-
dral” example. This specific example could be the game setting for a first- or
third-person action title, but the previsualization process that we will discuss for this
example can be applied to many game genres.
Each subsequent chapter will address in detail the process of “building up” or exe-
cuting your own game ideas. We’ll cover many topics that relate to giving shape and
form to your own game concepts. In summary, we will consider the following:
Level construction The process of creating game environments
Lighting, texturing, particle systems, effects, and audio How we detail our
game environments
Props, items, and behaviors How we stage or set up our game
environments
Camera considerations How we handle camera issues
Scripting action events How we create event behaviors
QA and player feedback loops How we test and refine game titles
Design considerations for emerging game forms New venues for games
2
C H A P T E R 1 3
Previsualization
I NTRODUCING THE PREVISUALIZATION
PROCESS
It helps to know where you’re going before you get there, so that you can be pre-
pared. Tropical jungle? Bring the bug spray. Exotic island? Bring the suntan lotion
and spear-fishing gear. Similarly, when you are developing a game, title planning and
attempting to predict trouble spots are critical to successful execution. Thus, most
game titles, in the early days of production, go through a quick series of
previsualization passes, the goal of which is to lock down a visual style—even if
you’re building the next frantic puzzle game based on alien octopus larvae marbles!
What do alien octopus larvae marbles look like? Can somebody show me? Is there a
museum? Is it open? Some development teams keep this process informal, while oth-
ers take it very seriously. Whether you’re building the next fighter, shooter, or envi-
ronmental action game, you need a visual roadmap.
The real point of previsualization is to help take your game vision in an
agreed-upon direction and to create a visual or stylistic reference point; a visual an-
chor, so to speak. Of course, deviations from this reference or anchor point can be
made. The visual style can and will evolve over the development cycle. It might evolve
slightly. It might change dramatically. Previsualization simply creates a useful start-
ing point for everyone involved in the project.
Next, as we look at the previsualization process itself, we’ll examine the following:
Utilizing concept and reference drawings
Implementing basic level architecture and environmental design. (A level is
a self-contained section of the game experience with its own beginning and
end. Most games feature many levels that must be completed in order to
finish the game as a whole.)
Doing concept work on paper and building topographic reference maps
Making simple asset breakdowns from your design
S TEP-BY-STEP PREVISUALIZATION
Since most game development cycles rarely allow for lengthy preproduction cycles,
developers often face the challenge of delivering creative and technical design docu-
mentation rapidly. Any previsualization work that can be accomplished under tight
time constraints will normally be done as the overall project details settle into place.
Previsualization will happen during a small slice of time while a game title ramps up
toward full production.
4 U L T I M A T E G A M E D E S I G N
Building Game Worlds
For many game developers, having the time to do aggressive previsualization is a
luxury. Yet, those who scramble together the time to do some previsualization often
save substantial amounts of time over the course of development. If a team is forced
in midproduction to determine many of the visual formatting details that might have
been resolved in a previsualization sequence, progress may be stalled and precious re-
sources may be wasted.
In what follows, we’ll walk through the process of completing a basic
previsualization sequence, culminating in the construction of a “cursed cathedral” as
our example.
Utilizing Environmental References and Sketches
Every game has an environmental setting—a physical location created to “host”
gameplay. We’re not just creating floor plans for a retirement village (that’s a side
project). We’re hosting gameplay! Whether you’re trying to simulate the atmosphere
of a Western casino, a colorful and sugary cartoon world, or the burned-out rem-
nants of a mining tunnel system on a distant star (or maybe all three at once—yikes!),
the environment will in large part help define and dictate the mood. Mood forms a
part of the player’s emotional connection to the game. Gameplay mechanics and
gameplay devices are what keep the player engaged, active, and excited, which sup-
ports a mood-driven or emotional experience. If you don’t engage a player’s emo-
tions, the player will have a flat, nondynamic experience. Most of the games that we
all love to play seem to blend mood and game mechanics seamlessly. You can’t tell
where one stops and the other begins. If you’re not screaming at the monitor or televi-
sion, whoever created that game might not get to make another game.
Simply put, the environment should support and complement gameplay—not de-
tract from it. Environments, by their very visual style, can shift or alter the mood sub-
stantially. Warm and happy might describe the mood generated by a well-crafted
Sugar World. Dark, anxious, and brooding might be the mood generated by your
own private Apocalypse World. Thus, when trying to set the visual style for an envi-
ronment, it’s often very helpful to use plenty of reference material, such as photo-
graphs, drawings, illustrations, and pictures that help influence a visual or stylistic
direction. This point may seem obvious, but it’s sometimes forgotten in the fray of
development. Reference material gives a team something concrete to talk about. Sug-
gesting that a game should look like Blade Runner is useful at a conceptual level, and
suggests a certain style, but really doesn’t help lock down the messy details. What
does a pay phone/telecom unit look like in the Blade Runner world? Inquiring minds
want to know—especially when it’s due on tomorrow’s schedule.
The basic point is that providing adequate visual reference is always helpful to art-
ists and designers and is usually very helpful to the development team when establish-
ing a reference point. Many aspects of game development begin with useful and
C H A P T E R 1 5
Previsualization
substantial reference points. Not all of them are visual. Some are conceptual. Some
are concrete game devices that have worked to great effect in other games.
As an example of a drawing that could be used as reference material, consider Fig-
ure 1-1, which shows The Mole of Hadrian (from “Antichita Romane”) by Giovanni
Piranesi (1720-1778). Hopefully, you can see immediately how such a drawing could
influence environmental construction, mood, texturing, and lighting. Not bad for
one drawing. You wouldn’t necessarily try to replicate the look and feel of the draw-
ing—although you might be tempted. Better still, it would stand as a great reference
point and starting point for developing the visual style for the parts or whole of a
game—a springboard for visual ideas with a common starting point. This is the criti-
cal point in using environmental references and sketches to support your regularly
rushed previsualization phase.
Architecture for Game Levels
Game worlds offer definite freedom in architecture. It is a “controlled” kind of free-
dom because as you are building up game environments, you must constantly weigh
options and make trade-offs. For example, you might want certain physical features
and complexities that would look wonderful to the player, but those same features
FIGURE 1-1
Piranesi’s The Mole of Hadrian
6 U L T I M A T E G A M E D E S I G N
Building Game Worlds
may end up degrading the game’s performance or running speed to a degree that is
way too slow to be any fun to play. This won’t do at all, because when the lights go
off at night and Junior gets tucked into his racecar bed, it’s all about the fun!
Chugging frame rates are not fun. Remember that a game level is a self-contained sec-
tion of the entire game experience, and each particular level will have its own unique
performance challenges.
Frame rate refers to the speed at which a single frame can be redrawn to the screen
following another frame; kind of like a flipbook animation. How fast can you make
the pages flip? That’s your frame rate. A “chugging” frame rate is a frame rate that is
too slow to provide adequate game play performance or satisfaction. You want as
much visual pop as possible, while maintaining fundamental performance. This is
the crux and crisis point. Let the trade-offs begin! At its simplest, for modern 3-D
games, the more stuff you put in the scene that uses polygons on drawing the scene,
the more performance speed you stand to lose.
Also, what works in traditional architecture doesn’t necessarily make for compel-
ling game environments. Generally, interior levels—such as the inside of a cas-
tle—can be adapted from real architecture and “bent” into game shape. You want
architecture that makes sense as a level layout, but you also want architecture that’s
fun (and fast) to navigate or move around in. So, it often helps to start with an exist-
ing reference point, like the floor plan of a castle, and then tweak and modify it into
game shape. Or, you can start with something entirely new if you wish. Either way,
you’ll need solid reference material.
The nice part about working in the digital world is that you can combine bits and
pieces of architecture from several different castles to build the ultimate castle inte-
rior. If you tried to build the real thing, it would fall apart like a sand castle in the surf,
but it sure looks good. No matter what game genre you’re building for, it always
helps to start with a reference point and then adapt and refine it for gameplay. In fact,
gameplay itself should determine level layout. Remember, environment supports
play, but play is the deciding factor.
Basic Environmental Design
In a networked multiplayer environment, characteristic of many of the games made
today, it makes sense to consider a couple of simple ideas about layout. After all, if
you’re going to have several players roaming a level or arena, you will want to con-
sider carefully how they’re going to navigate your map.
Entry and Exit
In general, bottlenecks and dead-ends don’t work too well in a multiplayer environ-
ment. However, this is considered a “soft” rule because there are always exceptions.
For example, someone may point out a case in which a bottleneck makes for a perfect
C H A P T E R 1 7
Previsualization
gameplay foil. (A “hard” rule is one for which no exceptions exist, such as “Avoid
frustrating your player!”) When it comes to environmental design, the softer rules of-
ten give way to solid testing feedback, player comments about what works and what
doesn’t. We’ll learn all about this process in Chapter 7. It’s up to you and your team
to figure out why something works or doesn’t work. Testing feedback is the single
most important measure of whether you’ve succeeded or failed at building a great
venue for play.
If you create a stock point or power-up point (a space with a variety of power-ups
like health or ammunition available together) in a dead-end area, the player may
have to risk much to get at it because the corridors leading to the dead-end area may
have high traffic—plenty of enemies stalking the player. This suggests that having
multiple entry and exit points is a good thing. If certain areas have only one way in
and one way out (see Figure 1-2), it becomes pretty obvious where a player might
take their first step toward their own undoing. It’s generally better to have multiple
entry and exit points so that players can flee a situation easily, and so that their ar-
rival/departure point is not so easily predicted (see Figure 1-3).
FIGURE 1-2
Player caught in a bottleneck
8 U L T I M A T E G A M E D E S I G N
Building Game Worlds
FIGURE 1-3
Player can flee north
F UNCTION
During the previsualization process, it is always useful to consider function, which in
this context is something akin to “gameplay purpose.” A well-crafted game environ-
ment has several simultaneous goals (for example, support actions and character
abilities in an exciting way, perform at optimum speed on the given hardware, dis-
play logic in the environmental lay-out, and be navigable). At a minimum, you want
your game environment to support in the right physical ways the kind of play dy-
namic you are trying to build or graft into the environment. This is a cross-genre prin-
ciple. It makes little difference what kind of game we’re talking about—from a state
of the art first-person shooter (FPS) to a multiplayer party arena game—in all cases,
you want to give forethought to the environment and its function (gameplay pur-
pose) and direct your thoughts toward supporting gameplay. In the end, the environ-
ment that you’re building will be built to host gameplay.
C H A P T E R 1 9
Previsualization
Building an environment to host gameplay is quite different from building an envi-
ronment for visual impact alone. You want both—an environment that hosts
gameplay well and is visually striking. The primary idea here is that for your levels
(first- or third-person games), arenas (death match or player vs. player scenarios),
maps (real-time strategy games or role-playing games), and playfields (action,
twitch, or shooter-style games), you want an environment configured in the right
ways to support your main objective: solid play. If you give little or no thought as to
how best to construct an environment in support of gameplay (for whatever reason,
whether it be a tight development schedule time or resource shortages), the results are
often frustrating and do not support solid play.
So, as you consider function and layout, think about the play mechanics and play
goals you’re trying to build. How you begin to set positions or lay out your play space
will depend on the kind of play mechanic you’re trying to build. Of course, this varies
according to which game genre you are working in.
Start by asking yourself a question: What is my game’s heartbeat? The “heart-
beat” refers to the primary or fundamental game mechanic that lies at the root of
your game. It is your game’s driving force. It is why players will want to play your
game. Always try to keep your game’s heartbeat in mind. No doubt, this heartbeat
will suffer many palpitations and skipped beats along the beating path of game devel-
opment, but your game’s heartbeat should be kept in mind to help guide the thou-
sands of decisions that will be posed to your development team along the way.
If you forget about a game’s heartbeat, the game can grow into a surly five-headed
beast almost overnight, and you’ll be hacking and slashing at your game’s Hydra
heads for some time to come. This is a difficult situation. Many game development
decisions along the development curve will be informed by keeping simple principles
clear in your mind. It’s always a challenge to learn how to do this under real-world re-
source constraints. As a team, you will have game direction ideas coming at you from
4002 sources—including those paying for your game development and those who
own the character and world rights you are currently meddling with.
What is the heartbeat? Clear up the answer in your mind. Clear up the answer with
your fellow team members. Act on it.
Although many game developers disagree on the deep details, many game heart-
beats are deceptively simple to express and remain true across genres:
Kill or be killed by other players or things (examples include Quake III
Arena, Asteroids, and Twisted Metal Black)
Let me grow my skills, abilities, powers, influence, or recognition in some
way (Everquest and Diablo II)
Let me control the simulation of a process (Rollercoaster Tycoon and The Sims)
Take me on an adventure of type X, Y, and Z (Grim Fandango and Myst)
10 U L T I M A T E G A M E D E S I G N
Building Game Worlds
Is this level of reduction and simplicity even useful? Definitely. Your heartbeat
might combine a couple of these statements, but be careful. Most successful games
don’t go too wide with their heartbeat statements. You should be able to reduce your
game’s heartbeat to one or two sentences at most. Don’t try and be everything to ev-
erybody. How do simple statements like these have any power in an age of never-end-
ing technological advance and gaming possibility? All I can say is, there is great
power in reduction sometimes.
How do you use a heartbeat statement? After you have defined your heartbeat
statement, you and your development team should evaluate the potential of each
feature, function, mode, asset, or ability based on whether it adds to or subtracts
from accomplishing your heartbeat statement. Game building is exploration. You
may not know until you try it, but you can limit the pursuit of “peripheral ideas” by
checking your idea for a feature or function against your game heartbeat. If it does-
n’t move you closer to presenting your heartbeat statement for the player, then
don’t bother with it. If it does, then weigh its true impact further and consider its
feasibility.
Keep in mind that building a next-generation game is a team function. You will be
working as a team member to help establish the heartbeat for your game. You will
not be working in solitude sending down “heartbeat” declarations from your throne,
after servants have set up an afternoon tea. In other words, part of the game design
process itself is learning how to work as a team to reach a “buy-in” or group agree-
ment for the game heartbeat. Each team member will bring their own particular
game experience, orientation, and passions to lend support or rejection for game di-
rection ideas. Normally, game producers and designers help to guide this process
through many iterations and revisions toward establishing a clear game heartbeat—a
game heartbeat vision that an entire team can share and charge toward.
With respect to function, start by asking yourself the following questions:
Are you building a game where competitive racing gives players the ability to
enhance and customize their vehicle over a series or race circuit?
Are you building a game based on collection and combat with offense and
defense?
Are you building a game based on simulating a growth process?
Knowing the game heartbeat is fundamental and will help answer these questions.
Establish the heartbeat first and build from there. The heartbeat will help inform the
details. It will help determine the function. It will help show you how to build and
evolve the right kind of environment in the right ways for your game.
C H A P T E R 1 11
Previsualization
Room Flow
Room flow is important because it gives shape to your game play function ideas.
Many current games depend on room-to-room interiors as environments for play.
For example, first- and third-person shooters are routinely set within building inte-
rior components. At the high concept level, rooms must connect in some fashion,
such as through direct or implied hallways. An “implied” pathway (such as a well-
worn dirt path would be an obvious example, a logical connection in level areas from
front to back or top to bottom might be another less obvious example) is generally
very helpful for the player in navigating your level, if a path isn’t obvious. Different
room types and room scales (such as the size of a room compared to the size of your
character or vehicle) are connected through implied pathways. For example, you
might be exploring a “prison cell” section of a level, which connects with a subterra-
nean command center, which in turn connects with a tunnel system that connects
with a vehicle hangar.
Room interiors vary in function, mood, scale, purpose, and many other particu-
lars. So, then, how are the rooms put together into a cohesive level? Previsualization
for room flow often requires a look at two critical areas: logic and symmetry.
When considering the logic of your room layouts during previsualization, you
need to ask some basic questions: Is there a logical connection between rooms? How
will basic room flow work as a transition from one playing space to another? What
kinds of play and primary action elements do you expect these rooms to contain?
Gameplay direction should always influence and shape environmental design
choices. If you’re going to be using long-range projectile weapons, you probably
don’t want short or cramped spaces. Room spaces can even be used to prompt certain
responses from players; for example, the lay-out logic of a room space may suggest to
players that it would be a good area to search, that it would be a potential high-con-
flict area, or that it would be a great cover and resupply area.
Physical symmetry is probably most important for team-based games like capture
the flag (CTF) and others. When you’re invading another team’s area to capture
something and bring it back home, the distance your team must cover should be the
same as the distance the other team must cover; otherwise, you have an immediate
imbalance. Yet, even for two player co-op or single play maps, those that offer some
kind of physical symmetry are often less confusing, easier to navigate, and generally
more enjoyable than those that feature no symmetry at all. Maps or levels with an un-
ending series of connected rooms laid out in a serial chain, one after the other,
quickly lose their sense of “place.” It becomes hard to tell where you are as a player in
relation to anything else in the level. On the other hand, levels that have a direct or
implied symmetry in their layout provide the player with valuable visual reference
points (for example, the tower is at the center ring). Symmetric levels seem to “feel”
better and make traversal (running around) easier than levels that offer little or no di-
rect symmetry at all.
12 U L T I M A T E G A M E D E S I G N
Building Game Worlds
In fact, you can see the symmetry when you start with an overhead map or topo-
graphic map as the basis for your level layout. It’s part of what you’re trying to work
out on paper. When you’re running around your favorite levels, stop and take a mo-
ment to consider symmetry. Are you even aware of it? It’s actually best if you’re not
aware of it as a player. In that case, symmetry is working its magic. As a designer,
though, you’re looking for patterns like symmetry. You’re looking for patterns that
help drive the play.
Interior to Exterior
Interior to Exterior transitions are an important expression of function. Many popu-
lar titles use environmental features that segue between interior and exterior environ-
ments. Interior to exterior transition spaces should be planned for and, again, a logic
check should be made to insure that these transitions make sense by viewing the
larger picture of an overall level layout. Interiors that change rapidly to unrelated ex-
teriors on a room-to-room basis usually don’t keep a player believing that they are
“within” a certain environmental setting for very long. If a player makes two close
exits from an interior to two unrelated exterior scenes (for example, from a prison
row exit to a jungle exterior through one door, and through another immediate door
into a desert setting), it may look cool, but it doesn’t support keeping a player’s belief
state suspended. We’re always striving to provide a player with a “continuous” feel-
ing or belief that they are where we’ve put them. A prison camp in the desert is a good
example. If you want both jungle and desert simultaneously, you need to think about
transition for the player.
Reinforcing Mood
Building mood supports and details your gameplay function ideas. The
previsualization sequence should attempt to “ask and answer” questions about how
a game will transfer mood to the player. Early concept drawings should deliver notes
and sketches that help define the mood. How will audio and visuals come together to
transfer mood? If you’re building a fantasy fighter based on a cartoon world, how
will you transfer mood? Location sets mood.
You want the mood to mirror the experience you’re trying to transfer. Sports games
or first-person shooters offer fast and frantic action, but the mood is reinforced by im-
mersion via visual and auditory cues. Relatively small touches can transfer plenty of
mood. For example, hearing an in-stadium broadcast announcer that sounds like a
true in-stadium announcer, such as you would hear while playing in a football sta-
dium, does much to transfer mood. Audio should never be neglected in game design,
although historically it has been. Our understanding of mood is greatly enhanced or di-
minished by the presence or absence of audio cues. Audio is fundamental to creating
and supporting mood. Audio is fundamental to designing a game world.
C H A P T E R 1 13
Previsualization
P APER-BASED LEVEL BLOCKING
Every map, level, arena—in short, every game environment—should still begin on
paper. There are a couple of reasons for this. First, it’s just plain easier to edit, update,
and try out ideas. Second, it can save large amounts of time and money spent on
wasted resources. You can play around with spacing, room flow, and the logic of the
level very easily. I’ve found that huge dry-erase whiteboards are very helpful. They
are great for team brainstorming sessions, from which useful notes and ideas can be
quickly gleaned. Paper-based level blocking is also great for discussing and making
quick changes to level flow ideas, boundaries, prop placement ideas, and segue areas
planned for your level.
Quick Topographic Maps
Yes, we live in a world of amazing editors and 3-D packages—each with its own sub-
tle and frustrating nuances—but many “concepts” can be tested faster and easier on
paper than by using any other medium. You can more easily identify flaws in logic,
build out transition spaces, and test your ideas, and really get a more solid grasp on
the global view for your level. Also, it’s important to start thinking modularly, which
means planning how to build up your level out of simple, adjoining, and reusable
components. It’s like building up a level with a toy construction kit out of several
pieces joined together in a meaningful way.
Okay, you have your graph paper, now what? Generally, you want a nice topo-
graphic or overview-style map. Figure 1-4 is an example of what a section of your
map might look like. I like to draw it out on paper or whiteboard, clean up the notes,
and build a quick and clean version using the Microsoft Visio software application.
The small level section illustrated in Figure 1-4 might be a cathedral area for part
of your level. The circles represent cathedral turrets or towers. The smaller circles are
simply columns. You can use a legend that identifies what each element on your top-
ographic map corresponds to, such as in this legend for Figure 1-4:
T Towers or turrets
C Columns
P Pews
O Pipe organ
OB Organ bench
A Altar
Now we have a basic positioning layout (not to scale, of course) and legend system.
Keep in mind that a topographic sample like this is only a reference point, a way to start
off on the often long road to a complete level. Now let’s take an introductory look at
how we begin to detail our level using textures, props, effects, and scripted events.
14 U L T I M A T E G A M E D E S I G N
Building Game Worlds
FIGURE 1-4
Topographic level map sample
Textures
Textures will be mapped or placed on our geometry constructions. Textures are sur-
face material information—colors or patterns, contrast and hue, but they also indi-
cate physical characteristics like bumpy, rusty, or stone-like, etc. Think of a texture
C H A P T E R 1 15
Previsualization
as the wrapper on a paint can. It covers the surface of the cylindrical paint can with
visual materials information.
We need to make a preliminary texture list for our cathedral example. A quick
look at the textures we might want for this area include the following:
Stained glass windows
Stone floor 1 and stone floor 2
Carpeted floor
Turret steps
Wall 1 and wall 2
Turret wall 1 and turret wall 2
Turret wall trim border
Door 1 and door 2
Altar covering
Organ covering
Organ bench
Wooden pews
Decorative columns
These should suffice as a first-pass listing. It’s important to think of these textures
in terms of how they support and define the visual look and feel you’re trying to cre-
ate or replicate. Make sure you have as much relevant reference material as you can
gather. “It’s bumpy” or “It’s rusty” is not entirely helpful. In what way is it bumpy?
What kind of rust? A visual reference is worth 1000 words. Be prepared to show your
texture artist photographic or illustrative samples. This is why the previsualization
phase, and the organization of this visual data, can be a helpful team time-saver.
Props
Props are 3-D models of objects that litter or populate a 3-D environment. Each of
the physical objects you find around you in an environment are potential props in our
created environments. Tables, chairs, phone booths, trashcans, and street lamps are
all examples of props. We need to model these and include them in our environments.
Again, this is where setting a visual style in a previsualization sequence is so impor-
tant. We’re not just making any street lamp; it has to be a street lamp that comple-
ments and supports the visual style we are working in or working for. A street lamp in
16 U L T I M A T E G A M E D E S I G N
Building Game Worlds
the Scooby Doo universe is different from a street lamp in the Blade Runner universe,
which is probably different from a street lamp in your universe.
So, what props might we want for our cathedral example? Some of the props are
already indicated on our map:
O Requires a pipe organ
A Requires an altar
P Requires wooden pews
We also have props that are used to scatter around the environment to add some
realism. Most cathedrals are not barren inside, so our first-pass listing of props might
also include:
Organ bench
Candelabras
Wall tapestries
Frozen beast statues 1 and 2 (two versions)
Our frozen beasts in this case are props that serve to tell a short backstory point on
our cathedral area. It has been frozen by a curse, and these poor unfortunate beasts
have been immortalized as frozen statues—unless maybe you break up the curse later.
Sound familiar?
Effects
Next, we want to consider some of the effects we’ll require for our cathedral exam-
ple. Yes, even the effects need to match up with the visual style that we are planning in
our previsualization phase. An effect like “steam” in The Simpsons world looks dif-
ferent from “steam” in the world of Minority Report. How is it handled? Typically, a
game engine like the Unreal2 or Doom III engines (built up on core code modules
like an input/output system, rendering and animation system, audio system, and
game loop/game logic system) handles effects (like ice spray off a hockey skate) as
sprite-based effects or as part of a built-in particle or dynamics system.
Although we’re still in our first-pass previsualization phase, we already know that
we’ll need some effects to visually detail our environment, such as the following:
Cold steam (rising from our frozen beasts)
Magical glow (surrounding our altar)
Candlelight fire (for our candelabras)
C H A P T E R 1 17
Previsualization
Effects add definite visual pop and excitement and help to tell us something about
our frozen beasts’ recent “confrontations.” These kinds of visual details can be han-
dled programmatically in a number of ways, but for previsualization purposes, we
need to think about which effects we must create and how the game engine we’re
working with will handle them.
Scripted Events
We’ve made some solid previsualization progress! We have our topographic map,
early texture and prop ideas, and effects breakdowns—and we’re cross-checking
them to our visual anchor point. This is why a flurry of conceptual drawing needs to
take place very early in the production cycle.
Now we have to consider scripted events. Scripted events are actions or behaviors
that we want to include in our environment to set up play possibilities, make story
points, elicit behavior from nonplayer characters (NPCs—like the talking castle gar-
goyle), and build up action.
For our cathedral example, we might want enemies to come crashing through the
roof once a player trips an action trigger on the floor. We might want the busting or
shooting of an altar icon to prompt a mini-attack by cathedral minions. We might
want a switch on the organ to reveal an area that is a hidden treasure trove. These are
all script-based actions. We’ll talk a lot more about scripting in future chapters (such
as Chapter 6). The important point here is that we need to consider scripting events in
the previsualization phase so that we can determine what additional art assets will be
required to support script ideas. Do the scripted events create extra character models,
props, or effects? Usually they do. To what degree will these scripted events require
additional resources? How are these resources connected to the visual reference
points established?
As previously stated, any previsualization work that you do up front can save time
and help to avoid confusion among developers all along the development path.
C ASE STUDY COMMENTS ON
PREVISUALIZATION
In 1996, a development team I worked with was asked to complete an action/RTS
(real-time strategy) title for the Sony PlayStation on a timeline of approximately 15
months. Production had to begin immediately on this licensed title, which was set in
an elaborate futuristic world. Licensed games, like Spongebob Squarepants or The
Scorpion King II, have to be built quickly because they often piggyback on a compan-
ion TV show or film that makes them known, popular, and attractive for purchase:
“You saw it! Now play it!” (or so the thinking goes).
In our case, no aggressive previsualization sequence could “seemingly” be com-
pleted due to the already aggressive development schedule. Our team settled the design
18 U L T I M A T E G A M E D E S I G N
Building Game Worlds
and production considerations as rapidly as possible, and proceeded to build the game.
As game engine details and technical factors evolved, so did the design. This is com-
mon. We had the opportunity to use established characters and to create new ones. We
were entirely responsible for environmental setting and execution. The world and
characters needed a consistent look. It is immediately obvious when “look” planning
fails. In our case, the look planning faltered. With the visual capabilities of consoles
and the PC today, the lack of a consistent look is entirely unacceptable.
Because we were prevented from completing even a condensed previsualization
phase, many details, despite our best efforts, were left hanging to be considered mid-
stream in the heat of development. This did indeed create a stall factor, which burns
valuable resources. When layers of approval phases are introduced, sometimes this
stall is close to inescapable. However, as game developers, you are always looking to
minimize this kind of development impact. One way to minimize the stall factor is to
use your best efforts to build a previsualization sequence into every development
schedule.
I NTERVIEW WITH ANDREW HOLDUN
Andrew Holdun is an extremely versatile and talented artist with a track record of making hit games
for developers like LucasArts, Disney, and THQ. His work can be seen in Jedi Knights for the PC and
Shadows of the Empire for the Nintendo 64. He received a B.A. in Architecture from Pratt Institute.
TM: Is getting ready for the game industry the same as preparing for a bullfight?
AH: I read a lot of Ernest Hemingway … and drank a lot of tequila. Before you knew it, I had a
cape and a hat with these stupid furry balls on it, and I was running for my life from a ton of mean
steam-snortin’ mammals.
TM: Nice. How is previsualization usually done? Is it important?
AH: I think that previsualization is becoming more and more important in all aspects of the
computer graphics area—from movies and TV to web and game development. In fact, I think that
it has trickled down from movies and TV commercials as a descendent of storyboarding.
While storyboarding has been accepted for a long time in those areas, it’s taken a while for that to
seep into games. As games have become more cinematic and more complicated, there has developed
a need to use devices like storyboarding to express what is happening—for both the creators and
producers of the content.
While I was at LucasArts, the majority of the artwork was conceptualizing what was going to go on
in the game … the character’s look … the appearance of the environment. A lot of the timing was in
the script of the game and worked out as a trial-by-error function. Not really previsualized or even
storyboarded that much. To be fair, I believe that there was not even a lot or any previz going on at
movie studios at the time.
Then with digital tools, people started to cut apart storyboards and have them become digital
visualizations of the action in the movie or commercial or game. As movie studios like Industrial Light
and Magic [ILM] started using previz more, they went from cut-up storyboards (animatics) to rough
3-D visualizations of the movie/commercial/video. The benefits are numerous.
C H A P T E R 1 19
Previsualization
Before committing large resources to the project, one can save a substantial amount of time and
money and also try out numerous avenues of story, and look before committing resources. With the
increase in production costs, this has become almost a standard in production rather than the rarity it
was just a few years ago.
This has all trickled down to games. As the costs, complexities, and cinematic quality of games
has increased, so has the acceptance of previz. In fact, it’s almost become a necessity with tighter
production cycles. Previz is usually done by going from script to storyboard and then converting
that storyboard to a 3-D re-creation. Characters can be rough geometric shapes as can be the
environment. The important thing is to create an understandable feel for what the project will be.
If you can make a rough previz exciting, then the rest (adding textures, higher quality models,
environments, lighting, audio) will just be the icing on the cake.
TM: What’s the best way to build up visual reference for environmental work?
AH: Photographs from the Web as well as from such great sources as National Geographic are
all my favorites. Also, it’s good to just troll the library and bookstores for interesting material, such as
the book Dead Tech: A Guide to the Archaeology of Tomorrow [Manfred Hamm, et. al].
The other key resource is a digital camera that you carry with you at all times. You never know
when you’ll see a grain silo or a rust-covered industrial tank that will just excite your imagination. One
should also always have a sketch book and pen handy…so you can draw what you see and play with
variations on a theme.
TM: What kinds of art skills relate to building successful 3-D environments?
AH: I started out as an architect, and so that has been a very good training ground for seeing the
environment around me in a more complete fashion. I think any training such as drawing, sculpture,
and photography are bedrock skills that give one the foundation for the creation of 3-D environments.
Also, just educating oneself visually by seeing movies of all types, but especially visually compelling
films like sci-fi and fantasy, and just religiously going to museums and theatrical presentations are all
important to help you create a 3-D visual vocabulary that you will use knowingly and sometimes
unknowingly in your work.
TM: How does traditional architecture relate to “digital” architecture?
AH: There is a great similarity, but traditional architecture is held back by the realities of client and
gravity. Digital architecture is unfettered by these things. A certain reality has to be present or else the
game can fall apart.
Gravity is an important thing to have working when you are developing a driving game, for
instance…but you can stretch a lot farther with digital and develop environments that just wouldn’t
be practical in the real world.
TM: How have you used your background in architecture for 3-D game work?
AH: I have used it to create city plans. Mos Eisley in Shadows of the Empire comes to mind.
And using the conventions of computer-aided design [CAD] that are pretty commonplace in
architecture … layers for different objects.
I’ve also used my architectural knowledge about how the shape of a space (a tunnel verses a room
with a high ceiling) can influence one unconsciously.
TM: How do you approach building architecture for game levels or arenas?
AH: First, I try to get a grasp of what the designer is going for in the game … what is the feel? Then it
becomes more like film set design. First, rough out the environments based on the script and the concept
