a blue's news publication

<< 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

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??