<< Back to Normal View
URL: http://www.loonygames.com/content/2.13/bent/
Vol.
2, Issue 13
February 25, 2000
Beaker's
Bent:
Making the Outdoors
(part 2)
by
Rich "Beaker"
Wyckoff
include("/home/loonygames/loony.timedoctor.org/includes/bent.htm");
?>
Welcome
back, after a long delay, to Beaker’s Bent. It’s been two months
since my last column, where I started to describe some of the
techniques I’ve built up over the years for making realistic outdoor
environments. Hopefully no aspiring designers of outdoor environments
have been forced into anything drastic out of frustration while
waiting for this new installment. At any rate, they can relax
now as I divulge some details about the geometry of outdoor environments.
Last time,
I discussed texturing and lighting, two aspects of an outdoor
level which actually supercede the geometry in importance. With
excellent textures and sparkling, sun-like lighting even very
simplistic geometry can capture some of the feeling of the outdoors.
Geometry
of an outdoor level is highly dependent on the engine involved.
Many outdoor-oriented engines use height-mapped terrain engines.
For the true neophytes out there or those who have never touched
anything beyond an FPS, a height-mapped engine uses a grid of
points of varying heights, with the geometry between those points
often out of the designer’s control. It is possible to programmatically
reduce detail in height-mapped terrain as it gets further away
from the player, which allows for extended viewing distances as
the furthers hills are rendered with the minimum number of polygons.
It is
also very easy to apply fractal algorithms to a grid of points
to quickly get mountains and valleys, and to make simple editing
tools that can raise or lower hills. However, this very ease
of use contributes to one of the most common problems with outdoor
geometry: what I call, until I can come up with a shorter description,
the “metal balls in a rubber sheet” look. In short, the most
simple fractal algorithms and editing tools, which are often all
that get put into a game editor for height mapped terrain, create
a generic and unnatural look to the terrain. Keep an eye out
for landscapes made of many hills and valleys of similar size
distinctive, bell-curve shape (as if metal balls had been pressed
up through or laid down on a rubber sheet). You’ll begin to notice
this effect in the most hastily assembled outdoor scenes, both
real time and pre-rendered.
There
are, indeed, some parts of the real world that look similar to
“rubber sheet world,” but the far more interesting parts of the
world (those which you would like to put in a game) have much
more variation than this. Achieving this kind of terrain requires
much more thought and hard work than merely applying fractal noise
and a smoothing routine to a grid of height points, and I’ll write
more about the technique in a moment. However, the very nature
of the height-mapped terrain engine also contributes to this.
The biggest
technical drawback to height-mapped terrain is that overhangs
or even completely vertical surfaces are impossible to create,
since none of the height points could possibly overlap another.
A secondary and related drawback is that it is difficult to reproduce
very fine detail, such as the branching run-off patterns that
you see on the sides of real hills, or the rounded banks of small
streams. Better height-mapped engines have variable-resolution
grids, which means that in areas which need high detail such as
stream banks or the foundation of a building, the spacing between
height points can be decreased. This also allows for near-vertical
slopes, but still not overhangs of course. The overhang issue
can be avoided by using objects cleverly placed on or in the terrain,
but it can be difficult to mask the transition between the terrain
and the overhang object itself.
On the
other hand, making terrain in engines intended for indoor use
such as Unreal and Quake III have far fewer geometry limitations,
but bring with them the huge problem of visible polygons. With
no ability to detail-reduce distant terrain, outdoor levels in
indoor engines must constantly take liberties with reality in
order to keep the number of on-screen polygons down as much as
possible. As a counterpart to the “marbles in rubber” look of
badly-done height mapped outdoors, outdoor FPS levels often have
the “maze of canyons” look.
Finally,
of course, and this is a problem that not even Trespasser solved
very well, despite our best attempts, is the issue of object density.
Sometime, probably before too long, either raw polygon-pushing
power or a breakthrough algorithm will permit the thousands of
trees and bushes that will enable outdoor levels which look like
something other than bare, rocky wastelands that just happen to
be painted in vegetation-like colors. For the time being, however,
there is a tricky balancing act involved in object placement which
many outdoor level designers seem to avoid altogether, going instead
for the “one tree every quarter mile” approach.
Now, I’ve
listed out the problems with making outdoor terrain, but just
knowing what to avoid or work around is not the best way to approach
the difficult task of making an outdoor level. Much of the technique
of making an outdoor level can only be gained through experience,
a belief that nothing is impossible, and an unwillingness to accept
the status quo of outdoor level design. However, I will try to
condense some of my own experiences into a few paragraphs of positive
advice.
The most
important recommendation I can give is to learn a professional
3D modelling package such as 3D Studio MAX and learn how to use
it with the engine of your choice. Internally created editors,
especially those created to make simplistic, indoor shooters,
are becoming increasingly unfit for creating the complex, sprawling,
organic geometry that today’s 3D cards and consoles are actually
able to create. Many companies are actually beginning to move
all their geometry creation, world geometry in addition to object
and character geometry, over to professional modelling packages,
and using their game editor for gameplay editing only, such as
placing objects and enemies and creating triggers for game logic.
Using
a 3D modelling program requires a much stronger knowledge of the
technology behind today’s games than the average level designer
brought up in FPS editors may be used to. MAX and programs like
it allow users to screw around with geometry to its lowest level,
right down to removing or adding in vertices and faces, and designers
using it for game creation must be acutely aware of what constitutes
good and bad geometry for their particular game.
The engines
I’ve worked with tend to go crazy if geometry has any gaps in
it (a missing face – picture a cube with one side gone). Poly-count
has also been a critical issue and removing verts and faces and
then rebuilding the mesh is a very easy way to get into trouble
and accidentally create bad geometry. I tend to start with the
simplest shapes possible and slowly add detail by splitting edges
and tessellating faces minimally. As high poly-counts and curves
become a part of more engines, however, it will probably become
necessary to work with geometry primitives in your modelling package,
and apply modifiers to them, rather than hand-editing their geometry
at the lowest-level.
Once you
are comfortable with the advanced level of editing available in
a package like MAX, I recommend getting your hands as messy as possible
with your main terrain geometry. Don’t rely on a fractal seed to
generate your whole level – instead refer to directly to real-world
terrain as much as possible, through photographs, drawings, and
personal visits to geographically interesting areas. We had some
success on Trespasser by starting with a large clay model of the
entire island locale of the game, sculpted by our lead artist and
then laser-scanned. Although much of the detail of the sculpture
was lost once the scanned mesh was reduced to usable polycounts,
it at least gave us a set of existing and fairly believable natural
features to work around. This gave some much-needed direction to
the design process (both visual and gameplay – the topic of the
next installment).
I cannot
recommend highly enough studying as much real-world geometry as
possible. Real terrain slopes and rolls in ways that simply will
not occur to most level designers working with no reference. After
you work on outdoor levels while studying the real world for a few
years, you may find yourself getting fascinated and excited by seemingly
simple things like how a rock face and the side of a hill connect.
When you start to become wistful about natural features that you
can’t reproduce well enough with today’s technology, you’ll really
be able to call yourself an outdoor level designer.
My words
of advice, which may become fairly irrelevant over the next year
or two, are for people making outdoor levels in indoor engines.
The key to a realistic outdoor area really is the long vista. To
avoid feeling like you are in a bowl or a maze of canyons, there
must be spots within a level where the player feels like they can
see all the way to the horizon, or can look out across other parts
of the level. Creating a vista that doesn’t drag the framerate
down requires careful planning however.
One approach
is to use fakery – create a very low detail area, such as a distant
river valley, perhaps which the player can not otherwise reach,
and allow them to see into it from selected points on the player’s
path. Use geometry for the vista, however, because a mere painting
of a distant river valley will almost inevitably be at the wrong
resolution, and will seem obviously flat. For this reason, in fact,
geometry in a skybox in Unreal, for instance, is not ideal, because
the camera into the skybox is fixed, which almost eliminates a feeling
or perspective, although you will get a good parallax effect between
your skybox contents and your in-level geometry.
If you do
not use fake forced-perspective vistas, then you need to be extremely
careful what parts of the level you allow the player to look across.
Conceal as many high-detail areas as possible – your staircases
(natural or human-made), cave/building entrances, platforms for
jumping puzzles, etc. If you know exactly the angles your player
will look across the level, you can use mid-sized hills to block
off the complicated stuff and they’ll even add interest to the area.
If you construct them carefully to be as small as possible, they
won’t seem like canyon walls when the player walks past their base,
even though they are serving the same purpose.
Finally,
know your engine’s strengths and limitations. Some indoor engines
just cannot handle large levels with lots of geometry and actors
and textures even if you can never see them. You may want to create
a single, large base terrain for your entire level, and split it
up into a variety of smaller actual levels, connected by tunnels
and tight canyons where you can put loading points. If you allow
the player to look across a location that is technically in another
level, just ensure that its major features (textures, trees) are
identical or at least very similar to the ones the player passed
through from ground level. This will maintain the player’s belief
that they are passing through one continuous space, even though
they are passing through load points.
There is
much, much more to say about geometry building in the outdoors,
but hopefully what I’ve covered so far is enough to get beginners
started and give experienced outdoor level designers some inspiration
and ideas to consider. Perhaps someday in the future when I’ve
managed to work on an outdoor game which is neither cancelled nor
a failure, I can return to the topic in some other forum besides
Beaker’s Bent, but it’s time to take this column back towards its
more-standard topic, game design.
So next
column, in the final installment of Making the Outdoors, I’ll be
tackling the big, hairy issue of design in realistic outdoor spaces.
There will hopefully be no two-month delay this time!
- Richard
Beaker Wyckoff is a game designer, not a level designer,
damnit
<<Back to Normal View
loonygames
- the best damn gaming magazine online
|
Credits: Print CGI is
© 2000 Square Eight. Used with permission.
Article is © 2000 its original author. All other content is © 2000
loonyboi productions. Unauthorized reproduction is prohibited. You got that??