october 1999twvideo01.ubm-us.net/o1/vault/gd_mag_archives/gdm... · sumer 3d chips, such as...

OCTOBER 1999

G A M E D E V E L O P E R M A G A Z I N E

T his heard at a Siggraph panel:“Consumer graphics cards intwo years will be more power-ful than any graphics card

available today at any price.” That’squite a bold prediction, but I agree.Graphics hardware has entered a phe-nomenal technological growth spurt,thanks in part to the demands oftoday’s games. The latest crop of con-sumer 3D chips, such as Nvidia’sGeForce 256 (formerly known as NV10),boasts features that were found exclu-sively on high-end workstation cardsonly a year ago. Consequently, the linedividing “consumer” and “workstation”class cards gets fuzzier each passing day.

The scary aspect to the aforemen-tioned prediction is that, if it pans out,we’ve got a lot of work ahead of us if wehope to maximize the capabilities ofthat hardware. Or, to put it anotherway, where are those hundreds of mil-lions of triangles being drawn on screeneach second going to come from? It’sapparent that game developers areincreasingly playing catch-up withhardware. Without changing the waythings currently work, we risk wideningthe gap between what hardware (bothPC and console) supports and whatgames actually deliver. To narrow thatgap, several things need to happen.

First, we need more specialized tools.Many SDKs currently categorized as“middleware,” such as physics and 3Danimation engines, are often expensiveto license and don’t appear to integrateeasily into already-underway projects.Perhaps this will change over time asmore commercial SDKs hit the market,causing prices to fall and developers tobecome better acquainted with usingcomprehensive off-the-shelf librariesfor adding complex functionality intogames. But the types of products that Ithink will make the most impact ongame development will be highlyfocused — those that sacrifice broadfeature sets in favor of super-specificfunctionality (for example, a trackingcamera system for TOMB RAIDER clones,or a flexible terrain editor/generator)and reduced price (what I call “Smacker

pricing” — $5,000 or less per product,no royalties). These will be inexpensivetools that even junior developers canlearn in a few weeks, and which can beintegrated into a game quickly. Wherewill we get these dream tools? Thatbrings me to my second point.

At Siggraph, it was evident that thegraphics research community desirescloser ties to the game developmentindustry. The problem is, researchersdon’t know how to build those relation-ships with us, how to identify whataspects of their research we might finduseful, and how to craft licensingschemes we’d find attractive. So in orderfor our commercial interests to beserved, it looks like it’s up to us to buildthose relationships. How many peopleon your team regularly investigate tech-nologies that are still in the labs? Itmight be worth your while to pick upthe Siggraph proceedings each year, seewhat’s been presented, and make licens-ing offers to the appropriate researcherswhen bits of technology look useful.Bridging the gap between the publicand private sector could give developersaccess to reasonably priced, highly spe-cialized software tools for maximizingthe horsepower of graphics hardware.

Finally, we can’t be afraid to take riskswith technology. Gambling on thecapabilities of future graphics hardwareseems to be one of the safest decisionsyou can make today. In this month’sPostmortem of DESCENT 3, for instance,Jason Leighton and Craig Derrick dis-cuss the reluctance they felt when earlyin the project they decided to build agraphics engine that required 3D hard-ware acceleration. Of course, any AAAgame aiming for the high end of themarket today takes 3D acceleration forgranted, but surely there are technolo-gies today which look just as risky ashardware-accelerated 3D did in back1996. With better tools and market fore-sight, the likelihood of a long deathmarch to get your game out will bereduced substantially. ■

G A M E D E V E L O P E R O C T O B E R 1 9 9 9

4

P L A NG A M E

Graphics Fly...

Will Developers Fry?

D E V E L O P E R

ON THE FRONT LINE OF GAME INNOVATION

www.gdmag.com

600 Harrison Street, San Francisco, CA 94107t: 415.905.2200 f: 415.905.2228 w: www.gdmag.com

PublisherCynthia A. Blair [email protected]

EDITORIAL

Editorial DirectorAlex Dunne [email protected]

Managing EditorKimberley Van Hooser [email protected]

Departments EditorJennifer Olsen [email protected]

Art DirectorLaura Pool [email protected]

Editor-At-LargeChris Hecker [email protected]

Contributing EditorsJeff Lander [email protected] Steed [email protected] Rahmat [email protected]

Advisory BoardHal Barwood LucasArtsNoah Falstein The InspiracyBrian Hook Verant InteractiveSusan Lee-Merrow Lucas LearningMark Miller HarmonixDan Teven Teven ConsultingRob Wyatt DreamWorks Interactive

ADVERTISING SALES

Western Regional Sales ManagerJennifer Orvik e: [email protected] t: 415.905.2156

Eastern Regional Sales Manager/RecruitmentAyrien Houchin e: [email protected] t: 415.905.2788

International Sales RepresentativeBreakout Marketing e: [email protected]: +49 431 801703 f:+49 431 801797

ADVERTISING PRODUCTION

Senior Vice President/Production Andrew A. Mickus

Advertising Production Coordinator Dave Perrotti

Reprints Stella Valdez t: 916.983.6971

MILLER FREEMAN GAME GROUP MARKETING

Marketing Director Gabe Zichermann

MarCom Manager Susan McDonald

Junior MarCom Project Manager Beena Jacob

CIRCULATION

Vice President/Circulation Jerry M. Okabe

Assistant Circulation Director Sara DeCarlo

Circulation Manager Stephanie Blake

Assistant Circulation Manager Craig Diamantine

Circulation Assistant Kausha Jackson-Crain

Newsstand Analyst Joyce Gorsuch

INTERNATIONAL LICENSING INFORMATION

Robert J. Abramson and Associates Inc.t: 914.723.4700 f: 914.723.4722e: [email protected]

CEO/Miller Freeman Global Tony TillinChairman/Miller Freeman Inc. Marshall W. FreemanPresident & CEO Donald A. PazourCFO Ed PinedoExecutive Vice Presidents Darrell Denny, Galen A. Poss, Regina Starr RidleySr. Vice Presidents Annie Feldman, Howard I. Hauben,Wini D. Ragus, John Pearson, Andrew A. MickusSr. Vice President/Development Solutions Group KoAnn VikörenGroup President/Division SF1 Regina Ridley

Playing the Political Game

R eading Herr Kreimeier’s chillingvision of game censorship in

Germany (“Killing Games: Violence vs.Censorship,” Soapbox, August 1999)has forced me to briefly divert my atten-tion from developing games to worryingabout the future of the game industry.The thought that in a few years I mightnot be able to develop or play gameswhere things “blow up good” is not onethat I am happy about. I have no prob-lem with rating systems, but the sup-pression and confiscation of gamesbased on their content reminds me toomuch of book burning.

When I’ve taken time to consider theissue (rarely), I’ve always thought of the“anti-violence in videogames” politi-cians as grand-standers using theirnutty ideas to win votes from Ma andPa Bible Belt. I always figured they’dhave zero chance of actually gettinganything passed. However, knowingwhat has been done in Germanyand seeing the rise to dominanceof mass media publishers whowould probably just roll overand accept any such changes, Inow believe that I shouldinvolve myself in this issue.

Unfortunately, like most of my col-leagues, I have only a very smallamount of time to devote to a crusade.My game’s got to ship by Christmas,right? I vaguely remember a game lobbygroup that was formed a few years agoto combat this type of censorship, and Iplan to get involved in such a group.

I’d like to thank Game Developer andBernd Kreimeier for bringing the possi-ble outcome of goofy anti-videogamelegislation to my attention. They’lltake away my fighting games whenthey pry the game-pad from my colddead hands.

L e e W a g g o n e r , P r e s i d e n t / C E O

W r e c k i n g B a l l S o f t w a r e I n c .

v i a e - m a i l

Get out of the Conference Room

Idon’t agree with Doug Church’sproposal that our industry needs a

lexicon in order for design to go for-ward (“Formal Abstract Design Tools,”

August 1999). Languages are not creat-ed by committee, they are formed outof necessity. The movie term “zoom-indolly-back” was not created because abunch of directors decided that theyneeded to create terms for all the dif-ferent shots they did. More likely thannot, some director said “O.K., in thisscene I want the camera to zoom inwhile we move the dolly away fromthe scene,” and when they shot thescene he probably said, “O.K., nowzoom in and move the dolly back!”and of course thephrase got shorterand eventuallycaught onwith otherdirectors —this is howlanguage devel-ops. The reasonthere are so many

terms forthings in the techni-

cal side of games isbecause they are

needed. Itis formed

along withthe technology

because it necessar-ily cannot be described

in any other way.Not only can we not create a

lexicon via committee, I also believethat it is not necessary. Any designerwho’s worth what he’s paid will beable to sit down, play a game, andthen tell you why he’s still playing it20 hours later. If you can’t figure outwhat makes a game fun or addictingthen you are probably doomed tomaking boring games unless you justget lucky. I don’t think this industry isrun by a bunch of lucky designers — Ithink most of us know what we aredoing. Design does not evolve in thesame way as technology because it isabstract; it is an art. Technologyevolves as fast as we can push it, butyou cannot push art. It will evolve atits own pace and all attempts to pushit ahead of its time will most likelyend in failure.

Designing games is an art, and artcannot be defined so easily by a few jar-gon-like terms — that is for technologyand other less abstract concepts. Youcannot force jargon into existence — itis formed out of necessity, and I for one

do not believe there to be a necessityhere as of yet. Art evolves in canvas, notin conference rooms.

A d a m H e i n e

v i a e - m a i l

A U T H O R D O U G C H U R C H R E S P O N D S :

“Lexicon” is Game Developer’s word, “Jar-

gon” is your word. “Tools” was my word.

The underlying tool idea and specific

tools discussed in the article have evolved

through use. During development of

UNDERWORLD 1 and 2, we talked about our

goal to “immerse” the player. On

SYSTEM SHOCK 1, we discussed

more seriously what tools we

had to work with. As I stated

in my talk on Intention at

the 1997 CGDC, SHOCK had

no conversation mode

because we felt that UW con-

versations had little player inten-

tion, especially compared to the 3D

world. This isn’t a judgement of conversa-

tion, but rather a statement about what

tools fit our game design vision. Tools are

used to shape games. We continue to try

and understand the tools we use and how

they work.

As I see it, “usage” has been happening

for years, the GDC talks and this article are

“exposure,” and we’ll see if the tools idea

catches on. Step 2, right? I didn’t sit around

in a conference room trying to figure out a

topic for a Game Developer article. I’m a

game designer trying to share ideas several

teams have actually used in attempting to

implement a game play vision.

I strongly disagree that design is a myste-

rious, unanalyzable “art.” Of course vision

and aesthetics are involved, but they are

part of technology or books, too. Stating

design is not rationally understandable,

unlike those other “simple” things, feels

lazy to me. As a game designer, I should

learn to design games, right?

Some people have interpreted my advo-

cacy of identification, analysis, and under-

standing of design tools as an attack on

designers. That was not my point. Nor was I

saying people who don’t use big words are

losers, pedantic analysis is game design, or

that tools encapsulate all. Certainly, you can

dismiss design analysis as pointless or

attack it as wrong. However, I believe the

tools idea and the process of developing it

has helped us focus game play and better

achieve our vision in titles I worked on.

Therefore, refinement of that understanding

will continue to bring benefit. That is the

spirit in which the article was written.

h t t p : / / w w w . g d m a g . c o m O C T O B E R 1 9 9 9 G A M E D E V E L O P E R

7

S A Y S Y O U

k

We’ll lend you an ear. E-mail us at [email protected]. Or write to

Game Developer, 600 Harrison Street,San Francisco, CA 94107.

h t t p : / / w w w. g d m a g . c o m O C T O B E R 1 9 9 9 G A M E D E V E L O P E R

New Productsby Jennifer Olsen

If You Build It, Will They Come?

ALIAS|WAVEFRONT is still busy wooinggame developers, and their latest sere-nade is in the form of Maya Builder,designed to streamline level design forgame designers and 3D programmers,while allowing easy integration withother Maya features they’re alreadyusing.

Builder includes features fromMaya’s suite of polygonal tools,including Artisan, prelighting, UVediting, and nonlinear deformers. Itsbasic animation capabilities, whichcan animate objects such as draw-bridges or cranes, support Maya’s stan-dard keyframe-style tools and IKsolvers (with source code, so program-mers can deploy behaviors easily ontheir end platforms). Maya’s Embed-ded Language (MEL) lets programmerscustomize Builder with level editingtools specific to their engines, while

the Maya API offers access to Maya’sinternal data structures for creatingcustom translators and plug-ins.

Maya Builder will be available forIRIX and Windows NT, and is expectedto have a retail price of $2,995. It willbe included in the upcoming release ofMaya 2.5 later this fall.■ Alias|Wavefront

Toronto, Ontario, Canada

(416) 362-9181

http://www.aliaswavefront.com

Riding the Next Big ‘Wave

NEWTEK unveiled Lightwave 6, thenext generation of its modeling andanimation software, at Siggraph thispast August. Newtek claims this partic-ular release is their most significantupgrade of the past ten years. Nolonger content with red-headed-stepchild status among character ani-mation systems, the new Lightwaveoffers several enhancements tailoredspecifically to game developers.

Version 6 introduces a family of char-acter animation tools called Intelligenti-ties, which consist of Skelegons, Endo-

morphs, andMulti-meshes. Skele-gons are polygonsthat appear like reg-ular 3D bones, sothat any changesmade to the charac-ter automaticallyupdate the skeletonas well. Endomorphsare designed to helpwith complex mor-phing tasks (such asfacial animation),allowing changes ofexpression, mood, oractions by training asingle model. Multi-meshes, as the nameimplies, embed mul-tiple layers of geom-

etry into a single object, aiding in themanagement of complex hierarchies.

Also notable are the new renderingtechnologies offered (including souped-up Hypervoxels) and a new hybridInverse/Forward Kinematics engine. Inaddition, Newtek has overhauled itscurve editor, offering multiple-tangenttypes such as Bézier and Hermite curves,which it hopes will improve control ofmotion curves, resulting in better real-ism in character animations.

Lightwave 6 runs on Macintosh,Alpha, IRIX, and Windows NT systems,and carries a suggested retail price of$2,495. Registered 5.6 users canupgrade for $495.■ Newtek

San Antonio, Tex.

(210) 370-8000

http://www.newtek.com

Not Your Father’s 3D API

GLOBAL MAJIC SOFTWARE recentlylaunched 3DLinx, a new 3D develop-ment environment for Windows incor-porating a variety of languages, includ-ing Visual Basic, Delphi, C++ Builder,and others.

Traditional 3D APIs can have longlearning curves, depending on the skillsand experience of the programmersusing them. Global Majic has attemptedto simplify many complex tasks such asscene graph management, view culling,and collision detection, to offer 3D pro-gramming to a wider audience.

The Standard Edition of 3DLinx,priced at $895, is geared toward quickcreation of 3D applications, while theProfessional Edition, for $2,495,includes additional loaders for import-ing different file formats. An SDK willalso be available for third-party develop-ment of custom features and add-ons.■ Global Majic Software

Huntsville, Ala.

(256) 922-0222

http://www.3dlinx.com

New Products: Alias|Wavefront andNewtek vie for the adoration of gamedevelopers with new offerings, andGlobal Majic debuts 3DLinx. p. 9

Industry Watch: Non-sightings atSiggraph, the latest from the onlinepiracy battlefront, and Stolar says sayonara to Sega. p. 10

Product Review: Jonathan Blowtakes NDL’s NetImmerse engine for aspin and weighs in on the big build-or-buy question. p. 12News from the World of Game Development

9

Maya Builder will be one of the new features of Maya 2.5,

offering new tools specifically for level design.

B I T B L A S T S - I N D U S T R Y W A T C H

Industry Watchby Alex Dunne

and Dan Huebner

NOT SEEN ON THE SCENE. At Siggraph,the usual suspects such as SGI, Dis-creet, Alias|Wavefront, and others hadlarge booths on the floor, but twocompanies were conspicuously absentfrom the exhibition: Microsoft andApple. Rumor has it that Apple won’tattend tradeshows where it can’t havethe largest booth, so perhaps its excusewas that it couldn’t compete withSGI’s dueling 60×60-foot booths at theshow entrance. But what was Micro-soft’s excuse? Microsoft Research,which employs some of the mostrespected graphics experts in theindustry (Glassner, Blinn, Hoppe,Whitted, and on and on), had a num-ber of people speaking at the confer-ence, but one wonders why the biggestcomputer graphics event of the yearwasn’t on the company’s radar.

STOLAR AND SEGA PART WAYS. Berniehas left the house. The question is,why? As the president and COO ofSega of America, Bernie Stolar wasinstrumental in shaping the Dream-cast launch, but Sega hasn’t revealedany details about the split. As you

might imagine,morale aroundSOA wasn’t terri-bly high when itwas announced,but it’s hoped thatToshiro Kesuka —Stolar’s replace-ment as vice-chairman andCOO — will keepthe ship afloatthrough this criti-cal time for thecompany.

VOULEZ VOUS MIDWAY GAMES? Mid-way regained the rights to distributeits games in international marketsafter reaching a settlement with GTInteractive. Midway, which had filed asecurities lawsuit against GT Interac-tive, must pay GT an undisclosedsum, and will distribute its gamesinternationally from now on. Midwaycan now directly realize the revenues

and profits from such worldwide sales,which wasn’t the case under its previ-ous agreement with GT. Under theterms of the terminated distributionarrangement with GT Interactive,Midway did not participate in the rev-enue and profits generated by sales ofits home videogames in internationalterritories until certain nonrefundableadvances were recouped by GTInteractive.

ESRB O.K.’S PERMISSION SLIPS. Somegame web sites now have something incommon with elementary school fieldtrips: parental permission slips. TheEntertainment Software Ratings Boardgranted its first certification in a pro-gram that requires children under theage of 13 to have a “permission slip”signed by their parents before they willbe allowed to participate in any web-based activities. Electronic Arts is thefirst company to implement the sys-tem, called ESRB Privacy Online.Youths aged 13 to 17 registering at anElectronic Arts site will have a noticeof their registration mailed to a parent,who then has the option of removingtheir child’s name. Those younger than13 will be directed to print a permis-sion slip to be signed by a parent andreturned to EA. The program is notdesigned to protect children fromobjectionable content online, butrather is geared towards regulating thecollection, use, and safeguarding ofcustomer information.

TAKING ON VIRTUAL SWASHBUCKLERS.The Interactive Digital SoftwareAssociation (IDSA), along with sixmember companies, filed a lawsuit inNorthern California against six onlinepirates located within the United

States. The IDSA alleges that thedefendants posted pre-productioncopies of PC and videogames on theInternet. Named as defendants werethe leaders of the Class, Paradigm,and Razor 1911 hacking groups, oper-ating in San Francisco, Dallas, Austin,Minneapolis, the Philadelphia area,and the Champaign, Illinois, area.Acclaim, Accolade/Infogrames,Bethesda Softworks, Interplay, Lucas-Arts, and 3DO are also plaintiffs inthe case. The lawsuit charges that thedefendants engaged in copyright andtrademark piracy, racketeering (includ-ing mail fraud, wire fraud, and inter-state transportation of stolen proper-ty), counterfeiting, and unfaircompetition. The IDSA gathered evi-dence in the case by monitoring thegroups for several months, trackingtheir private chat sessions and mes-sage postings. It’s the first case everfiled against actual named members ofany piracy group. ■

G A M E D E V E L O P E R O C T O B E R 1 9 9 9 h t t p : / / w w w. g d m a g . c o m

10

Digital Video Conference and Expo

LONG BEACH CONVENTION CENTER

Long Beach, Calif.October 19–22, 1999Cost: variablehttp://www.dvexpo.com

Game Developers Conference 1999 RoadTrips

OGDEN ECCLES CONFERENCE

CENTER

Salt Lake City, UtahNovember 1, 1999

THOMPSON CONFERENCE CENTER

AT THE UNIVERSITY OF TEXAS

Austin, Tex.November 3, 1999

Cost: $120 ea. (discounts available)http://roadtrips.gdconf.com

UPCOMING EVENTS

CALENDAR

Bernie Stolar

helped shape

the U.S. Dream-

cast launch.

If titles such as READY 2 RUMBLE are a

hit overseas, Midway won’t have to

share the prize money with anyone.

B I T B L A S T S - P R O D U C T R E V I E W


12

NDL’sNetImmerse 2.3

by Jonathan Blow

N etImmerse is a software devel-opment kit for 3D graphicsand animation. It is a scene

graph API, meaning that objects inyour 3D world are stored in a hierarchi-cal tree. The graphics engine then ren-ders your scene by traversing the tree.

You make things happen in theworld by tweaking the attributes ofobjects in the tree. If you transform anobject (rotate it, move it, or scale it),all of its children (nodes below thatobject in the tree) will be transformedas well. To make an object movethrough space, you can either modifyits position manually from frame toframe, or you can attach animationcurves to its attributes; the object willfollow the path of motion described bythe curves.

The nodes in the tree can be simplegeometry objects such as textured tri-angle meshes; they can be more com-plex geometry objects, like curvedobjects made from Bézier patches orheight-mapped landscapes; or, theycan be completely new objects thatyou define yourself.

NetImmerse’s name can be mislead-ing; it sounds as if it’s a networkingAPI, but it’s not. There are a few fea-tures of NetImmerse that can be usedin conjunction with networking (suchas the ability to asynchronously loadgeometry and animations into a run-ning scene, or fetching an image file

from a given URL), but this is nowherenear its central point.

NetImmerse provides componentsthat include the following technicalfeatures:

• A terrain rendering system withview-dependent detail reduction,based on Peter Lindstrom’s algo-rithm from the 1996 Siggraph pro-ceedings. (This algorithm has beenpopular with game developers cre-ating their own terrain systems.)

• View-independent detail reductionfor triangle meshes. This appearsvery similar to Hugues Hoppe’s pro-gressive mesh algorithm, which isincluded with DirectX. I find thatNetImmerse’s version is nicer andeasier to use.

• A portal system, for culling hiddengeometry in indoor environments.

• A collision detection system thatuses trees of oriented boundingboxes (the OBB-Tree algorithmdeveloped by Gottschalk) and someother simple bounding primitivessuch as spheres, extruded spheres,and extruded ellipses.

• A system for dynamic tessellation ofcurved objects built from Bézierpatches.

• A shape animation system thatincludes morphing, skinning, gen-eral path control, and particle sys-tem support.

• A multitexturing texture systemwith a cache manager.

• A 3D sound API that uses AurealSemiconductor’s A3D 2.0 as itsback end.

• A rendering manager that can useGlide, Direct3D, or OpenGL as itsback end.

QUALITY OF TECHNOLOGIES. So Net-Immerse provides all these features.But how good are they, actually? Theanswer is, pretty darn good for a gener-alized API.

The source code for the NetImmerseinternals is clean. Each of the modulesis a competent implementation of thetargeted technology, written to be asgenerally useful as possible while stillbeing efficient and easy to modify.

However, none of the modules is asgood as what you’d get if you told anexperienced 3D programmer to createthat functionality for one specific

game. For example, the NetImmerseterrain module does not providesmoothly interpolating terrain vertices(you see “popping” effects) and is notstructured for landscapes that havevery high texture densities. It is alsonot very memory efficient compared towhat you could create if you knewexactly what terrain size and resolutionyou wanted and implemented theLindstrom algorithm by hand. So ifyou are developing a game to competewith STARSIEGE TRIBES 2, and you wantyour terrain to be superior, you’regoing to have to write your own.

Similar statements can be madeabout every component of NetImmerse.Though the collision detection systemsare quite intelligently coded with a lotof care given to speeding up the specialcases between different types of primi-tives, they don’t report accurate enoughcollision points or times to be used for“real” physical simulation. The portalsystem doesn’t perform optimally forsome geometry types, which may bethe ones you want to use in your game.And so on.

These observations can’t really betaken as criticisms of NetImmerse,however. These are the same problemsthat come up any time you use a gen-eralized system to perform a specifictask. Because the system is attemptingto solve a harder problem than whatyou’re using it for, it will not be as effi-cient as something that is tailored toyour specific needs.

NetImmerse is designed for modular-ity. So if you need a terrain system thatis more memory-efficient and thatsmoothly interpolates vertices, you canwrite it yourself and stick it into thescene graph, and it will work. But ifyou’re pushing the cutting edge of per-formance, there’s a limit to how effec-tive this will be; at some point youhave to re-architect the game enginearound your core features, and thiswould require throwing away most ofthe structure that NetImmerse givesyou, or using it in an ancillary way. ASSET CREATION. NetImmerse does notprovide a content creation tool for 3Dgeometry and animation; the paradigmis that you should use the commercialauthoring tool that works best for you,then export the data for use withNetImmerse. NetImmerse providesexporters for 3D Studio Max 2.x,Softimage 3.8, Multigen Creator, and

Jonathan Blow is the guy who receives e-mail sent to [email protected].

B I T B L A S T S - P R O D U C T R E V I E W


14

Motion Factory’s Motivate.NetImmerse can load textures from

.TGA or .BMP files and from files con-sisting directly of RGB 3-byte values orRGBA 4-byte values. It can also parsetextures out of its own file format, .NIF.The NetImmerse file format is a pack-age format that can contain any of theNetImmerse data types; you get one ofthese when you export a scene, orwhen you use API calls to save a scenethat you have created in memory. DOCUMENTATION AND SAMPLE CODE. Thesystem is fully documented and thedocuments are provided in two fileformats: .PDF and Word 97 .DOC. Thedocumentation is of high quality; infact, it’s the best documentation Ihave ever seen for a game-related SDK,by a wide margin. The first piece ofdocumentation is a 26-page program-ming manual that provides anoverview of the entire system; afterreading it, anyone who has ever useda scene graph API will be able to sitdown and begin coding. Anyone whohas not will want to proceed to thenext piece of documentation, thetutorial, which is a walkthrough ofevery sample program provided withthe SDK.

There are 15 different sample pro-grams, and the documentation does aterrific job of explaining them. Thinkof a good programming book that youwould buy for $70 in a bookstore,wherein the author creates programsand guides you through their logic onesection at a time. That’s what you getin the tutorial (all 116 pages of it).

If you’re in a rush and want to skip

the tutorial, that’sO.K. too. The samplesource code is cleanand easy to read onits own. There is not atrace of platform-spe-cific code in the sam-ples, which is nice fortwo reasons. First, itshows that the under-lying architecture isclean and complete,without falling backon Windows for somefunctionality or allow-ing Windows datastructures to infiltratethe API calls. Second,it makes the codepleasant and easy tounderstand (because it’s not filled withthe nasty type definitions and unread-able naming conventions common inMicrosoft APIs).

The rest of the documentationdescribes NetImmerse’s major techno-logical components (the portal sys-tem, detail reduction system, and soon). These files use diagrams todescribe the operation of each compo-nent; they also give guidelines on theoptimal, proper, and improper uses ofeach component.HOW IT STACKS UP AGAINST COMPETITION.

Anyone who is considering licensing atoolkit like NetImmerse will, naturally,consider other options as well. Ofcourse one can license a tool that com-petes with NetImmerse and providesfunctionality in roughly the samearena; since this is not a review of the

whole marketplace,we won’t touch onthose here. However,we will discuss twoimportant alterna-tives, in terms oftheir scale of func-tionality, to putNetImmerse into per-spective.

First, you might optto license the enginefrom an existing 3Dgame that you like,such as UNREAL orQUAKE 3. On theminus side, thisoption will cost you alot more than a toollike NetImmerse.

However, what you get with, say, theQUAKE 3 engine, is an already-assembledgame that you can modify until itbecomes what you want. If the originalgame is technologically similar to thegame you want to develop, then youwon’t need to spend too much engi-neering effort to get your game into abasic running state. Instead, you canspend all your effort on refining yourgame, which hopefully means it is ofhigher quality in the end. NetImmerseprovides a lot of features, but it is not agame or a game engine. You will stillneed to do a lot of work to put thepieces together in the right way, and toprovide the pieces of core functionalityneeded to make your game run.

A second alternative might be to useFahrenheit, the codename for theupcoming version of Direct3D, whichreportedly will contain its own scenegraph API. (Fahrenheit specifications arenot yet available for public perusal.) Thestructure of Fahrenheit should be simi-lar to NetImmerse in many ways, andFahrenheit will most likely be free forgeneral use, as with previous versions ofDirect3D. So why would you opt to useNetImmerse, which will cost you? First,Direct3D has a history of not living upto its promises, so expect Fahrenheit todisappoint and/or annoy programmersfor a while after its initial release. Also,it is quite unlikely that Fahrenheit willbe ported to any non-Windows operat-ing systems, so if your game relies on it,you will be tied to Windows. And youcan bet that you won’t get Fahrenheitsource code, so NetImmerse will be easi-er to adapt to fit your needs. Finally, the

F I G U R E 1 . This shows NetImmerse’s continuous LOD

demo. As you move the dinosaur into the distance, its

polygon count decreases. Popping is scarcely visible.

F I G U R E 2 . NetImmerse offers projected shadow targets,

shown, as well as regular ground-plane projection, in

which case the shadow would disappear under the wall.

Excellent Very Good Average PoorBelow Average

h t t p : / / w w w. g d m a g . c o m O C T O B E R 1 9 9 9 G A M E D E V E L O P E R

15

authors of NetImmerse seem to be morein touch with the needs of game pro-grammers than the designers ofFahrenheit. Unfortunately, space is notavailable for a full discussion of this.Simply stated, all of NetImmerse’s fea-tures can save game developers signifi-cant amounts of engineering time,while Fahrenheit’s features seem to havebeen motivated by a checklist of buzz-words. It is likely that game developerswill ignore many of Fahrenheit’s fea-tures, seeing them as ill-fitting or irrele-vant. But a price tag of “free” goes along way, so we can be sure thatFahrenheit will be used. LICENSING TERMS. NetImmerse can bemodularly licensed. The most basiclicensing of the SDK, for use on a sin-gle game project, costs $50,000. Theportal, terrain, and mesh detail reduc-tion systems cost extra, at $10,000each. The MacOS version of the SDK(which NDL plans to make available infall 1999) also costs $10,000. This is aroyalty-free, no-strings-attached licens-ing agreement. For double these prices,you can license NetImmerse for anunlimited number of games to bedeveloped at one site.

The import/export tools are availablein binary form free of charge. Thesource code can be licensed for $20,000per tool. Extended maintenance andsupport licenses are also available.BUILD OR BUY? It would cost many timesNetImmerse’s price tag to develop thein-house equivalent of NetImmerse’scode base, and it would also take a lotof time (measured in years). So in termsof cost and time-to-market savings,licensing NetImmerse makes sense, ifyour goals are compatible with theusage of a general-purpose API.

We’re all familiar with the schedulebloat and general increase of projectfailure that has developed since gameswent 3D. From that standpoint, licens-ing NetImmerse provides a certainamount of security. You know that youhave in your hand algorithms thatsolve a certain set of problems, so afair degree of the technological riskfactor is eliminated from the develop-ment process.

Unfortunately, when faced with thechoice of “build or buy?” game devel-opment teams have chosen “build”more often than they should, resultingin schedule overruns and canceledgames. I have seen many popular

games on store shelves that could havebeen developed more quickly, for lessmoney, and been less buggy in the end,if tools like NetImmerse had been used.

The truth is that the vast majority ofmodern 3D games do not push thelimits of the computer’s graphics capa-bilities, even when the game develop-ers begin the project with the intent ofdoing just that. The developers findthat the project was much more diffi-cult than they expected, and despitethe schedule overruns they still don’t

have time to optimize their hand-coded system to be as fast as it could.In the end, the game player needs avery fast computer to play the game,not because the game has a verysophisticated graphics engine, butbecause that engine is not sophisticat-ed enough. Thus one of the major rea-sons behind the “build” decision — tohave a hand-tuned system that is supe-rior to what everyone else has —becomes self-defeating, and “buy”would have been a better choice. ■

Numerical Design Ltd.Chapel Hill, N.C.(919) 929-2917http://www.ndl.com

System Requirements:For development envi-ronment: 200MHz PC,32MB RAM, 150MB diskspace, Windows 95/98/2000/NT, DirectX 6.1 orOpenGL 1.1.

Supported Platforms:Windows currently;MacOS and Playstation 2versions are pending.

Pros:

1. Provides componentsthat are relevant to mod-ern games.

2. Source code is clean andaccessible.

3. Runs at a reasonablespeed.

Cons:

1. Suffers the usual prob-lems of a generalizedAPI — it’s generalized.

2. Pricing is out of rangefor hobbyists.

3. In some cases, an enginefrom a completed gamemay be a more effectivestarting point.

NetImmerse 2.3:

b y J e f f L a n d e r G R A P H I C C O N T E N T

pened yet, no matter how many times Isee life-like organic aliens and roboticbipeds trotting all over the screen.

The trouble is, humans are tough tosimulate, regardless of how long wetake to create the image. It may beobvious, but the difficulty lies in thefact that we are all very familiar withhow humans look. We see them all thetime. In the morning, I see somethingresembling a human in the mirrorwhile I shave. Living as I do along thecoast, I often see more of the humanform than is probably healthy both formy ego and my digestion. In everydaylife, we see all varieties of people per-forming every imaginable action. Eachof us is an expert in determining thebelievability of a CG human form. Ifthe skin looks wrong or the motionlooks stiff or the lip-synch is off, eachof us screams, “Fake!”

But these technical and artisticproblems are solvable. The brilliantartists and technicians charged withmaking us believe will make sure thatit happens. I have thought a bit aboutthe problems this will present, howev-er. I think about John Wayne. What if,while he was alive, he was asked to doa commercial for beer? Perhaps hisanswer would have been, “Over mydead body!” That used to mean some-thing, that there was no way youwould ever get me to do something. Abit of stock video footage and someclever video processing tricks andvoilà — John Wayne’s dead body sell-ing beer.

Now don’t get me wrong. I seenothing wrong with a family memberlicensing the likeness of a relative forcommercial or charitable purposes. I

think most people would be glad tocontinue to provide a living for theirfamily even after they have gone fromthis life. I just think technology hasforced us to reexamine that particularultimatum. Perhaps it is time forsomething like, “Over my dead bodyand virtually extinct telepresence.”Kind of loses that Wild West charm,doesn’t it?

Bringing Them Back in Real Time

C oncerns over these kinds of legaldilemmas are not going to stop

me from doing my job, however. As acreator of real-time 3D graphics, I notonly face the hurdles which confrontmy visual effects comrades, but I alsoneed to make these realistic charactersmove fast. Fortunately, in this task,technology is on my side.

Realistic characters require lots ofpolygons to make them look realistic.Lots of polygons mean lots of verticesbeing transformed by an overwhelmedCPU. At Siggraph 1998, I began to seethe emergence of transformationacceleration in the consumer graphicshardware space (see “Taking a Breakfor Siggraph,” Graphic Content,October 1998). At that time, I thoughtit wouldn’t be long before we wouldbe able to take advantage of hardwareacceleration for transformation andlighting (HW T&L) in our games.Well, Siggraph has come and gone

again and we are starting to see thisbecome a reality.

One consumer graphics chip com-pany, Nvidia, has publicly committedto delivery of hardware transforma-tion and lighting with their next gen-eration of graphics chips. There arerumblings that others are likely todeliver on this promise as well. In fact,Microsoft is so certain that hardwareT&L will be a reality in the consumerhardware market, they have includedsupport for it in the next version ofthe DirectX game programming API,DirectX 7. Game developers who arescheduling projects for release in thenext production cycle need to consid-er how their projects will handle hard-ware T&L.

How Do We Deal with HW T&L?

F ortunately, the driver writers willdo most of the work for us. Games

using the transformation and lightingpipeline in OpenGL will take immedi-ate advantage of the hardware if it’savailable. Now, with the introductionof DirectX 7, games supporting this APIwill also transparently benefit from thenew hardware. By using the built-intransformation pipeline in either API,games will get faster.

This will naturally enable games toincrease polygon counts without sacri-ficing performance. It also means thatthe load on the CPU will decrease,


17

Over My Dead,

Polygonal Body

A mazing things have been created with computer graphics over the past

several years. Visual effects companies are poised to tackle one of the

most difficult challenges in computer-generated (CG) imaging: creating

a realistic CG human character. However, in my opinion, it hasn’t hap-

When not being frightened by the idea of virtual versions of himself, Jeff creates 3Dgraphics for Darwin 3D. Let him know he is just being paranoid by e-mailing him [email protected].

allowing more processor time for game play features, such asartificial intelligence and game physics. And, as to be expect-ed, creating content that performs well on a variety of usersystem configurations will be more important than ever.

Since we the graphics programmers can gain this benefitwithout doing any real work, hardware T&L doesn’t seem toaffect us much. The programmer will need to conform to astandard pipeline. For the transformation, this doesn’t seem

to be a big deal. Most 3D programmers are com-fortable with matrix manipulation of vertices.The problem is pretty well solved and the onlyissue of trust revolves around the quality of thedriver implementation. Once the hardware isdoing the work, the driver issue largely goesaway. Most will gladly accept this pathway tohardware nirvana.

Lighting, however, is a much more con-tentious issue. No one I have talked to is satis-fied with the lighting model provided by theOpenGL and DirectX libraries. This issue doesn’tbug me that much. I don’t know anyone who isready to give up lighting tricks such as shadowmaps and texture-mapped lighting for simplisticGouraud lighting. While we do need a hardwaresolution for realistic lighting, this is not it. Iadvise continued reliance on those lightingtricks. However, as a supplement to pre-comput-ed lighting for dynamic changes or shadowcomputation, a few hardware point and spotlights couldn’t hurt, particularly if they’re fast. Ican think of a lot of things that a few lightscould be used for.

No, simple transformation and lighting is notthe problem with hardware T&L. We run intothe real trouble when we consider what it meansfor modeling organic objects.

T&L for Non-Rigid Bodies

Hardware transformation is ideally suited tothe display of rigid objects. You first set up

the transformation matrix and then submit anobject to be drawn. With hardware, it will becostly to obtain the results of the transformation

G R A P H I C C O N T E N T

G A M E D E V E L O P E R O C T O B E R 1 9 9 9 h t t p : / / w w w . g d m a g . c o m

18

F I G U R E 1 A . Modeling organic objects is a challenge for 3D

programmers dealing with hardware T&L.

F I G U R E 1 B . Skeletal deformation systems offer both flexi-

bility and good looks.

GLvoid COGLView::GetBaseSkeletonMat(t_Bone *rootBone)

{

/// Local Variables ///////////////////////////////////////////////////////////

int loop;

t_Bone *curBone;

tMatrix tempMatrix;

///////////////////////////////////////////////////////////////////////////////

curBone = rootBone->children;

for (loop = 0; loop < rootBone->childCnt; loop++)

{

glPushMatrix();

glTranslatef(curBone->b_trans.x, curBone->b_trans.y, curBone->b_trans.z);

// Set observer’s orientation and position

glRotatef(curBone->b_rot.z, 0.0f, 0.0f, 1.0f);

glRotatef(curBone->b_rot.y, 0.0f, 1.0f, 0.0f);

glRotatef(curBone->b_rot.x, 1.0f, 0.0f, 0.0f);

// Grab the Matrix that is built up to this point

glGetFloatv(GL_MODELVIEW_MATRIX,tempMatrix.m);

// Invert this matrix to get the Base->World matrix

InvertMatrix(tempMatrix.m,curBone->baseToWorldMat.m);

// Recursive call if the bone has children

if (curBone->childCnt > 0)

GetBaseSkeletonMat(curBone);

glPopMatrix();

curBone++;

}

}

L I S T I N G 1 . Code for the World->RestBone matrix.

before the object is drawn. This means everything needs tobe set up beforehand.

That’s fine for most objects and environments. However,characters do not look their best when composed of rigidobjects. As I have explored in a previous article (“SkinThem Bones,” Graphic Content, May 1998), creating acharacter from a single mesh and then deforming it via askeletal system provides a better solution. By using skeletaldeformation, you maintain the good looks of a seamlessmesh and the animation flexibility of a hierarchical char-acter system.

Unfortunately, this system requires manipulation of ver-tex coordinates. Let me review how a skeletal deformationtechnique works. I have a character in a rest pose in Figure1a and have created a skeleton for the character in Figure 1b.

In order to deform the mesh with the skeleton, I need toassign each vertex to a bone or set of bones. For example, allof the vertices in the head region should be assigned to thehead bone. For now, let me assume that the vertices in thecharacter’s head are completely, or 100 percent, assigned tothe head bone.

I can determine the position and orientation of the headbone at the rest frame by creating a matrix that representsthe transformation needed to move that bone from the ori-gin to its location in the hierarchy. The matrix of each boneis dependent on the matrices of all of its parents, so it is nec-essary to traverse the entire hierarchy to determine thisWorld->RestBone matrix.

Now this matrix will take a vertex and transform it to thelocation of the bone. However, when I am taking the restposition of the character, I will need to know how to take avertex in the mesh and transform it back to the origin.Fortunately, since we are using a matrix operation, this is asimple matter of inverting the World->RestBone matrix with astandard 4×4 matrix inversion routine. I now have aRestBone->World matrix. This only needs to be done once, so Ican store this matrix for later use. You can see the code forcomputing the RestBone->World matrix in Listing 1.

I now have the matrix I need to move any vertex from therest position back to the origin. Now I want to move the ver-tex to its final pose as shown in Figures 2a and 2b. I can do

this virtually the same way. I go through the hierarchy andcreate a matrix for each bone that will take a vertex from theorigin and move it to the bone position in that animationframe. For this World->Bone matrix, I don’t need to invert it.

I now have everything I need to take a rest vertex andmove it to the final position. The procedure is as follows:worldVertex = baseModelVertex * restBoneToWorldMat

deformedVertex = worldVertex * worldToBoneMat

There is an easy optimization step, though. Because twomatrices can be multiplied together to create a matrix that isa sum of both transformations, I can create one matrix thatwill do everything:combinedMatrix = worldToBoneMat * restBoneToWorldMat

Then for each vertex, I simply multiply it by that onematrix:deformedVertex = worldVertex * combinedMatrix

This is the key to skeletal deformation. If you want to havemultiple bones influencing a vertex, this final formula can bescaled by the amount of influence, or weight, of each bone.The sum of all the weights for each vertex should equal 1.

What’s the Problem?

T his process requires each vertex to be transformed by amatrix for every bone that influences it. Clearly, this

process should benefit greatly by the use of hardware trans-formations. However, this really breaks the transformationpipeline. It’s obviously possible for a single polygon to havevertices that are influenced by multiple bones. Therefore,you cannot simply set the transformation matrix and drawa polygon as you would normally. An entire character iseven more complicated.

In order for this to work, I would need to do the matrixoperations first, combine the resulting vertices into a singlepolygon, and submit that to be drawn. However, the pipelinedoesn’t allow this. Getting the results of a transformation isnot a fast process, as it requires values to be returned fromthe driver through a mechanism such as feedback.

This is precisely why it’s crucial that this type of operationbe handled by the driver via the graphics API. It’s impossible



20

F I G U R E 2 A . Our matrix enables us to move the skeleton’s

vertices to our character’s final pose.

F I G U R E 2 B . Our finished model, the beneficiary of our

transformation matrix.

to perform this kind of deformation without breaking thetransformation pipeline. Now many people are against theidea of adding API features for specific effects such as this,but I see no other way to achieve the goal. If the transforma-tion could be handled as a specific DSP operation that wasnot tied directly to the display, it would be possible to havesimple accelerated matrix operations. However, this is notthe direction the hardware development is heading.

What’s Being Done About It?

M icrosoft, while creating DirectX 7, realized that thiswould be an issue. To solve the problem, they created

the notion of “vertex blending.” In vertex blending, thefinal position of a vertex can be determined by the weightedtransformation of up to four matrices.

You set up the matrices by creating a transformstate withthe function:SetTransform( D3DTRANSFORMSTATE_WORLD, matrix1);

SetTransform( D3DTRANSFORMSTATE_WORLD1, matrix2);



By using the flexible vertex format, you submit weights ineach vertex structure. The number of weights is one lessthen the number of matrices being used. This is so that theAPI can enforce the constraint that the sum of the weightsmust equal 1.

For example, if I wanted each vertex to be weighted bytwo different bones, I would use code that looks somethinglike Listing 2. There are some problems with this approach,however. First, the API supports blending of between oneand four matrices. This leads to a content creation issue. If

a particular card supports blending of onlytwo matrices and your content wasdesigned for blending four, you will needto clamp and scale the weights to work.This is yet another restriction for contentcreators.

Second, you set the matrices for eachprimitive instead of each vertex. Each prim-itive submitted to the rasterizer must becomposed of vertices that are blendedamong the same bones. This can be a prob-lem in certain regions, such as the shoulderor waist where it would be quite easy tohave each vertex influenced by a differentbone.

Finally, to submit primitives efficientlyfor rendering, the model will need to besorted by matrix usage. This may meanrearranging your dataset with a sophisticat-ed export utility or custom optimizationtool.

While it will be possible to create contentto match these restrictions, it won’t beeasy. Naturally, artists won’t enjoy beinglimited in their methods of weighting, andtools will need to be developed to handlethe requirements.

But I Don’t Like Direct3D!

Unfortunately, at this time, there’s no way to achieve asimilar functionality in OpenGL using transformation

hardware. The OpenGL community needs to step up anddesign an extension that will provide access to this hardwarecapability.

I would prefer an extension that provides more function-ality with fewer restrictions. I imagine a vertex accumulationbuffer similar to the compiled vertex arrays we have now. Inthis version, you set a transformation matrix and submit aseries of vertices with associated weight values. These aremultiplied, scaled, and accumulated. Once all the verticeshave been processed, the entire mesh is drawn with thisaccumulated vertex array.

This system would have no restrictions on the number ofmatrices in the blend. It would also have the side benefit ofenabling many other interesting 3D effects such as morph-ing. I am not sure if this kind of extension could work withhardware as it exists now but I hope to find out. I’ll keep youposted.

What Are the Goodies?

I have provided a couple of demonstrations on the GameDeveloper web site (http://www.gdmag.com). Both of

them allow you to manipulate a hierarchical skeleton todeform a 3D mesh. One was created using DirectX 7 and thevertex blending function, the other was created usingOpenGL and implements the method I described above. Letme know how you think the algorithm can be improved. ■



22

typedef struct tVertex

{

float x, y, z;

float weight;

D3DCOLOR color;

D3DCOLOR specular;

float u;

float v;

} tVertex;

#define FVF_VERTEX ( D3DFVF_XYZ | D3DFVF_XYZB1 | D3DFVF_DIFFUSE | \

D3DFVF_SPECULAR | D3DFVF_TEX1 )

for (int loop = 0; loop < curBone->visuals[0].faceCnt; loop++)

{

tFace *face;

face = &curBone->visuals[0].face[loop];

// There are two Matrices stored for each vertex

d3ddev.SetTransform( D3DTRANSFORMSTATE_WORLD, face->matrix1);

d3ddev.SetTransform( D3DTRANSFORMSTATE_WORLD1, face->matrix2);

vertex = (tVertex *)curBone->visuals[0].vertex;

HRESULT hr = d3ddev.DrawPrimitive(D3DPT_TRIANGLELIST, FVF_VERTEX, vertex, 3, 0 );

}

L I S T I N G 2 . Vertex blending, where each vertex is weighted by two bones.

b y J e f f L a n d e r G R A P H I C C O N T E N T

pened yet, no matter how many times Isee life-like organic aliens and roboticbipeds trotting all over the screen.

The trouble is, humans are tough tosimulate, regardless of how long wetake to create the image. It may beobvious, but the difficulty lies in thefact that we are all very familiar withhow humans look. We see them all thetime. In the morning, I see somethingresembling a human in the mirrorwhile I shave. Living as I do along thecoast, I often see more of the humanform than is probably healthy both formy ego and my digestion. In everydaylife, we see all varieties of people per-forming every imaginable action. Eachof us is an expert in determining thebelievability of a CG human form. Ifthe skin looks wrong or the motionlooks stiff or the lip-synch is off, eachof us screams, “Fake!”

But these technical and artisticproblems are solvable. The brilliantartists and technicians charged withmaking us believe will make sure thatit happens. I have thought a bit aboutthe problems this will present, howev-er. I think about John Wayne. What if,while he was alive, he was asked to doa commercial for beer? Perhaps hisanswer would have been, “Over mydead body!” That used to mean some-thing, that there was no way youwould ever get me to do something. Abit of stock video footage and someclever video processing tricks andvoilà — John Wayne’s dead body sell-ing beer.

Now don’t get me wrong. I seenothing wrong with a family memberlicensing the likeness of a relative forcommercial or charitable purposes. I

think most people would be glad tocontinue to provide a living for theirfamily even after they have gone fromthis life. I just think technology hasforced us to reexamine that particularultimatum. Perhaps it is time forsomething like, “Over my dead bodyand virtually extinct telepresence.”Kind of loses that Wild West charm,doesn’t it?

Bringing Them Back in Real Time

C oncerns over these kinds of legaldilemmas are not going to stop

me from doing my job, however. As acreator of real-time 3D graphics, I notonly face the hurdles which confrontmy visual effects comrades, but I alsoneed to make these realistic charactersmove fast. Fortunately, in this task,technology is on my side.

Realistic characters require lots ofpolygons to make them look realistic.Lots of polygons mean lots of verticesbeing transformed by an overwhelmedCPU. At Siggraph 1998, I began to seethe emergence of transformationacceleration in the consumer graphicshardware space (see “Taking a Breakfor Siggraph,” Graphic Content,October 1998). At that time, I thoughtit wouldn’t be long before we wouldbe able to take advantage of hardwareacceleration for transformation andlighting (HW T&L) in our games.Well, Siggraph has come and gone

again and we are starting to see thisbecome a reality.

One consumer graphics chip com-pany, Nvidia, has publicly committedto delivery of hardware transforma-tion and lighting with their next gen-eration of graphics chips. There arerumblings that others are likely todeliver on this promise as well. In fact,Microsoft is so certain that hardwareT&L will be a reality in the consumerhardware market, they have includedsupport for it in the next version ofthe DirectX game programming API,DirectX 7. Game developers who arescheduling projects for release in thenext production cycle need to consid-er how their projects will handle hard-ware T&L.

How Do We Deal with HW T&L?

F ortunately, the driver writers willdo most of the work for us. Games

using the transformation and lightingpipeline in OpenGL will take immedi-ate advantage of the hardware if it’savailable. Now, with the introductionof DirectX 7, games supporting this APIwill also transparently benefit from thenew hardware. By using the built-intransformation pipeline in either API,games will get faster.

This will naturally enable games toincrease polygon counts without sacri-ficing performance. It also means thatthe load on the CPU will decrease,


17

Over My Dead,

Polygonal Body

A mazing things have been created with computer graphics over the past

several years. Visual effects companies are poised to tackle one of the

most difficult challenges in computer-generated (CG) imaging: creating

a realistic CG human character. However, in my opinion, it hasn’t hap-

When not being frightened by the idea of virtual versions of himself, Jeff creates 3Dgraphics for Darwin 3D. Let him know he is just being paranoid by e-mailing him [email protected].

allowing more processor time for game play features, such asartificial intelligence and game physics. And, as to be expect-ed, creating content that performs well on a variety of usersystem configurations will be more important than ever.

Since we the graphics programmers can gain this benefitwithout doing any real work, hardware T&L doesn’t seem toaffect us much. The programmer will need to conform to astandard pipeline. For the transformation, this doesn’t seem

to be a big deal. Most 3D programmers are com-fortable with matrix manipulation of vertices.The problem is pretty well solved and the onlyissue of trust revolves around the quality of thedriver implementation. Once the hardware isdoing the work, the driver issue largely goesaway. Most will gladly accept this pathway tohardware nirvana.

Lighting, however, is a much more con-tentious issue. No one I have talked to is satis-fied with the lighting model provided by theOpenGL and DirectX libraries. This issue doesn’tbug me that much. I don’t know anyone who isready to give up lighting tricks such as shadowmaps and texture-mapped lighting for simplisticGouraud lighting. While we do need a hardwaresolution for realistic lighting, this is not it. Iadvise continued reliance on those lightingtricks. However, as a supplement to pre-comput-ed lighting for dynamic changes or shadowcomputation, a few hardware point and spotlights couldn’t hurt, particularly if they’re fast. Ican think of a lot of things that a few lightscould be used for.

No, simple transformation and lighting is notthe problem with hardware T&L. We run intothe real trouble when we consider what it meansfor modeling organic objects.

T&L for Non-Rigid Bodies

Hardware transformation is ideally suited tothe display of rigid objects. You first set up

the transformation matrix and then submit anobject to be drawn. With hardware, it will becostly to obtain the results of the transformation



18

F I G U R E 1 A . Modeling organic objects is a challenge for 3D

programmers dealing with hardware T&L.

F I G U R E 1 B . Skeletal deformation systems offer both flexi-

bility and good looks.

GLvoid COGLView::GetBaseSkeletonMat(t_Bone *rootBone)

{

/// Local Variables ///////////////////////////////////////////////////////////

int loop;

t_Bone *curBone;

tMatrix tempMatrix;

///////////////////////////////////////////////////////////////////////////////

curBone = rootBone->children;

for (loop = 0; loop < rootBone->childCnt; loop++)

{

glPushMatrix();

glTranslatef(curBone->b_trans.x, curBone->b_trans.y, curBone->b_trans.z);

// Set observer’s orientation and position

glRotatef(curBone->b_rot.z, 0.0f, 0.0f, 1.0f);

glRotatef(curBone->b_rot.y, 0.0f, 1.0f, 0.0f);

glRotatef(curBone->b_rot.x, 1.0f, 0.0f, 0.0f);

// Grab the Matrix that is built up to this point

glGetFloatv(GL_MODELVIEW_MATRIX,tempMatrix.m);

// Invert this matrix to get the Base->World matrix

InvertMatrix(tempMatrix.m,curBone->baseToWorldMat.m);

// Recursive call if the bone has children

if (curBone->childCnt > 0)

GetBaseSkeletonMat(curBone);

glPopMatrix();

curBone++;

}

}

L I S T I N G 1 . Code for the World->RestBone matrix.

before the object is drawn. This means everything needs tobe set up beforehand.

That’s fine for most objects and environments. However,characters do not look their best when composed of rigidobjects. As I have explored in a previous article (“SkinThem Bones,” Graphic Content, May 1998), creating acharacter from a single mesh and then deforming it via askeletal system provides a better solution. By using skeletaldeformation, you maintain the good looks of a seamlessmesh and the animation flexibility of a hierarchical char-acter system.

Unfortunately, this system requires manipulation of ver-tex coordinates. Let me review how a skeletal deformationtechnique works. I have a character in a rest pose in Figure1a and have created a skeleton for the character in Figure 1b.

In order to deform the mesh with the skeleton, I need toassign each vertex to a bone or set of bones. For example, allof the vertices in the head region should be assigned to thehead bone. For now, let me assume that the vertices in thecharacter’s head are completely, or 100 percent, assigned tothe head bone.

I can determine the position and orientation of the headbone at the rest frame by creating a matrix that representsthe transformation needed to move that bone from the ori-gin to its location in the hierarchy. The matrix of each boneis dependent on the matrices of all of its parents, so it is nec-essary to traverse the entire hierarchy to determine thisWorld->RestBone matrix.

Now this matrix will take a vertex and transform it to thelocation of the bone. However, when I am taking the restposition of the character, I will need to know how to take avertex in the mesh and transform it back to the origin.Fortunately, since we are using a matrix operation, this is asimple matter of inverting the World->RestBone matrix with astandard 4×4 matrix inversion routine. I now have aRestBone->World matrix. This only needs to be done once, so Ican store this matrix for later use. You can see the code forcomputing the RestBone->World matrix in Listing 1.

I now have the matrix I need to move any vertex from therest position back to the origin. Now I want to move the ver-tex to its final pose as shown in Figures 2a and 2b. I can do

this virtually the same way. I go through the hierarchy andcreate a matrix for each bone that will take a vertex from theorigin and move it to the bone position in that animationframe. For this World->Bone matrix, I don’t need to invert it.

I now have everything I need to take a rest vertex andmove it to the final position. The procedure is as follows:worldVertex = baseModelVertex * restBoneToWorldMat

deformedVertex = worldVertex * worldToBoneMat

There is an easy optimization step, though. Because twomatrices can be multiplied together to create a matrix that isa sum of both transformations, I can create one matrix thatwill do everything:combinedMatrix = worldToBoneMat * restBoneToWorldMat

Then for each vertex, I simply multiply it by that onematrix:deformedVertex = worldVertex * combinedMatrix

This is the key to skeletal deformation. If you want to havemultiple bones influencing a vertex, this final formula can bescaled by the amount of influence, or weight, of each bone.The sum of all the weights for each vertex should equal 1.

What’s the Problem?

T his process requires each vertex to be transformed by amatrix for every bone that influences it. Clearly, this

process should benefit greatly by the use of hardware trans-formations. However, this really breaks the transformationpipeline. It’s obviously possible for a single polygon to havevertices that are influenced by multiple bones. Therefore,you cannot simply set the transformation matrix and drawa polygon as you would normally. An entire character iseven more complicated.

In order for this to work, I would need to do the matrixoperations first, combine the resulting vertices into a singlepolygon, and submit that to be drawn. However, the pipelinedoesn’t allow this. Getting the results of a transformation isnot a fast process, as it requires values to be returned fromthe driver through a mechanism such as feedback.

This is precisely why it’s crucial that this type of operationbe handled by the driver via the graphics API. It’s impossible



20

F I G U R E 2 A . Our matrix enables us to move the skeleton’s

vertices to our character’s final pose.

F I G U R E 2 B . Our finished model, the beneficiary of our

transformation matrix.

to perform this kind of deformation without breaking thetransformation pipeline. Now many people are against theidea of adding API features for specific effects such as this,but I see no other way to achieve the goal. If the transforma-tion could be handled as a specific DSP operation that wasnot tied directly to the display, it would be possible to havesimple accelerated matrix operations. However, this is notthe direction the hardware development is heading.

What’s Being Done About It?

M icrosoft, while creating DirectX 7, realized that thiswould be an issue. To solve the problem, they created

the notion of “vertex blending.” In vertex blending, thefinal position of a vertex can be determined by the weightedtransformation of up to four matrices.

You set up the matrices by creating a transformstate withthe function:SetTransform( D3DTRANSFORMSTATE_WORLD, matrix1);




By using the flexible vertex format, you submit weights ineach vertex structure. The number of weights is one lessthen the number of matrices being used. This is so that theAPI can enforce the constraint that the sum of the weightsmust equal 1.

For example, if I wanted each vertex to be weighted bytwo different bones, I would use code that looks somethinglike Listing 2. There are some problems with this approach,however. First, the API supports blending of between oneand four matrices. This leads to a content creation issue. If

a particular card supports blending of onlytwo matrices and your content wasdesigned for blending four, you will needto clamp and scale the weights to work.This is yet another restriction for contentcreators.

Second, you set the matrices for eachprimitive instead of each vertex. Each prim-itive submitted to the rasterizer must becomposed of vertices that are blendedamong the same bones. This can be a prob-lem in certain regions, such as the shoulderor waist where it would be quite easy tohave each vertex influenced by a differentbone.

Finally, to submit primitives efficientlyfor rendering, the model will need to besorted by matrix usage. This may meanrearranging your dataset with a sophisticat-ed export utility or custom optimizationtool.

While it will be possible to create contentto match these restrictions, it won’t beeasy. Naturally, artists won’t enjoy beinglimited in their methods of weighting, andtools will need to be developed to handlethe requirements.

But I Don’t Like Direct3D!

Unfortunately, at this time, there’s no way to achieve asimilar functionality in OpenGL using transformation

hardware. The OpenGL community needs to step up anddesign an extension that will provide access to this hardwarecapability.

I would prefer an extension that provides more function-ality with fewer restrictions. I imagine a vertex accumulationbuffer similar to the compiled vertex arrays we have now. Inthis version, you set a transformation matrix and submit aseries of vertices with associated weight values. These aremultiplied, scaled, and accumulated. Once all the verticeshave been processed, the entire mesh is drawn with thisaccumulated vertex array.

This system would have no restrictions on the number ofmatrices in the blend. It would also have the side benefit ofenabling many other interesting 3D effects such as morph-ing. I am not sure if this kind of extension could work withhardware as it exists now but I hope to find out. I’ll keep youposted.

What Are the Goodies?

I have provided a couple of demonstrations on the GameDeveloper web site (http://www.gdmag.com). Both of

them allow you to manipulate a hierarchical skeleton todeform a 3D mesh. One was created using DirectX 7 and thevertex blending function, the other was created usingOpenGL and implements the method I described above. Letme know how you think the algorithm can be improved. ■



22

typedef struct tVertex

{

float x, y, z;

float weight;

D3DCOLOR color;

D3DCOLOR specular;

float u;

float v;

} tVertex;

#define FVF_VERTEX ( D3DFVF_XYZ | D3DFVF_XYZB1 | D3DFVF_DIFFUSE | \

D3DFVF_SPECULAR | D3DFVF_TEX1 )

for (int loop = 0; loop < curBone->visuals[0].faceCnt; loop++)

{

tFace *face;

face = &curBone->visuals[0].face[loop];

// There are two Matrices stored for each vertex

d3ddev.SetTransform( D3DTRANSFORMSTATE_WORLD, face->matrix1);

d3ddev.SetTransform( D3DTRANSFORMSTATE_WORLD1, face->matrix2);

vertex = (tVertex *)curBone->visuals[0].vertex;

HRESULT hr = d3ddev.DrawPrimitive(D3DPT_TRIANGLELIST, FVF_VERTEX, vertex, 3, 0 );

}

L I S T I N G 2 . Vertex blending, where each vertex is weighted by two bones.

b y P a u l S t e e d A R T I S T ’ S V I E W

time because of the millions of facesyou have to ray-trace. Then again, ifyou have a pimped-out machine eventhe mental gymnastics of making sureyour model complexity matches yourin-view requirements becomes moot.Even so, if your scene contains a dis-tant character that is only 50 pixelshigh in your 720×486 render, chancesare he doesn’t have to have 50,000-faceboots. High-resolution modeling andanimating is a luxury.

When animating characters for real-time polygonal games such as QUAKE 3:ARENA or DRAKAN, “luxury” becomes afour-letter word, and optimizationyour mantra. More so than in renderedcharacter animation, real-time, low-polygon character animation requires alot more brain power and planning.

Low-Polygon Defined

I ’ll begin with defining low-polygonas a character weighing in at under

1,000 faces. Most of the characters Itypically work with have between 700and 900 faces — but without splittingtoo many hairs, any model with fourdigits in its face-count just isn’t low-polygon anymore. Then again, thereare plenty of characters in games todaythat are over 1,000 faces, but they’reusually “boss” or unique charactersthat are going to dominate a scene andallow for more polygon gluttony onthat character’s part.

The character in Figure 1, for exam-ple, is actually composed of two charac-ters. The big ugly guy is the mount ofthe actual boss character (sitting on hisback) and together they weigh in ataround 3,500 faces. Of course, no otherenemies can be present at the same timethis final boss is on-screen. Otherwisethe game would turn into a slide show.

Other factors that determine what“low-polygon” actually means can bethe core technology (or game engine)used and level of detail. Level of detailis straightforward enough and consistsof adjusting mesh complexity based onits proximity to the viewer. Right nowthere are several programs, both stand-alone and plug-in, that will optimizeyour models for you, increase the speedof the game and basically give youmore polygons with which to buildyour characters. As far as what kind ofanimation technology can drive yourcharacters, there are currently two

main types: skeletal animation and ver-tex deformation.

Skeletal vs. Vertex Deformation

In simplest terms, skeletal animationconsists of a mesh being deformed by

an underlying skeleton. The mesh itselfand its subatomic components of ver-tex, edge, and face don’t contain anyanimation data. They are attached tothe skeleton and are tweaked to certaintolerances as they are influenced by oneor more bone. The bones are then ani-mated instead of the mesh itself and thegame uses that data to translate motioninto the character. Valve incorporated askeletal animation system into id Soft-ware’s QUAKE engine to allow themmore fluid motion, less media storageper character, and occasional higher-polygon creatures in last year’s criticallyacclaimed HALF-LIFE.

The advantages of a skeletal anima-tion system are numerous to say theleast: smoother animation sequences,more realistic and diverse animations,80-frame walk cycles, and so on. But inthe end, the skeletal animation relieson keyframed (or motion-captured)data provided by the artist just like ver-tex deformation animations. Ironically,most vertex deformation keyframemeshes are derived from animationscreated using a skeletal system of somesort (just not in the game engine). It’strue vertex deformation animation lim-


25

Staying in Shape: Low-Polygon

Mesh Accommodation

B uilding and animating high-resolution characters for use in rendered art

such as print ads, game cinematics, or movie special effects is fun — the

sky’s the limit. Your only possible concern in terms of total polygon

count is the unwieldy nature of large scenes and the length of render

Paul Steed is a form of computer game artist concentrate. Just add expensive imported beer, hard-to-find microbrewery swill or bot-tled water to yield a virtually endless supply of ideas, models, animations, and the occasional texture or three. Paul Steed can befound in the upcoming title, QUAKE 3: ARENA. For product information, contact [email protected].

F I G U R E 1 . These two characters

won’t have any on-screen company.

its itself by providing a locked posemesh that essentially becomes a key-frame. It’s just as true that skeletal ani-mation limits itself by taking a certainamount of control away from the artistand forces him or her into the con-straints of a narrow technological box.

Vertex interpolation, variable framerate control, and a logically segmentedbody system via tag representation canmake vertex deformation work nearlyas well as a full skeletal system andleave a huge amount of control andextensibility in the hands of the artist.Figure 2 shows id’s upcoming QUAKE 3:ARENA, in which this technique for ani-mating characters has yielded signifi-cant animation enrichment. The biggestbenefit of a system like this is that whenyou move your mouse from side to side,your character’s head, then torso, thenlower body shift around accordingly.This generates small, ancillary motionscreated by the player that never had tobe keyframed, and in essence becometrue real-time animation.

Regardless of what animation system

the game engine employs utilizing low-polygon models for characters, face-counts are still important for overallgame speed. Even with a dynamiclevel-of-detail system and a higherpolygon budget, not paying carefulattention to the construction of yourmesh is just asking for trouble whenyou go to animate it.

Look at Those Lines

A s you can see in Figure 3, thischaracter has a certain amount of

curvature in its design that needs to beconveyed and retained while goingthrough a varied range of motions.Once the model is attached to a skele-ton (in this case a biped using 3DStudio Max 2.5 and Character Studio),we can seek out any problems with hermesh integrity as she animates.

Looking at the wireframe of themodel, you can see I’ve tried to keep itas clean and symmetrical as possible.By this I mean making every vertex,edge, and face a useful part of themodel. Keeping the model symmetri-cal in terms of gross polygon usage iskey. If it isn’t needed to delineate anintentional shape, get rid of it. Inessence, the character gets its massthrough the shaping of its constituentparts. Of course, the trick is to impartmass in fewer than 800 faces.

So, after the model is attached to herunderlying skeleton, I begin animatingher. Figure 4 shows how the characterlooks during her walk cycle.

Not bad. The mesh seems to be

deforming well enough and the shapeis holding up nicely. This particularcharacter carries a weapon of some sortall the time so, I’ve assigned a wire-frame material to it preventing it fromobscuring any mesh weirdness.

Now let’s look at another animationsequence: her crouched walk cycle,shown in Figure 5. Immediately I seesome weirdness at her backside. Giventhe limited number of polygons, it’shard to get a decent FPB (face per butt)ratio going, so some angularity is to beexpected. However, the settings in theanimation tool that describe how muchinfluence a particular bone or joint hasover the geometry can be tweaked toovercome this. Sometimes, however, thesettings are right and the mesh itselfneeds to be tweaked.

A R T I S T ’ S V I E W


26

F I G U R E 3 . Modeling this character’s

curves efficiently will be a challenge.

F I G U R E 4 . The character’s walk cycle — so far, so good.

F I G U R E 6 . Her inner thighs flatten as she crouches down. F I G U R E 5 . Her crouched walk cycle presents problems.

F I G U R E 2 . Players create true real-

time animation in QUAKE 3: ARENA.

Look a little closer at the mesh inFigure 6. Notice we’ve hid everythingbut the legs and have gone to a flat-shaded, non-textured mode to get a bet-ter sense for the deformations of themodel. For me, smooth shading hindersmy ability to get a feel for how themodel is shaping up and I always workin flat-shaded mode when not in wire-frame. In the case of this particularmodel, not only is it losing its roundedshape when crouched, the inner thighs’edges are collapsing. Easy enough to fix— turning some edges will help the flat-tening of the inner thigh, so let’s do justthat, as I have done in Figure 7.

Figure 8 shows how it looks betterwith the edges turned, but what aboutthose pointy cheeks? Houston, fromthis view, we definitely have a prob-

lem. This character is supposed to be asexy biker/monster-killer/femme fatalewho can frag with best of them.

To begin correcting the problem, weneed to look more closely at the legs(Figure 9). We take for granted the ver-tex weighting and bone influences arecorrect, so the task at hand is to addfaces to the hip and leg areas to giveher fewer angles and more curves. Butfirst, I’ll explain the reasoning behindthe current distribution of polygons.

Obviously, frugality is the key here.I’ve tried to keep the cross-section ofthe leg at any given point down to nomore than a pentagon. The thighs weremeant to be strong and healthy, andthe knees need extra segments for flex-ion. To the rear, a few extra faces wereput in relative to the rest of the legs

purely for shaping reasons and deemedan important enough feature to have arelatively good FPB (not great, but nottoo skimpy, either). The boots are greatsince the texture is so detailed and cov-ers up the low number of trianglesthere. Obviously the problem lies inthe area from the mid-posterior to justabove the knee.

Figure 10 provides another look at theleg done in cross-section to show what Imean. Notice how the inner thigh linescreated by the configuration of facesand edges cause some bad pinching andedge overlap. The two vertices at the topof the thigh can’t really move aroundtoo much since they anchor the hips,and help keep the mass there. So again,the conclusion stands that we need toput some more faces in the thighs.

Thus, after much tweak-ing — adding more faces,experimentally turningedges to see what worksbest, playing aroundwith the vertex weight-ing, and tweaking somemore on top of that — Icame up with the solu-tion shown in Figure 11.

Compare the frontview of the old and newversion of the legs. As Iwent through the tweak-ing process, the mostinteresting change I hadto make was the relative-ly minor adjustments tothe height of the verticesthat form the hips (1).



28

F I G U R E 7. Turning some of the edges alleviates the flat-

tening of the inner thigh.

F I G U R E 1 0 . Now we’ve isoated the problem: some

edges are overlapping and pinching at the inner thigh.

F I G U R E 9 . Polygons have been care-

fully allocated throughout the legs.

F I G U R E 8 . Pointiness in back is an unwanted side effect of

fixing the inner thigh problem.

This wasn’t just a purely form-keepingmove to better use the extra polygons Iput in her backside, either. This heightadjustment was key to making sure thatin the crouched position the segmentsmaking up the curve of her cheekflexed and distributed themselves even-ly enough to look rounded. Again, thismay be something particular to the wayPhysique works in Character Studio,but I remember having the same issuesin Alias|Wavefront’s Power Animator.

Moving on, also note that when I firstbuilt the leg, I simply over-optimizedthe thigh and compromised its mass bynot having a full segment midway up(2). I also had to increase the cross-sec-tion circumference to retain mass whenthe character crouches (3). Next, I hadto insert a partial segment just above

the knee to supportthe muscular innerthigh I was trying toimpart (4).

Figure 12 shows afull comparisonbetween the old leg(blue) and new leg(yellow). Overall, Ihad to add moregeometry, but moreimportantly I had tomake sure the edgeswere arranged toavoid inappropriatecollapsing. Again,this takes time andexperimentationmore than anything else, but the factthat there is a limitation on the polygoncount makes it more challenging than ifI could have added unlimited faces.Referring to our cross-section in Figure13, we can see the leg is more roundedand full. Now she can crouch walk instyle and not get laughed at because herbehind is so pointy (Figure 14).

Rising to the Challenge

C reating convincing, good-looking,low-polygon meshes is a challenge.

Making sure these models animate wellwith their polygon budgets requiresquite a bit of thought. If I had to comeup with an overriding rule of thumbwhen it comes to ensuring your meshwill accommodate your animations, I’dsay it’s a matter of convexity. When Itweaked the character’s leg to make itretain its mass, my goal was to findedges that were being torqued in such away that the illusion of mass was beingtaken away.

I turned the edges to go from a con-cave to a convex look, but in the caseof the upper thigh, I had to insert addi-tional geometry to support its shape.Viewing your model in flat-shaded

mode makes finding concave edges rel-atively easy, but very crucial. Whenreviewing and testing your models forproper deformation, definitely seek outthose edges and turn them. Unwanteddents and divots in your mesh breakthe illusion of mass very quickly andjust plain make your model look bad.

I know attaching a mesh to a skeletonand spending hours getting your vertexassociation just right is a difficult thingto throw away. I cringe every time I real-ize I have to detach the mesh and tweakit. Not only is reattaching it a pain, butreassigning UVs and getting the texture(if it’s already been done) to line upmakes for hair loss and lack of sleep.However, if you have to perform mas-sive reconstructive surgery on a part of amodel that isn’t quite working out tomake it better than it currentlyis...tough. Unless you’re going gold thenext day, never settle for what the com-puter will give you — only settle forexactly what you want. It’s what sepa-rates the men from the boys and thewomen from the girls. ■



30 F I G U R E 1 1 . A few small changes will

make a big difference.

F I G U R E 1 2 . In the end, a little more geometry was

added, with careful attention paid to arranging the edges.

F I G U R E 1 3 . After the changes, the

thigh is rounder and fuller. F I G U R E 1 4 . At last, our character can crouch with confidence.

Now that DRAKAN has shipped, Mel

Guymon is taking a few months off to

recover. He will return in January 2000.

Where’s Mel?

b y O m i d R a h m a t H A R D T A R G E T S

Obviously, bundling software withhardware is a symbiotic process thatshould benefit both the software andhardware partner, but it’s also a special-ist sales channel that needs to beapproached with care.

Everyone a Microsoft

T he greatest bundling machine inthe computer business is Micro-

soft. Not only does the company haveits operating system bundled withevery PC sold, but you can almostguarantee that there are other Micro-soft goodies on your hard drive, andeven the odd interactive media prod-uct. In very simple terms, Microsoftmakes the software that sells the hard-ware, and in return, the hardware vendors have had little desire to goanywhere else for software. Fortunate-ly, Microsoft has also driven PC tech-nologies by supporting features in itsoperating systems that have made itpossible for hardware innovations toflourish.

Game developers may not be able tooffer the same breadth of opportuni-ties as Microsoft does with Windows,but they do hold a key, which canunlock higher-end technologies suchas 3D graphics and surround soundaudio, and they also help Intel andAMD sell ever-greater performingCPUs. Leading the charge in entertain-ment software OEM deals is InterplayOEM. In fact, Interplay is the only one

of the major publishers that has set itsOEM business as a separate subsidiary.Interplay OEM should stand alone;the company counts among its cus-tomers LucasArts, Take Two Interac-tive, Fox Interactive, WestwoodStudios, Virgin Interactive Entertain-ment, and Gathering of Developers.It’s the model of how OEM salesshould be built into a game publish-ing business.

Additionally, Interplay OEM alsohandles licensing and merchandisingactivities on behalf of Interplay andShiny Entertainment, including nov-elizations, strategy guides, and othermerchandise tied to Interplay’s gameproperties. There are also arrange-ments for royalty-based revenues fromlicensing arrangements and the sale ofproducts by third-party distributors ininternational markets.

Bundling for Profit

J ill S. Goldworn has served as presi-dent of Interplay since December

1996, and has handled OEM contractsfor the last ten years. Unlike somegame developers and publishers thatview OEM sales as part promotionaltool and part incremental revenuestream, Goldworn has a strong belief

that the OEM sales channel is a majorrevenue contributor.

Goldworn says, “OEM sales are forpure revenue purposes and, alsoimportant, getting access to cuttingedge technology early. It’s the same asin the console market — if a developergets a hold of the next-generationtechnology early enough, it is posi-tioned to take advantage of the con-sole at launch. We’ll actually put insupport for some technologies beforethe traditional retail channel estab-lishes a need for it — for example,DVD. We’ve been developing DVDtitles for a number of months. So,we’ve actually developed DVD titlesfor OEM, which retail will take to themarket later.”

The benefit of marrying the revenuepotential of OEM sales to the techno-logical advantage it can give a develop-er isn’t lost on companies such asFrance’s Ubi Soft, and Rage Software,based in the U.K. Ubi Soft’s TONIC

TROUBLE, and previously, POD, haveachieved unit shipments in excess ofone million by piggybacking behindthe Pentium II and Pentium III launch-es. POD was probably the standard-bearer for MMX-enhanced games, andwhile it may have done well in OEMchannels, there never was any retailMMX market to speak of. In 3D, Rage’s


33

Interplay OEM:

Little Bundles of Joy

R ecently, Mattel Media announced that it was teaming up with Patriot

Computers to launch Barbie- and Hot Wheels-branded PCs for children.

These lunchbox PCs (my term, not the manufacturers’) would cost

around $599, and include a library of education and entertainment soft-

ware from Mattel Media and its recent acquisition, The Learning Company. No prizes for

guessing which computer would have the girl software, and which the boy software.

Omid Rahmat is the proprietor of Doodah Marketing, a digital media consulting firm.He also publishes research and market analysis notes on his web site athttp://www.smokezine.com. He can be reached via e-mail at [email protected].

INCOMING has been among the bestselling OEM titles in recent years,probably constituting a third of Rage’stotal revenues. Now, the company’sfollow up, EXPENDABLE, is following inits footsteps, and looks as if it too willcome out equally strong in Pentium IIIlineups in 1999.

Goldworn herself has evangelizedthe OEM channel to the game indus-try drawing other publishers into theInterplay OEM fold. “Our wholemodel is to educate publishers abouttechnologies that will eventuallybecome a revenue stream for them,”she says.

LucasArts used to think of OEM salesas a small contributor to its revenues,and not worth focusing on. However,after five years of working with Inter-play’s OEM team, the company is nowputting an OEM SKU on its releaseschedule. Whereas in the pastLucasArts would take months to buildan OEM version of a title, it now hasan OEM support and developmentstructure in place almost simultaneous-ly releasing retail and OEM SKUs. Forcompanies such as LucasArts, it makesgood business sense to be in OEM, butit is also valuable strategically. Thedeveloper gets early access to technolo-gies, and the title gets automatic expo-sure in the hardware vendors’ market-ing and sales promotions.

Of course, the hardware technolo-gists need game developers more thanthey’d care to mention. Intel, AMD,

3dfx, Nvidia, Diamond, Creative, ATI,and Matrox have all courted develop-ers with technology, free hardware,and sometimes, cold, hard cash, inorder to get a game or games ready fora new product launch. It also helpswhen a company such as Intel recom-mends the cutting edge titles it favorsto its PC OEMs. It’s a win-win situa-tion for all parties, but developershave to be aware of the problems ofjumping on the cutting edge of tech-nology, too.

Working with new technologiesoften means that a game title has tobe modified for it, in addition tobeing maintained for the existinginstalled base. Everything from codeto art work has to be refreshed insome cases, and the results could beslippage in shipment times, or evenlost development time if things don’tgo according to plan. In other words,the risks of working with any newtechnology don’t go away when anOEM is involved, regardless of thefinancial carrot being dangled.

Delays in shipment of a title, or theexpectation that an OEM release willtranslate into a big retail launch, areoften the two biggest problems devel-opers face. If a developer is tied into anOEM release in order to get a launchfor a new title, any delay can have seri-ous repercussions. Even a successfulOEM product doesn’t guarantee a simi-lar impact in the retail channel. UbiSoft’s POD proves this. Therefore,

developers should plan for OEM inmuch the same way as they plan forany title.

An OEM Strategy

W ith the development hiccups ofOEM opportunities having

been overcome, there are still numer-ous ways in which a company can get atitle bundled with hardware:STRAIGHT: The straight bundling dealrequires the developer or publisher todeliver a CD for inclusion by the hard-ware vendor with its products. Thedeal is often subject to a certain mini-mum quantity, or staggered so thatdifferent discounts apply as the ven-dor ships increasing numbers of thebundled software. The straight bundledeal is probably the easiest to trackbecause finished goods are beingshipped, and revenue generateddirectly thereafter. However, whilestraight bundling deals are great if youare in the position of an InterplayOEM, and have a strong catalog oftitles to offer, a smaller developer willoften find them more difficult tocome by. Still, there is always room inthe OEM market for a title that definesa new technology and gets consumerrecognition of it.TARGETED: A developer or publisher maychoose to target a particular 3D graph-ics chipset, or CPU product. Ubi Soft isdoing it with Matrox, and Interplay

H A R D T A R G E T S


34

19

97

$ 120,053

OEM*

Int'l

Int'l

N. America

N. America

OEM*

58% 28% 14%

53% 35% 12%

10 20 30 40 50 60 70 80 90 100 120 1300% of Change 1997 - 1998

N.

Am

eri

ca

Int’

l

OE

M*

Ne

t

Re

ven

ue

Net Revenue

25%

20%

15%

10%

5%

0%

-5%

-10%

-15%

-20%

Total revenue in thousands of dollars

* OEM, royalty, & licensing

Net Revenue $ 126,862

$64,106 $41,922 $14,025

$73,865 $35,793 $17,204

100%

100%

6%

23

%

-15

%

15%

19

98

C H A R T 1 . Interplay OEM’s performance relative to overall revenue achievements, in thousands of dollars and percentage

points. Interplay OEM also provides licensing and merchandising deals, but it can be safely assumed that the bulk of its

sales are from straightforward bundling deals (source: Interplay).

OEM has done it with 3dfx in thepast. In effect, the modified OEM titlewill only work on the hardware ven-dor’s particular product. For example,the title might work with 3dfx’sVoodoo 3, but not Voodoo 2. It’salmost an ideal bundle arrangementbecause the hardware vendor gets tolaunch big on a product and use a spe-cific title for its platform, while adeveloper gets the benefit of the expo-sure the hardware brings, but can stilllook forward to exploiting opportuni-ties in other areas of the market andon other hardware platforms. Intel,AMD, and any number of 3D graphicsand audio guys have a vested interestin getting a unique experience fortheir products.ENCRYPTED: Some vendors have attempt-ed — with little success thus far — toship encrypted, time-locked versionsof their titles with a hardware prod-uct, hoping to get the benefit of thefull sell when a user buys the product-unlock key. This is more of a market-ing strategy, and less of a bundlingarrangement, but it is something thathas been tried in the OEM market

before. The results for game compa-nies have been poor, with responserates being equivalent to a direct mailcampaign, in the region of one or twopercent. So it works for AOL disks, butnot for games. Still, many hardwarevendors are looking at ways of creat-ing bundling arrangements that willallow them to get a slice of the retailsale of a title. The most obvious possi-bilities are going to be on the Internet.As more hardware companies developtheir direct sales on the web, they arelooking for ways to leverage theirproducts off of software and content.In many cases, selling a package ofgoods, such as a graphics board and ahandful of titles, is better than tryingto sell the individual components ofthe deal separately. LIMITED: With some popular titles, limit-ed versions, or versions containing spe-cific levels but not the full retail com-plement, are used in OEM bundles. LICENSED: Many vendors are moving toa model whereby they license content,therefore not requiring any finishedgoods from the developer. As is thecase with most PC OEMs, bundled

software is preloaded on the harddrive, and the cost of reproducing anumber of bundled software CDs issaved.

As for the revenues, bundled titlescan fetch anywhere from as little as35¢ to as much as $14 per title. Theminimum quantities required to qual-ify for a bundle deal varies. I haveseen deals done for 12,000 unit com-mitments on some high-end peripher-als, to multi-million-unit commit-ments on some CPU products. Formost of the major publishers, once aproduct’s revenues fall under $1 perunit, the OEM sales lose almost alltheir appeal. Publishers will changepricing depending on the age of theproduct, or the hardware vendor theyare dealing with. Whatever the priceor the unit commitment, new tech-nologies such as faster CPUs and faster3D graphics need games to turn con-sumers on to them. It’s also worthknowing that these new hardwaretechnologies are more profitable forthe vendors, thus leaving room for anaggressive OEM sales company likeInterplay OEM. ■


35

ound effects are an integral part of games, equal in importance to

artwork, music, and game play. And I’m not just saying that because I

create them either — I’m also a game player, so I understand their

impact from that perspective, too. Sounds are designed to absorb

the player into the game world, to make it believable, entertaining, and satisfying.

The process of determining the appropriate sounds for a given game situation, creating

them, and implementing them in the game isn’t always a painless experience. Both

sound designers and game producers need to understand each other’s professional needs

and responsibilities so that the sound design process becomes less grueling to both par-

ties. This article describes the process of determining what you will need from a third-

party sound designer, what that person will need from you, and will briefly describe the

process audio contractors go through to create high-quality sound effects.


36B Y A A R O N M A R K S

Aaron Marks ([email protected]) is a sound designer, music composer, and owner of On Your Mark Music Productions. Look formore of his life story at: http://members.aol.com/aBmajor.

How to work with athird-party sound

designer

illu

stra

tio

n b

y St

uar

t B

rad

ford

Where Does It All Start?

J oey Kuras, sound designer forTommy Tallarico Studios, has per-

sonal credits on more than 60 games,and he recently worked on the JamesBond game, TOMORROW NEVER DIES.Early in the production cycle, he wasgiven a list of effects needed for thetitle. He designed and delivered morethan 200 sounds per the developer’srequest, only to have approximately 90percent of them discarded as the pro-duction matured. He ended up recreat-ing them later in the project. Onanother project, he received an unspe-cific and vague list of sounds. Therequest for a “splash” sound had littlemeaning to him. Was it a rock makingthe splash? A person? A 400-poundobject or a four-pound object? Was thebody of water a bathtub, a pond, or anocean? No one he talked to was sureand they ended up waiting far into theproject to solve the mystery.

This is a lesson for all of us. Earlyconcepts of art and game play have atendency to change and continuouslyevolve, so sound design at the outset ofa project is usually a grand waste oftime. Producers have the difficult taskof trying to determine the audio needsof the game early in the developmentcycle, and if a contracted sound design-er is used, the producer must find onewhose skills and credits match those ofthe game being developed and negoti-ate the contract with that individual.When you are spending up to $30,000for sound effects, you want to get yourmoney’s worth.

The producer may have to take along-range look at what sorts ofsounds the game may need (generalFoley sounds, imaginative or “far out”sounds, and so on). If the game is tohave a wide range of settings andcharacters, it can be difficult to imag-ine what this large bank of effects willconsist of. Therefore, it’s important tobring the development team togetherto begin thinking conceptually aboutthe game audio as early as possible. Ifyou’ve decided on a sound profession-al, bring him or her in on the discus-sion and listen to what the sounddesigner’s experience has to say. A lotof time can be saved this way and theprocess will have more grease for asmooth ride. Don’t be tempted tojump into the audio implementation

details, however — starting the cre-ation of game sound effects too earlyin the process often leads to majorheadaches down the line, as I’llexplain later.

Usually, when a game is far enoughalong (at the point when characters,movements, and a defined game playmodel are present), the sound designershould enter the picture. By permittingsound designers to meet with the devel-opment team, view some rough gamelevels, and perhaps see some animationideas, their idea machine can begin tochurn out possible routes to take.Also, asking a few

specific ques-tions will bring a direction and neces-

sary information together to get off to asmart start.

Contracting Out the Work

T he actual task of finding a third-party contractor can be as arduous

as creating the game itself. Unlessyou’ve worked with a particular sounddesigner in the past and you’re com-fortable using him or her again, you’llneed to take care of some advancework. Even before the project is putout for bid, a media buyer (often theproducer’s role) can do homework.Investigate various sound designcompanies beforehand to stay aheadof the game. Web search engines canhelp, developer resource web sites areprevalent, and the numerous unsolicit-ed e-mails, inquiries, and résumés can(finally) be taken advantage of.Request a sound designer’s currentdemo reel, references, and examples of past work, and keep this data onfile.

When the time does come to startlooking at bids, the producer alone, orwith several of the team members, sitsdown to evaluate submissions. Gener-ally, they are looking for outstandingwork, creativity, a shared vision, relia-bility, experience, and someone withwhom they feel they can work for thelength of the project. After the fieldhas been narrowed to a couple ofchoices, pick up the phone or invitethem over. It’s a good idea to talk tothe candidates either by phone or inperson before any final decisions aremade. Check their production sched-ules to ensure they will be available(some busier sound people are bookedtwo to three months in advance), seewhich one you feel is best at commu-nicating and receiving ideas, and get asense of whom you can get alongwith.

Moving on from the courtship stagetoward project commitment necessi-tates that both parties bring theirinterests (and sometimes lawyers) tothe table and work out an agreementboth sides feel comfortable with.Typically, though, negotiations forsound design work are fairly simple.More complicated negotiations comeup when music creation is also part ofthe deal, because that can also involvehashing out ancillary rights, paymentfor different SKUs, bonuses, propertyrights for soundtrack releases, and soon. Spend a little time working out anequitable agreement and get thebusiness out of the way so you canfocus on the creative aspects of greatdevelopment.

Prices for sound design services varyper contractor, as each contractor hasdifferent overhead costs to meet. Thosewith more experience can, of course,demand more, and their experience isusually worth the price. Rush jobs, spe-cial requests, and other tasks assignedto the sound designer (such as audi-tioning, hiring, and producing voicetalent and their sessions, abnormalamounts of revisions or change orders,and so on) can increase the price, too,so try to plan ahead. The bottom line isthat costs are definitely negotiable, butdon’t expect the contractor to work forfree or below their expenses. For moreinformation about payments and con-tracts for sound design, see the sidebaron p. 44, “The Audio DevelopmentAgreement.”


38

G A M E A U D I O

Questions Sound Designers Ask

A round the time a producer is tryingto wrap up contract negotiations

with a sound designer is when thesound designer is going to want toknow the nitty-gritty details about theproject. This is the point at which “clearand concise” can mean the differencebetween complete audio bliss and asound disaster. A good sound designerwill want specific information about thegame. As the producer or team leader,be prepared to answer the followingquestions clearly and concisely: FOR WHAT PLATFORM IS THE GAME INTENDED?This will suggest what type of playbacksystem the consumer will use and theconfines the final sound effects will restwithin. As a sound guy, I mix to severalplayback systems — from “el cheapo”multimedia speakers you buy at thegrocery store to high-end studio moni-tors. My interest is to make my soundswork well with them all, but my mainfocus is on the system the majority ofpeople will be using. FOR WHAT GENRE IS THE GAME INTENDED? Youwant the music and sound effects tofollow the spirit of the game, so makesure you communicate this to yoursound designer, including the feel ofthe game, what genre it falls into, andwhat similar games are currently onthe market.WHAT SAMPLE RATE, BIT SIZE, AND FILE FORMAT

ARE PREFERRED? Should the audio be instereo or mono? The development teamshould have done all of its homework todetermine how much space the graphicsand sound will be allotted. This infor-mation will help decide the sound qual-ity level and within what parametersthe sounds should be created.WILL SOUND EFFECTS BE ALTERED BY ANY SOFT-WARE OR HARDWARE PROCESSORS? Addition-al processing by a game engine willdetermine to what extent certainsounds are processed beforehand bythe sound designer (if a sound designerapplies reverb to a sound that thedeveloper had planned to apply reverbto in the game, that could be a prob-lem). For example, driving games oftenapply a reverb effect to sounds. This isthe kind of information the sounddesigner needs to know at the outset.Decide as soon as possible if there areplans for this type of processing andcommunicate them, so that the sounddesigner doesn’t overprocess any files.

ARE ANY AMBIENT SOUNDS NEEDED? Youprobably don’t want to distract theplayer with silence. If the game will usebackground music, tell the sounddesigner — designers won’t know thisfact unless they are also the composer.This question may jog a producer’smemory and alert the team to the factthat more than just event-driven noisesare needed. WILL CERTAIN EFFECTS HAVE PRIORITY DURING

PLAYBACK? There can be instances duringa game (a player unlocks a hidden door,stumbles into a trap, or is attacked by avillain) when a single sound punctuatesthe moment. All other sounds becomeirrelevant and this one sound takes pri-

ority. These are the ones you want tohave the biggest bang for

the buck. Sinceother

soundswon’t be drown-ing them out or playingover them, you won’t have toconsider whether other effects can beheard at the same time. It’s critical toget this type of sound perfectly, and byalerting sound designers to theseeffects, they’ll know which ones to pullout the stops for.WILL THERE BE ANY VOICE-OVERS OR SPEECH

COMMANDS THAT NEED TO BE HEARD? Similarto the way vocals must stand out in asong mix, any vocals in a game must beheard easily by players. A sound design-er can be involved with processingspeech via an equalizer or the volumecontrols to ensure they can be heardand understood over the other effects.ARE ANY NARRATIVES NEEDED? Will there bebackground sounds to accompany nar-ration? Narratives fit into the soundrecording category, and generally any-one capable of sound design can alsorecord narration. If you already havenarratives recorded, the sound designercan usually transfer these recordings

into digital files, maximize the sound,cut them to length, and add any addi-tional background or Foley sounds. Ifnarratives are to be recorded, sounddesigners need to know if they have toprovide the voice talent so they canbudget accordingly. A good question toask prospective sound designers iswhether they have any experiencedirecting narrative sessions, and if not,make it clear that the producer will fillthat role. ARE THERE ANY SPECIAL SOUND CONSIDERA-TIONS? Is the game intended to be anaudio trend setter, and use technologiessuch as Dolby Surround Sound or DTS?Are you planning to advertise the gameas having “cinema quality” sound?Knowing this ahead of time could be animportant safety tip for the sounddesigner’s longevity in the business.WHAT TYPE OF MUSIC, IF ANY, WILL PLAY AS THE

SOUNDS ARE TRIGGERED? This would givethe sound designer an indication ofwhat other sonic activity will be hap-pening during the game. If the musicwill be a soft orchestral score, youmight want the sound effects geared tothat mood, and not sound too obtru-sive. If a rock soundtrack will be played,then harsher sounds and careful manip-ulation of an effect’s higher and lowerfrequencies will ensure these stand out.The sounds should all work together toenhance game play, not aggressivelycompete with one another.ARE ANY SOUND RESOURCES AVAILABLE TO THE

SOUND DESIGNER FOR LICENSED MATERIALS?ALIEN VS. PREDATOR, STAR TREK, andSOUTH PARK, for example, are gamesbased on film or television propertiesthat were produced under licensingagreements. If the publisher or devel-oper has secured use of the actualsounds from these works, sounddesigners need to know if they have itat their disposal to manipulate for thegame, or if they are expected to recre-ate it themselves. While your sounddesigners may not have an actual handin creating them originally, they areequipped to convert them to the prop-er formats and sample rates and needto know, for planning purposes, if thisservice is desired, too.ARE ANY SPECIAL FILE NAMING CONVENTIONS

REQUIRED FOR FINAL DELIVERY OF SOUNDS? Ifthe development team is overly orga-nized, or if they waited until late inproduction to bring a sound designeron board, they may already have file


40

G A M E A U D I O

names pro-grammed into the code.

While renaming files is not a big deal,it may help cut down on any confusionwhen delivery is made if they arealready appropriately named. Thedeveloper should make this need clearor define an acceptable method.

Getting to Work

Once the sound design contractorhas been hired, the previous ques-

tions have been answered, and theappropriate nondisclosure agreementshave been signed, one or two peopleon the development team should beassigned as liaisons to the sounddesigner, who are responsible for com-municating the project specs and sign-ing off on work. This ensures clear andeffective communication, which is thekey to obtaining sounds that match theteam’s vision.

If you’re using a local contractor,have them stop by, meet the rest of thecreation team, and discuss the game. Ifthe sound designer is unavailable, sendcopies of artwork, storyboards, and any story text already written. If thereare any rough animations, movie pro-mos, or even an early version of the

game available, send those, too. There are several ways to convey

sound effect needs to the sound design-er. You could create a sound list thatdescribes each sound, what it will beused for in the game, and the requestedsound duration. This is really just a wishlist, because often the entire list isn’tcompleted for the game — changes inthe game see to that.

A producer can also indicate wheresounds are needed by giving an alphaversion of the game to the contractorthat uses place-holder sound effects(general effects-library sounds oreffects taken from other games). Place-holders can, of course, simply be spo-ken words created by someone on theteam — for a game I’m currentlyworking on, the producer insertedaudio files of himself saying wordssuch as “click,” “bonk,” “explode,” or“shot” that are triggered by the appro-priate game event. As I play the game,every time I hear his voice, I create asound to match the action.

With the preliminary action accom-plished, the sound designer has a solididea of what the game is looking forand sets out to get things organized onhis or her end. Jamey Scott, sounddesigner and composer for PrestoStudios (developers of THE JOURNEYMAN

PROJECT series, GUNDAM 0078, and oth-ers) believes putting together the initialpalette — finding sounds that will mixwell together — is the most importantstep. He uses the E-Mu Emulator 4 sam-pler in his sound design process, andfor each game he develops an entirelynew sound palette to keep them origi-nal. Scott feels that using a sampler hasadvantages over straight computer filesand sound editors. “Layering soundsinternally in the E4 works very well forme,” he says, “more so than doing iton a computer. That way, I can savemy banks as a palette rather than hav-ing sources in various folders all overthe computer. They are all looped,equalized, and noise filtered all to myspecifications. Plus, returning to themto make any changes is a simpler task.”

Soapbox Time

P roducers and developers whoknow absolutely nothing about

sound design tend to place unduedemands on the sound designer, or sim-


42

G A M E A U D I O

Here’s an example of how one

simple sound effect is creat-

ed. The project I’m currently

working on is a space strate-

gy game, in which units are maneuvered

in formation to battle against other play-

ers. It is a PC game with final sounds to

be delivered as 22KHz, 16-bit .WAV files.

I’m creating a sound which is triggered

when a shielded unit is fired upon.

The shield sound should have an

“electric” quality to it — a controlled

surge of energy that might sound as if it

were deflecting a shot from a laser

weapon. I wanted it to sound unique, so I

stayed away from stock library effects

and used one of my synthesizers for ini-

tial inspiration.

I ultimately settled on a patch, similar

to the keyboard sound in the Van Halen

song “Jump,” and recorded four seconds

of a three-note chord. I saved it into my

audio editing program, Sonic Foundry’s

Sound Forge, as a 44.1KHz, 16-bit stereo

file. Experimenting with a few different

effects processors, I found a nice Doppler

effect in another program, GoldWave. I

edited an existing patch to give it a quick

one-second Doppler increase with three

seconds of Doppler decrease. Back in

Sound Forge, I pulled up a radio static

sound file (which gives it that “electric

charge” feel), ran it through a 1Hz stereo

flange effect, and equalized it to increase

the high frequency range. I then cut that

file to four seconds to match the manipu-

lated keyboard sound and mixed the two

sounds, keeping the static barely percep-

tible. I gave the new mixed file a one-sec-

ond fade-in, and faded out the last two

seconds with a linear fade. Now it was

beginning to sound like something. I nor-

malized the file to maximize the sound,

adjusted for any abnormal level peaks

and finally saved the new file as

SHIELD.WAV.

Later, the producer wanted a dull,

metallic clank mixed in to give the player

some distinction between a shield hit and

a hit to the unit’s space suit. I pulled up a

nice clank sound, used the equalizer to

get rid of most of the high frequencies,

and mixed to the shield file. All was well;

the producer was happy.

Converting down to 22KHz is simple.

Utilizing the resample feature in my

audio editor does the trick nicely.

Because some of the higher frequencies

get lost in the conversion, I usually

adjust the equalization to compensate.

After another check on the levels, the

effect is ready for the game. Total time

spent creating this one sound effect: two

hours, 15 minutes.

A Sound Is Born

ply ask for the impossible. It is tremen-dously frustrating to negotiate and workwith those who don’t have at least abasic concept of what goes into ourprocess. One original sound can takemore than two hours to create — we’renot just taking clips from an effectslibrary disc and converting it to theneeded format. (To get an idea of thesound creation process, see the sidebar“A Sound is Born.”) An entire game canbe done in two weeks — with muchpressure on the sound designer — but itcan take a month or two just as easily.

Ensuring the Best Audio Results

W hen a sound designer devoteshis or her time exclusively to

your game for the duration of the pro-ject, it helps ensure consistent gameaudio. Ask prospective sound designersup front whether they will commitsolely to your project. The second con-cern to address with your sound design-er is that of quality assurance. All of thesound designers and many of the pro-ducers I’ve talked to insist that thesound designer listen to the sounds inthe actual game. Typically, this hap-pens around the time the game goesinto beta. It’s not uncommon for effectsto sound great in the studio but not sohot (too loud, soft, long, or short) oncethey’re synchronized with the action inthe game. While analyzing the audio inthe beta version of a game he was work-ing on, Joey Kuras discovered a pro-grammer on the project had taken oneof the effects — the sound of footsteps— and bumped up the volume. Whatwere intended to be subtle, barely dis-cernable Foley effects turned into aloud series of crunches. Thankfully,Joey’s screening session caught theproblem and corrected it in time.

Specify to your sound designer thatyou want your sound effects created inthe highest quality possible (whichtoday is usually 44.1KHz, 16-bit stereo).Because new technology is now becom-ing more mainstream, some develop-ment teams may soon opt to go evenhigher to 96KHz, 24-bit audio. Why?Because you want to develop thesounds in the highest fidelity then con-vert down to what is needed for thegame. If a game needs 22KHz, 16-bitstereo sounds and it is later discoveredit can fit in 44.1KHz, 16-bit stereo

sounds, it may already be too late forthe sound designer. Attempting to con-vert up almost always adds unaccept-able noise to a recording — you justcan’t do it. You usually have to startthe whole recording process again fromscratch.

Not too long ago, one game compa-ny decided to create a television com-mercial for its game and intended touse the original effects from the game.They contacted the sound designerwho worked on the project andrequested their sounds in a CD-qualityformat. Unfortunately, he didn’t havethem at that sample rate and proceed-ed to spend a few sleepless nights recre-ating them. It would have been just afew minutes of work had they alreadybeen available.

Presenting the Final Work

D elivering the final sound effects toa client is not usually just a mat-

ter of sending a CD or e-mailing thesounds and saying, “Here they are!”When presenting finished effects toproducers, some sound designers(myself included) send more soundsthan were actually requested by theclient. I work up several effects, let theproducer in on the process, and giveclients the chance to choose the effectthat matches their vision. Some havesubtle differences, changes in length,layering, or effects processor settings.Other sounds are completely differentbut still evoke a similar emotion oridea. This procedure actually servesdual purposes: it gives the producerradical ideas that just might work, or itmakes other effects stand out andsound that much better.

Occasionally included, if it isn’talready obvious by the file names,

is some sort of documenta-tion that describes

what each

sound effect is for. This key will savesome headaches for everyone involvedand score some points for the orga-nized sound designer.

Avoiding Production Nightmares

T here are plenty of ways that thingscan get screwed up when working

with a third-party sound designer. Forexample, the producer may not choosethe proper adjectives to describe thegame and, in turn, the description maynot mean the same thing to the sounddesigner. Or, the production could gothrough dozens of design changes,causing the sound designer to loseinterest and quit. The list of potentialproblems is endless. We’ve all had ourown experiences which we’d rather for-get, but it’s important to learn fromthem, if for no other reason than toprevent history from repeating itself.Here are some true horror stories fromthe trenches.

Mark Temple, owner and executiveproducer of Enemy Technology, hasmany games to his individual creditand he’s currently at work on his com-pany’s first game. One of his biggestpet peeves is trying to work with sounddesigners who are not computer liter-ate. Yes, believe it or not, there are stillpeople out there who don’t knowmuch beyond their immediate soundapplications. He has made several treksduring hectic schedules to visit a sounddesigner just to get a copy of a gamerunning. He’s also had to instruct themhow to zip and unzip files, attachsound files to e-mail, or use a modemto connect to the company BBS. Sonow when hiring people, he makes it apoint to ensure first that they knowtheir way around a computer.

Another time, Mark’s sound designerleft a project in the middle of the con-tract, with half of the milestones com-pleted and half of the sound effectsbudget. A new sound artist was quicklybrought in, but the effects had a differ-ent quality and it became difficult tomatch his sounds to the previous work.Reluctantly, they opted to start fromscratch, which forced them to spendmore than they had budgeted and alsobroke their schedule. People leave inthe middle of projects all the time forvarious reasons, and there are as manydifferent ways to prevent this as there

43


44

are reasons to leave. But honest com-munication and understanding of thecreative processes helps. Contractpoints, which give the proper incentive(such as increasing milestone pay-ments over the course of a project,with the largest payment for the com-pletion of all work) are another option,but overly aggressive contracts thatwithhold too much money until theend can spoil things, too. Try to findthe right balance.

A potential contract sound designer,whose work is outstanding, wanted towork on a particular game, but didn’thave the right equipment for the partic-ular project, nor the money to buy it.And because the development teamdidn’t have the resources to help himwith this purchase, he didn’t get thejob. If you find yourself in this position,talk about the situation with theprospective sound designer and see ifyou can come up with a creative solu-tion before you pass up the deal. Devel-opers have been known to loan or buyequipment for the contractor, depend-ing heavily on how badly the contrac-tor is needed and the cash flow of thedeveloper.

The idea of “one-stop shopping” fora sound designer who can also com-pose and produce music is appealing.It’s an opportunity to hire one fewerperson, saving time and money. How-ever, when Mark began his search forjust such a person, he found few avail-able. What may have helped this situa-tion would have been to have the pro-ducer looking in the right places (nooffense, Mark). If they had done anyprevious research, they could have hada list of names and demos already attheir disposal. But since that didn’tappear to be the case, there are plentyof online sites that cater to this verything, some of which are listed at theend of this article.

Here’s my horror story. A while back,I replaced a sound designer late in theproduction cycle of a fantasy game,after the producer became dissatisfiedwith the previous contractor. It seemsthe former sound designer was missinghis milestones by ever-increasingamounts, and the overall creative qual-ity of the work had declined rapidly. Asan example, for some of the spokenmagical spells used by the various wiz-ards in the game, he recorded profani-ties and simply played them back-

wards. While his “shortcut” wasn’trecognizable to the average listener,someone with audio editing softwarecould reverse it and a lawsuit coulddevelop, something this small develop-er couldn’t afford to have happen. Iwas able to step in late in the game andsecure a few points, landing the con-tract for their next two games.

Managing Outside Talent Shouldn’tBe a Mystery

A t some companies, there tends tobe a stigma attached to third-

party contractors. To some, it seems ahighly unnatural act to search beyondthe company walls after you’ve spent atremendous amount of time and effortcollecting and nurturing your own tal-ent. As you might have guessed, I takea different attitude. I’ve found thatartists are more creative in workingenvironments that they have designedfor their own purposes. Not keeping toa nine-to-five schedule actually letsthem budget their own time and workwhen they are at their best. Their hap-piness and security can be heard intheir much-inspired work, and anygame could benefit from this passion.

When it comes down to it, workingwith a contracted sound designer isnot so different from interacting withany of the full-time developers onyour staff. Graphic artists, program-mers, composers, actors, and voice tal-

ent are all looking to you for the prop-er motivation and, though the sounddesigners are not immediately withinthe corporate view, they respond tothe same proper, positive stimulus.

The key points mentioned here,when focused on, can help you achievefantastic work from a sound designcontractor. Even though there are nohard and fast rules, secret formulas, orprescribed methods for creating theconsummate assemblage of gamesound effects, it can happen. It takesfluid communication and a firm visionfrom the development team coupledwith a sound designer who shows nobounds to their creativity and patience.Together we can take on the gamingworld and keep them lining up at thestores. ■


G A M E A U D I O

T ommy Tallarico is making life

easier for both producers and

sound designers by trying to

standardize sound contracts

and the often unpredictable contract

negotiation process. With more than

125 games to his credit, he has plenty

of experience in this phase of deal-

making and after paying lawyers large

sums of money to draw up the paperwork,

he’s still willing to share. At the 1999

Game Developers Conference, he

gladly handed out copies of the agree-

ment to anyone interested. Hundreds

of people took advantage of his

generosity.

This contract, available for download

from the Game Developer web site

(http://www.gdmag.com), is a revised

copy that pertains to the sound designer

and the created effects. Many points can

be added or taken out as needed during

negotiations, since both parties are

attempting to have their best interests

represented. Whether you’re a producer

or a sound designer, I recommend you

download this file and read it over closely

so that you get a sense for what the top

talent in the field is asking for. Tallarico

has granted everyone permission to use it

as is, or merely as a guideline for sound

design deals.

The Audio Development Agreement

Places to Find Third-Party Sound Designers:Gamasutra.comhttp://www.gamasutra.com

Happy Puppyhttp://www.happypuppy.com/biz/

index.html

Dungeon Crawlhttp://developer.dungeon-crawl.com

Black Sheep Journalhttp://members.aol.com/blaksheepj

GameDev.Nethttp://www.gamedev.net/info/about

FF OO RR FF UU RR TT HH EE RR II NN FF OO

worlds without blowing milestones and spending large sumsof money? Simply put, we must have some of our game datagenerated automatically for us.

For example, suppose you’re developing an online mas-sively-multiplayer game with an enormous amount ofpolygonal terrain (hundreds of thousands of screens’ worthof in-game scenes) for thousands of players to exist in andinteract upon. In addition to that (just to make your lifemore difficult), this terrain model must conform to a loose,preexisting map specification (in other words, the generalmap layout and major landmark locations are known rela-tive to each other, but there is no concrete data set describ-ing the terrain, such as satellite imagery). This constrainteliminates the possibility of using any truly automatic ter-rain generation algorithm (such as fractal terrain genera-

tion). Meticulous construction of the terrain model byartists’ hands is completely out of the question. No group ofartists assigned this arduous task would be able to producethe desired result within the budget constraints; it will eithercost a prohibitive amount of money, or take more time thanis allotted for the development of the product. So you’re leftsearching for some kind of middle ground between thesetwo extremes.

Using manageably-sized, artist-generated bitmaps, com-bined with some clever image processing techniques, youcan create a desirable terrain model. The techniques Idescribe in this article don’t eliminate artist or world-builderinvolvement from the creation process — these techniquesonly create a model that is very close to completion in a rel-atively short amount of time. Once generated, the terrain


48

G E N E R A T I O NT E R R A I N

Using Bitmaps forAutomatic Generation ofLarge-Scale Terrain Models

bb yy KK aa ii MM aa rr tt ii nn

layers today demand a rich game experience with

larger worlds to explore, more interesting

things to do, and higher degrees of realism

with each new title that ships. The prob-

lem is that game development schedules and

budgets cannot keep pace with consumer demand for

new feature sets. So, how do we make larger, more interesting

Kai Martin is a programmer for Sierra Online, where he is currently working on, among other things, nearly all aspects of automati-cally generating an enormous landscape for MIDDLE-EARTH, a massively-multiplayer online role-playing game based on the works ofJ. R. R. Tolkien. Questions, comments, and miscellaneous musings can be directed to him at [email protected].

PP

must be fine tuned by an artist or leveldesigner to add the aesthetically pleasingfinal touches.

There are several other advantages tousing bitmaps for your terrain modeling.First and foremost, the tools for manipu-lating images (such as Photoshop) areextremely well developed and wellknown by a majority of artists. Second,the techniques I’m about to discuss willlower the ratio of time spent generatingthe terrain images to the amount of in-game data you can generate from them.Finally, this technique lets you view thelayout of the entire world within a fairlysmall area — the bitmaps we will use arefairly manageable and allow you to viewthe entire image at once on a typicalmonitor.

It’s assumed that the terrain model desired is a textured3D polygonal mesh, with the vertices lying upon a regularly-spaced rectangular grid. The terrain’s z-values (the “up” vec-tor) are taken from a two-dimensional array of values calleda height field. The terrain textures are also set according to atwo-dimensional array of values, where different valuesdenote specific types of terrain. This helps specify a textureto use for a particular cell in the terrain grid. Thus, twobitmaps are required to generate all the data needed to cre-ate terrain. In the examples provided in Figures 1a–c and2a–b, the height and terrain data bitmaps are 8-bit grayscaleand palletized color images, respectively.

Note that there are several methods by which you can usethis terrain data to create a system of connecting tiles. Forexample, you could view each terrain value as an individualtile, or view each value as a tile vertex, and so on. However,this article is strictly concerned with generating the neededdata. Showing you what to do with the data once it has beengenerated is beyond the scope of this article.

Bitmap Representation of Terrain and Elevation Data

T ranslating bitmap values into usable data is straightfor-ward, assuming you can read the file format of the

bitmap. For a given entry (x, y) in a height data bitmap, acorresponding value in the height field can be calculated bytaking the value in the bitmap and multiplying it by somescalar: heightField (x, y) = bitmap (x, y) · scaleZ. Using theterrain bitmap is even easier. Since the bitmap is 8-bit, sim-ply set the value (palette index) at any given point (x, y) inthe image to a predetermined terrain type. If more than 256terrain types are needed, you can use the RGB values of a 24-bit image for terrain type indexing instead.

While the goal is to use a large data set to generate a ter-rain model, it is unlikely that a 1:1 mapping of bitmap val-ues to height and terrain values will yield a large enoughdata set for very large game worlds. Thus, you probably willhave to “scale up” the bitmaps some way in order to gener-ate sufficient amounts of data.

There are two easy ways to scale the data gathered fromthe height bitmap. The methods rely on a two-dimensional

scale vector(scaleX, scaleY) todo the work. Thescale vector is cre-ated based on theratio of the size ofthe bitmap to thesize of the terrainmodel one wishesto create from thebitmap.

The first methodtakes each pixel (x,y) in the heightbitmap and dupli-cates the pixelvalue bitmap (x, y)inside a rectangulararea of pixelsscaleX · scaleY insize, in which the upper left corner of the rectangle equals (x · scaleX, y · scaleY). Empirically, the data becomes “pixel-lated,” as though the bitmap is viewed at a higher zoomlevel. The terrain data is scaled in this way, as well.

The second method of scaling the height data treats thebitmap values as points on an arbitrarily large surface, or ascontrol points used to generate such a surface parametrical-ly, in which each value in the height bitmap is a discretesample from this surface. For a given entry (x, y) in one’sheight-data bitmap, a corresponding value in the heightfield can be calculated using the following mappingfunction:

[x, y, bitmap (x, y)] = [scaleX · x, scaleY · y, scaleZ · bitmap (x, y)]

All we’re doing is taking a point in the height data bitmapand multiplying it by a scale vector of (scaleX, scaleY,scaleZ).

Now that the amount of raw data needed to create thefull size terrain model has been generated, one mightnotice (see Figures 1a–c, 2a–b, and 3a) that scaling the


49

F I G U R E S 2 A A N D 2 B . A. Original

elevation bitmap. B. Scaled elevation

bitmap.

F I G U R E S 1 A - C . A. Original terrain bitmap. B. Scaled terrain bitmap. C. Scaled

and smoothed terrain bitmap.

A

B

A

B C

bitmaps has created some rather harsh and unwantedartifacts in the final images. To correct these artifacts, let’suse some basic filtering techniques from the field of imageprocessing.

Basic Image Processing and Elevation Smoothing

M any image processing operations can be modeled as alinear system:

where f(x, y) and h(x, y) are the input and output images,respectively, and g(x, y) is the system’s impulse response. Toput it another way, g(x, y) is the operation upon f(x, y) thatcreates h(x, y). For such a system, the output h(x, y) is theconvolution of f(x, y) with the impulse response g(x, y),defined in discrete terms, for an N×M image, as:

If f and h are images, convolution becomes the computationof weighted sums of the image pixels. This computation isperformed using an arbitrarily-sized square table of valuescalled a convolution mask. This computation is what per-forms the actual filtering.

One of the simplest filters is implemented by a localaveraging operation where the value of each pixel isreplaced by the average of all the values in its local neigh-borhood, as determined by the size of our convolutionmask. For example, taking a 3×3 neighborhood about thepixel (i, j) yields:

If g[i, j] = 1/9 for every [i, j] in the convolution mask, theconvolution operation reduces to a local averaging of the3×3 grid of pixels centered on pixel [i, j]. Notice that for the9 pixels involved in the operation, the sum of the weights isequal to 1 (9×1/9 = 1). When an N×N convolution mask isused as an averaging filter, the size of N controls the amountof filtering. As N becomes larger, the image noise is reduced,but you also lose more image detail. So there’s a trade-off inchoosing a particular size N, and choosing the size of yourconvolution mask will depend on the amount of filteringyou need and level of detail your final image requires. Anexample of an average filter applied to a height field isshown in Figure 3b.

A Gaussian filter is similar to the averaging filter. In theGaussian filter, the values in the mask are chosen accordingto the shape of a Gaussian function. For reference, a zero-mean Gaussian function in one dimension is:

where the Gaussian spread parameter determines the widthof the Gaussian. For image processing, a two-dimensionalzero-mean discrete Gaussian function,

G i j ei j

,/[ ] =

− +( )2 2 22σ

G x e x( ) = − 2 22/ σ

h i j f k lk i

i

k j

j

, ,[ ] = [ ]= −

+

= −

+

∑ ∑19 1

1

1

1

h i j f i j g i j

f k l g i k j lk

N

l

M

, , ,

, ,

[ ] = [ ] ⋅ [ ]= [ ] ⋅ − −[ ]

= =∑ ∑

1 1

Input, linear system, Output,f x y g x y h x y, , ,( ) → ( )[ ] → ( )


T E R R A I N G E N E R A T I O N

F I G U R E 3 B . Scaled height data, filtered using the averag-

ing filter.

F I G U R E 3 A . Scaled, unfiltered height data.

F I G U R E 3 C . Scaled height data, filtered using a Gaussian

filter.

50

is used as a smoothing fil-ter. The Gaussian filter hasa few properties that makeit particularly useful forsmoothing purposes.

First, the Gaussian func-tion is rotationally sym-metric. In other words, thefunction does not favorany particular directionwhen it smooths, which isparticularly useful whenthe areas needing smooth-ing are oriented in an arbi-trary direction (not knownin advance), and there isno reason to smooth inany specific direction.

Second, the Gaussianfunction has a single lobe,which means that theGaussian filter replaces eachpixel with a weighted average of the neighboring pixelsaround it (like the averaging filter), such that a pixel’s weightdecreases monotonically with distance from the central pixel.

The filter centers on one pixel (i, j). This pixel is modifiedby: 1) Multiplying each surrounding pixel, including thecenter pixel by its respective filter weight, and adding theresulting products together. 2) Dividing the sum from stepone by the sum of the filter weights. This is the new valuefor pixel (i,j). This allows local features in the height bitmapto remain in the filtered image. Finally, the width (and thusthe degree of smoothing) is linked directly to s, so that as sincreases, so does the degree of smoothing. One can controlthis parameter to achieve a balance between the amount ofsmoothing and blurring in the final image.

There are a couple of techniques that one can employ todetermine what kind of Gaussian filter to use. If the filter isbeing calculated directly from the discrete Gaussiandistribution

where c is a normalizing constant, the equation can berewritten as

Once a value for s2 is chosen, the function can be evaluatedover the N×N area desired for the mask. For example, choos-ing s = 2 and N = 7, the above equation yields the grid ofvalues in Table 1. However, if integer values are desiredinside the mask, you can divide every value inside the maskby the value at one of the corners in the array (the smallestvalue in the mask). With this completed, and assuming thevalues are rounded appropriately, a table is created like thatshown in Table 2.

Notice that the sum of all the weights contained in theabove Gaussian masks do not equal one. Thus, the resultgiven from convolving a given section of the image by themask should be divided by the sum of the weights containedin the mask. This ensures that the mask does not affect

regions of uniform inten-sity. An example of theGaussian filter shownabove applied to a heightfield is seen in Figure 3c.

Another useful aspectof the Gaussian func-tion is the fact that it isa separable function. Inother words, a two-dimensional Gaussianconvolution can beobtained by convolvingthe bitmap with a one-dimensional Gaussianand then convolvingthe result with the sameone-dimensionalGaussian–orientedorthogonal to theGaussian used in thefirst step. Therefore,

another way to create a Gaussian filter is to approximate itby using the coefficients of the binomial expansion (youmight remember the binomial series from calculus, where itwas used to estimate integrals and roots of numbers):

In other words, use row n from Pascal’s triangle (Figure 4) asthe values for your Gaussian filter. For example, a five-pointapproximation of a Gaussian filter is:

1 4 6 4 1

This corresponds to the fifth row in Pascal’s triangle, asshown in Figure 4. This method works for filter sizes up toaround n = 10. For larger filters, the binomial coefficientsbecome too large for most images. Of course, if floating-point values can be used, you could always normalize therow by the largest value.

Depending on how much you scaled the original heightbitmap, the above smoothing methods should produce sat-isfactory results. However, for higher amounts of scaling,the amount of smoothing needed (provided by either of themethods above) might be too high to produce a smoothheight bitmap (depending on what kind of terrain modelwill be satisfactory). In doing so, there is a trade-off betweenlosing local detail from the original height bitmap (sincesmoothing reduces noise by spreading it over a larger area,making it more difuse) and generating more terrain datafrom a bitmap of given size.

Smoothing Using Curved Surfaces

W ith images that have a large amount of height varia-tion, such as a terrain that goes from a valley at sea

level to a mountain peak, the amount of smoothing neededto produce a satisfactory terrain model would be so large

10 1 2

2+( ) =

+

+

+ +

xn n

xn

xn

nx

n nL

G i j

ce

i j, /[ ] =− +( )2 2 22σ

G i j cei j

,/[ ] =

− +( )2 2 22σ


51

TA B L E 2 . Resulting table of values.

[i, j] -3 -2 -1 0 1 2 3 -3 1 2 3 3 3 2 1 -2 2 4 5 6 5 4 2 -1 3 5 6 7 6 5 3 0 3 6 7 10 7 6 3 1 3 5 6 7 6 5 3 2 2 4 5 6 5 4 2 3 1 2 3 3 3 2 1

TA B L E 1 . Grid of values.

[i, j] -3 -2 -1 0 1 2 3 -3 .105 .197 .287 .325 .287 .197 .105 -2 .197 .368 .535 .607 .535 .368 .197 -1 .287 .535 .607 .779 .607 .535 .287 0 .325 .607 .779 1.000 .779 .607 .325 1 .287 .535 .607 .779 .607 .535 .287 2 .197 .368 .535 .607 .535 .368 .197 3 .105 .197 .287 .325 .287 .197 .105

that a great amount of detail would be lost in the process —your mountains might suddenly turn into rolling hills. So adifferent approach for these images must be used. A moreobvious yet slightly more complicated method is to findsome form of surface representation from the initial set ofdata points. This can be a surface either shaped by or inter-polating through these points. There are many ways to dothis, but this discussion will be limited to creating a uniformcubic B-spline surface to achieve our goal.

Introduction to B-Splines

Iwill assume that you have some basic knowledge of para-metric curved surfaces, such as Bézier curves and surfaces.

If not, Brian Sharp’s articles on Bézier curves and surfaces(“Implementing Curved Surface Geometry,” June 1999, and“Optimizing Curved Surface Geometry,” July 1999) are avery good introduction.

You may recall that four control points define a cubicBézier curve and that 16 control points define a cubic Béziersurface. In general, a degree n Bézier curve is defined by n + 1control points, and a degree n Bézier surface is defined by (n + 1)2. However, the desired final set of elevation pointswill be much larger than a 4×4 grid. Therefore, one will needto use either a much larger degree Bézier surface, or employanother approach that will remain a third degree surfacethat allows any number of points to define it.

This is where the cubic B-spline comes in. In simpleterms, a B-spline of degree n can be thought of as a com-posite curve made up of several curve segments, each alsoof degree n, with each curve segment defined by n + 1 con-trol points. In this case, each curve segment is a thirddegree curve defined by four control points. An importantfeature of the B-spline is what’s known as “C2 continuity.”This means that at any point on the curve, the secondderivative will exist (means that no sharp points will existanywhere on the curve — a nice property to have). Todefine the B-spline as a whole, if we have m + 1 controlpoints, then we have m – 2 curve segments. Let a given curvesegment Qi be defined over the interval 0 ≤ u ≤ 1 by basisfunctions Bk(u)(k = 0,…,3) and control points pi , pi+1, pi+2, pi+3

as follows:

This should look familiar, since it’s very reminiscent of howa Bézier curve is defined. For the sake of brevity, here are thebasis functions for a cubic B-spline (if you’d like more infor-mation how the functions are actually derived, please seethe References section at the end of this article):

Since these segments are connected together to create onelarge curve, it makes sense to have a parameterization of theentire curve in terms of one parameter U, instead of havingjust a parameter u for every curve segment. Globally, U isdefined over [0, m – 2], and u defined (as one would expect)over [0, 1]. The parameter u for any given curve segment i isgiven by U – i.

Except for the end points of the B-spline curve, each con-trol point (in the case of a cubic B-spline) influences fourcurve segments, that is, control point pi influences curve seg-ments Qi –3, Qi –2, Qi –1, and Qi. The influence of each controlpoint pi over the curve at some global parameter value U is“collected” into one global function (called a blending func-tion), Ni(U).

Think of the blending function as the sum of the basisfunctions (which is similar to the basis functions used whenevaluating Bézier curves) for any given point on the curve.In formal terms, the B-spline curve Q(U) is defined by:

B uu

B uu u

B uu u u

B uu

o ( ) =+( )

( ) =− +( )

( ) =− + + +( )

( ) =

1

6

3 6 4

6

3 3 3 4

6

6

3

1

3 2

2

3 2

3

3

Q u p B ui i k kk

( ) = ( )+=

∑0

3


52

T E R R A I N G E N E R A T I O N

F I G U R E 4 . Pascal’s triangle. At the tip is the number 1,

which makes up the zeroth row. The first row (1 & 1)

contains two 1s, both formed by adding the two numbers

above them to the left and the right, in this case 1 and 0

(all numbers outside the triangle are zeros). Do the same

to create the second row: 0 + 1 = 1; 1 + 1 = 2; 1 + 0 = 1. And

the third: 0 + 1 = 1; 1 + 2 = 3; 2 + 1 = 3; 1 + 0 = 1. In this

way, the rows of the triangle go on infinitely. A number in

the triangle can also be found by n Choose r (nCr) where

n is the number of the row and r is the element in that row.

For example, in Row 3, 1 is the zeroth element, 3 is element

number 1, the next 3 is the second element, and the last

1 is the third element. The formula for nCr is shown below.

n!------------r ! ( n — r ) !

The ! symbol means factorial, or the preceding number

multiplied by all the positive integers that are smaller than

the number. 5! = 5 x 4 x 3 x 2 x 1 = 120.

where

The global function Ni(U) takes the global parameter U andconverts it to the appropriate local parameter uj for eachcurve segment involved.

As mentioned earlier, this type of B-spline is a uniform B-spline, which means that the curve consists of curve seg-ments between endpoints that are spaced equally apart(there are other types of B-splines that do not have the endsequally spaced, but we won’t worry about those here, sincewe’re dealing with a regular grid of control points). In ourcase, these ends are located at [0, 1, …, m] of U for m numberof control points. These ends will be referred to as knots (tobe consistent with any other reference one may find on B-splines). Thus, the spline curve becomes a collection of theknot intervals t0 < t1 < ··· < tm. Also, the order k (the degree +1) of a B-spline can vary, but for simplicity’s sake, we willkeep the order of our spline constant at k = 3. Now we canrecursively define a blending function Ni,k(u) of degree k overthe knot range [ti, ti + k] as follows (otherwise known as theCox de Boor algorithm):

Now that we have the definition of a B-spline curve, howdo we define a B-spline surface? Informally put, any point(u, v) on the surface is calculated by multiplying two sepa-rate curves together. Formally, let a point (u, v) on a cubic B-spline surface S defined by a grid of control points pi,j(i = 0, … , n; j = 0, … , m), and blending functions Ni,k(u)and Mj,k(v)

Now that we have basic knowledge of B-splines, applyingwhat we have learned to create our desired amount of eleva-tion data should be relatively easy. The initial set of eleva-tion points should be used as control points for the final sur-face. Next, determine the dimensions the final elevationdata should satisfy. Let our final elevation data set be s val-ues wide by t values tall. When evaluating points on the sur-face, one needs to know the change in u(du) and change inv(dv) from one point to the next, which is defined by:

The code to do all of this is available on the GameDeveloper web site, http://www.gdmag.com.

Terrain Smoothing

In smoothing the terrain bitmap, neither the straightfor-ward smoothing algorithms described above nor any

other image processing technique used for scaling orsmoothing images can be applied. All of these methods havepotential to introduce new color values into the final image,and only the terrain values contained in the original terrainbitmap can be present in the final bitmap. In this smoothingmethod, another n×n array of values centered on a pixel g[i,j] in an image g will be used to calculate the value of thepixel h[i, j] in the final image h. However, instead of using anequation or other means independent of the values con-tained in the source bitmap, the values in the n×n convolu-tion mask will be taken directly from source bitmap (specifi-cally, the n×n neighborhood surrounding pixel g[i, j]). Next,a histogram (an “inventory” of all the different values con-tained in the specific n×n area of the source bitmap) of then×n array is calculated. From this histogram, the value that ismost frequently occurring in the n×n region surrounding thepixel g[i, j] shall be the value of the pixel h[i, j].

Conclusion

The convenience of using bitmaps for generating gamedata can extend beyond just polygonal terrain genera-

tion. Other examples could be world object placement (fortrees and other vegetation), non-player character (NPC)placement (perhaps for a real-time strategy game where hun-dreds of units need to be placed for a given scenario), settingpaths for NPCs to follow, or providing any addition infor-mation about the terrain (for example, setting “off-limits”areas for certain player characters or NPCs). The number ofthings that an image can represent is virtually limitless. So,before considering creating your own custom tools for gen-erating game data, make sure that you’re not simply rein-venting the wheel by wanting to provide something that abitmap could provide just as well. ■

duns

dvmt

= =,

S u v p N u M vi j i k j kj

m

i

n

, , , ,( ) = ( ) ( )==∑∑

00

N ut u t

N uu t N u

t t

t u N u

t t

i o

i i

i ki i k

i k i

i k i k

i k i

,

,, ,

( ) =≤ ≤

( ) =−( ) ( )

−+

−( ) ( )−

+

−

+ −

+ + −

+ +

1

0

1

1

1

1 1

1

if

otherwise

N U

B u i U i

B u i U i

B u i U i

B u i U i

u U i j j

i

j

( ) =

( ) − ≤ < −

( ) − ≤ < −

( ) − ≤ <

( ) ≤ < +

= − + − =

3 0

2 1

1 2

0 3

3 2

2 1

1

1

3 0 3

( , , )K

Q U p N Uii

n

i( ) = ( )=∑

0


53

Image Filtering• Gonzalez, Rafael C., Richard E. Woods, and Ralph Gonzalez.

Digital Image Processing. New York: Addison-Wesley, 1992.

• Jain, Ramesh, and others. Machine Vision. New York:

McGraw-Hill College Division, 1995.

Curved Surfaces and Surface Interpolation• Rogers, David F. Mathematical Elements for Computer

Graphics. New York: McGraw-Hill College Division, 1989.

• Watt, Alan and Mark Watt. Advanced Animation and

Rendering Techniques: Theory and Practice. New York:

Addison-Wesley, 1992.

RR EE FF EE RR EE NN CC EE SS


54

ESCENT 3’s creation was a long and arduous task that

was both a joy and a pain. Exciting technology

coupled with inconsistent design and almost

nonexistent management had all members of

the team exhausted by the end of our 31-month

development cycle. When the game finally did ship

however, we knew we had a winner.

Developed by Parallax Software and published by Interplay Produc-

tions, DESCENT was released in 1995 and took the world by storm with

the first first-person shooter offering 360 degrees of movement. No

longer were players constrained just to walking around a 2D world —

now they had complete freedom of movement in a true 3D space.

b y J a s o n L e i g h t o n a n d

C r a i g D e r r i c k

OutrageÕs DESCENT 3

P O S T M O R T E M

Jason Leighton likes to kill time by complaining about the horrid Michigan weather cycles. When it isactually nice outside, he complains anyway. To hear his weather woes, or if you just want to talk aboutgame programming, write to [email protected]. Your e-mail is important to him, but may be monitoredfor quality assurance purposes.

When Craig Derrick isn’t off buying DVDs, he’s often writing to Jason Leighton about his weather woesand trying to convince him that all he really needs to do is to stop programming and go outside. If you needa motivational speaker or if you have a problem and no one else can help, write to [email protected].

DD

55


Players were able to fly their Pyro ship in any disorientingdirection — up, down, and everywhere — and top becamebottom, bottom became up, as players plummeted downnever-ending tunnels blasting mechanical robots and savingimprisoned miners.

This innovation in action gaming was immediately suc-cessful and garnered The Academy of Interactive Arts andSciences Best Title of 1995 and Best Computer Game of1995. And PC Gamer voted it Best Action Game in theWorld. One year later, the sequel DESCENT II was released,which added another 30 levels to the mix and improved thegame’s AI, thanks to the addition of the Guide-Bot andThief-Bot. The game ended with a cliffhanger cinematic thatalmost certainly guaranteed another sequel. That’s wherethe DESCENT 3 project began.

Who the Hell Is Outrage?

D ESCENT was developed by a small group of programmersand artists at Parallax Software in Champaign, Ill.,

headed by Mike Kulas and Matt Toschlog. After the success-ful completion of DESCENT, Toschlog moved to Ann Arbor,Mich., and established a second office for Parallax Software.He took three designers with him and hired two additionalprogrammers. Both offices then began to work simultane-ously on DESCENT II. While DESCENT II was deemed a suc-cessful project, the process of trying to get teams located intwo distant offices to work effectively together took a heavytoll on both teams. It was at that time that Matt and Mikedecided that each office should work on separate titles andeventually become separate companies. Thus, OutrageEntertainment and Volition Inc. were born.

It was another eight months before the production ofDESCENT 3 began. After the release of DESCENT II, Outrageimmediately began work on THE INFINITE ABYSS (a Windows95 version of DESCENT II, along with a new level add-on packentitled THE VERTIGO SERIES). Meanwhile, Volition concen-trated on development of FREESPACE. It wasn’t until after therelease of THE INFINITE ABYSS and DESCENT MAXIMUM (thePlaystation version of DESCENT II) that the developers here atOutrage began focusing all our energy on the design anddevelopment of DESCENT 3.

Another Sequel And Why DESCENT 3?

D ESCENT I AND II had the makings of a franchise forInterplay, and with any franchise, successful or other-

wise, sequels are sure to follow. Technology had taken a bigleap in the year and a half that DESCENT had come out:notably Windows 95 and hardware-accelerated 3D. It waseasy to see how DESCENT 3 could be dramatically improvedover its predecessors.

By the fall of 1996, we began to compile a list of featuresthat we would like to see in DESCENT 3. By November we hadcreated a design document detailing the new features thatwould be implemented for DESCENT 3 and submitted it toInterplay for approval.

The initial design and programming work on DESCENT 3began in December 1996. Some of the team had just com-

pleted work on DESCENT II – THE INFINITE ABYSS and DESCENT

MAXIMUM for Playstation, while others were involved withresearch and development for DESCENT 3, where they learnedabout new tools and technologies. We were excited abouttaking the DESCENT franchise to the next level and eager tobegin, but little did we know that our over-eagerness wouldimpair the game’s development.

About six months after starting development, we steppedback and took a long hard look at what we had and wherewe were going. Originally, it was deemed that DESCENT 3would have both a software and hardware renderer. Afterchecking out the competition, it was apparent that, if wewanted to be visually stunning (and maintain interactiveframe rates), we would either have to scale back our technol-ogy design or go with a hardware renderer only. We chosethe latter. In retrospect this was a good decision, but it wasunfortunate that we had to make it six months into thedevelopment, since many of the tools and software render-ing technology were already developed.

At this point, not only did we decide to go with a hard-ware-only renderer, we decided to scrap the engine that wehad been developing. The engine we had going was an

Outrage EntertainmentAnn Arbor, Mich.(734) 663-9120http://www.outrage.com

Release date: June 1999Intended platform: Windows 95/NT/98Project budget: $2 millionProject length: 31 monthsTeam size: 19Critical development hardware: Intel Pentiums and AMD K-6 II

processors. Each machine was equipped with a hardwareaccelerator and at least 64MB of RAM.

Critical development software: Photoshop, 3D Studio Max,Lightwave, Microsoft Visual C++ 4/5/6; rendering APIs usedinclude Sourcesafe, OpenGL, Direct 3D, and Glide; Direct Sound,Aureal, and EAX were used for the game audio.

DESCENT 3

Initial conceptual drawing of the Phoenix Interceptor.

enhanced segment engine — a portalengine that used six-sided deformedcubes to represent geometry. Essen-tially, it was the same technology usedin DESCENT II, with some additionalfeatures thrown in for improved geom-etry modeling. If we had stuck withthis engine until the game shipped, wewould have been way behind the tech-nology curve with respect to our com-petition. Instead, we went with a“room”-based engine, which allowsdesigners to create just about any geo-metrical area within a 3D modelingprogram, such as 3D Studio Max orLightwave.

Shortly thereafter, the terrain enginewas developed. We were seriously con-sidering the idea of creating outdoorareas for DESCENT 3, but we worriedabout the high polygon count associat-ed with such a large rendering dis-tance. Fortunately, we used a goodlevel-of-detail (LOD) algorithm to com-bat the frame-rate problems. Unfortun-ately, the decision to include terrainwould adversely affect the overalldesign in ways that we couldn’t possi-bly have foreseen, such as the scale ofthe terrain dictating how fast the shipappeared to move while outside.

For the next 18 months, work con-tinued on DESCENT 3 at a frantic pace.We were learning how to use our cus-tom in-house tool, D3Edit, so in theprocess we ended up creating and thenthrowing out an incredible amount ofour content — what looked cool onemonth looked dated the next. This waslargely due to the fact that we weredeveloping a cutting-edge engineat the same time we were trying todesign the game itself — a pitfallmany developers have fallen vic-tim to. Unfortunately, throwingout so much work also cost ourteam a lot in terms of our morale.What we should have done isfreeze the design of the engineabout a year before the productshipped and then worked on thegame. Unfortunately, in our lustfor sexy technology, we justcouldn’t do that.

When we finally did ship, wewere exhausted in a variety ofways. Working on the same gamefor two and a half years is emo-tionally depleting, to say the least.Although we knew the game wascool, we didn’t know how the pub-

lic (or reviewers) would receive it.Thankfully, it turned out that our fearswere unfounded — DESCENT 3 hasreceived incredibly good scores from avariety of sources, including print mag-azines and gaming web sites.

What Went Right

1.WORKING ON A SEQUEL. Working onany sequel, whether a game or

movie, has its ups and downs, andDESCENT 3 was no exception. Much ofthe joy of working on a sequel comesfrom the fact that you can improve onan already established title, and inmany cases, add features that were pre-viously impossible to do.

Knowing your target market is essen-tial to making a successful sequel. Youmust not deliver a product that com-pletely turns away your core audience,and yet enough of it must be new inorder to persuade them to purchase it.The four long years between DESCENT IIand DESCENT 3 convinced us that newtechnology alone warranted a newproduct, but we didn’t want just tocopy the previous version. DESCENT 3had to retain all of the elements thatmade its predecessors big hits and yet,creatively, be different. And therein liesthe paradox of making a sequel.

Starting with our old games’ designdocument and features list, we cata-loged elements that the team liked anddisliked about the previous games.Every item was scrutinized and brokendown into specific lists, such as art,

weapons, sounds, user interface, and soon, to determine what part of the fea-ture needed to be changed and whatneeded to be left alone. Developerssometimes do this with their competi-tion’s products when beginning devel-opment of a similar game, but nothingbeats being able to do it with your owngame because you have an intimacywith the product that outsiders are notprivy to.

2.USING A HARDWARE-ACCELERATED 3DENGINE. When development of

DESCENT 3 began in November 1996,hardware accelerators (specifically3dfx’s Voodoo 1) had just come out.Our initial design document called forDESCENT 3 to ship with a hardware andsoftware renderer, but as our aspira-tions for the graphics engine grew, sodid the need for hardware acceleration.Complex geometric rooms, robot ene-mies having nearly twice the amountof polygons and animation states com-pared to our previous games, complexoutdoor terrain, and the whiz-bangeffects expected in today’s games allnecessitated hardware acceleration.With all these features in the game andrunning at abysmal frame rates withour software renderer, it was decided,reluctantly, that we would release as ahardware-only game.

As development wore on, technolo-gy advanced and accelerators becamefaster, cheaper, and more popular witheach passing year. It seemed thatgames were coming out every weekthat sported a hardware acceleratormode or patch, but up to this point,

nothing had come out that washardware-only. We knew justby looking at our progress onthe game under accelerationthat we had a beautiful lookinggame with all the latest tech-nologies — but would anyoneactually be able to play it?

Our Christmas deadlinecame and went, but in retro-spect I feel it was for the better.If you didn’t have a hardwareaccelerator before Christmas1998, chances are you did haveit later. With the implementa-tion of Direct3D, OpenGL, andGlide, DESCENT 3 was capable ofrunning on just about everyvideo card available when itwas released. Because we took achance on technology, believed


56

P O S T M O R T E M

Conceptual drawing of the hulking Juggernaught

robot.

in our product, and slipped a bit,DESCENT 3 looks, feels, and plays like anext-generation DESCENT. And that’s allwe really wanted.

3.OUT WITH THE OLD ENGINE, IN WITH

THE NEW. As mentioned earlier,the initial plans for DESCENT 3’s graph-ics engine were to include both a soft-ware and hardware renderer. Theengine itself was to be a heavily modi-fied version of the segment (cube-based) engine used for DESCENT I and II,meaning that all geometry had to besculpted by connecting one deformablecube to another. While this enginesupported some interesting geometry,it just couldn’t handle the complexitywe had in mind for DESCENT 3’s levels.

So, six months into development westarted over on the engine, and thistime we aimed higher. We set oursights on creating what is now theFusion Engine. This engine would actu-ally be two separate engines — one forinternal settings and one for outdoorterrains — that would work togetherseamlessly. The internal “room” engineallows designers to model almost anytype of complex geometry in a pro-gram such as 3D Studio Max andimport it directly into our game editor.Once imported, designers can modifythe geometry, texture it, place objects,and light it. Designers could then takethe individual rooms and join themtogether, creating a portalized worldfor the player to fly through.

The terrain engine actually began as aprototype for another game that Jasonwas interested in developing.Unfortunately, Bungie’s MYTH beat us to

the idea, but the terrain technology wassolid enough to be incorporated intoDESCENT 3. It was based on a great paperby Peter Lindstrom and colleagues enti-tled Real-Time, Continuous Level of DetailRendering of Height Fields (from Siggraph1996 Computer Graphics Proceedings,Addison Wesley, 1996). Of course, it wasbastardized heavily to fit the needs ofDESCENT 3, but the overall concept wasthe same — create more polygonaldetail as you get closer to the groundand take away polygons when you arefarther away. After implementing thereal-time LOD technology, our framerates quadrupled.

The outdoor engine gave designersthe ability to create an internal struc-ture and its outside shell (an externalroom with the normals flipped), andplace it anywhere on the terrain. Thislet us create seamless transitionsbetween a structure within the level toan outdoor section, with absolutely noload times whatsoever. For the firsttime in DESCENT, players could actuallyleave the mine. When players cross theportal that leads from inside to outside,the game code would switch collisiondetection, rendering, and so on, to usethe terrain engine.

4.INCREDIBLE TECHNOLOGY. One ofour biggest goals in developing

DESCENT 3 was to bring the gameengine up to date. This included graph-ics, AI, sound, and multiplayer. I thinkwe hit the mark. DESCENT 3 includesjust about every whiz-bang graphicalfeature there is, the AI is very smart foran action game, and the multiplayerplays pretty well even over lagged

connections. Even though we’re not inthe first-person-shooter genre — agenre that is judged by its graphics andnetworking technology (some say atthe cost of game play) — we competefavorably with the offerings in thatarena.

5.GREAT MULTIPLAYER. We knew thatDESCENT 3 had to have the best

multiplayer right out of the box, orpeople would be disappointed andscream for our heads. Sadly, in this ageof release-once, patch-many, there area lot of games that come out thathaven’t fully tested their multiplayeraspects, and these systems are full ofbugs. Fortunately, DESCENT 3 did notsuffer from this. We spent a lot of timetesting DESCENT 3 networked gamesover a variety of conditions, bothlagged and unlagged. It was a tiresomeprocess, but in the end, I’m happy wedid it.

Another thing we did that show-cased our attention to multiplayer wasto give a whole slew of options to theplayer. We had support for IPX, TCP,DirectPlay Modem, and DirectPlaySerial. These options allowed players to connect to games using the protocolbest suited for their situation, insteadof just offering TCP as a lot of othergames do. There were also threenetwork architecture types: D3client/server, peer-to-peer, and permis-sible client/server. We did this becausewe knew we had to support theDESCENT II fans (peer-to-peer), theQUAKE and UNREAL fans (permissibleclient/server), and try to forge our ownpath with a new network technology


57

The new and improved Thief-Bot. Sparky, one of the more than 30 new robots in DESCENT 3.

(D3 client/server). We guessed that per-missible client/server would be themost popular model, simply becausethat was what players were used to. Toour surprise, it turned out that D3client/server was the most frequentlyused architecture. This architecturechanged the way lag was perceived. Ingames such as QUAKE and UNREAL,there is a noticeable delay between fir-ing the weapon and when the weaponappears on your screen. The reason isthat the client asks the server to fireand the server gives the client permis-sion to fire (hence permissible client/server). The D3 client/server is differentin that it allows you to fire right away— when you press the trigger, the laserappears immediately. The downside isthat you have to lead your opponentby your ping to the server, and some-times when the laser would hit youropponent on your screen, it wouldn’treally hit them on the server. Wefound this to be less frustrating thatthe permissible client/server way(which personally drove me crazy), andthankfully our fans agreed.

While providing players with somany options might have cost usdevelopment time, I’m confident thatwe made up for it in the satisfactionthat our customers had by being ableto customize the game to their liking.

Overall, the development team atOutrage was very energetic to work onDESCENT 3 and their dedication paid offmore than once during development.Working on a game as long as we did isalways tough going. Because we, too,are game players, it was some-times tough to be working onsomething for so long, neverquite knowing whether or notthe work you were doing wouldbe accepted by your peers with-in the industry, or more impor-tantly, by consumers and fansof the product. This all changedfor us during 1998’s E3 conven-tion.

We didn’t get confirmationfrom Interplay that we wouldbe showing the game at E3until about a month before theshow. When the word finallydid come, we shifted gears fromour production and went fullsteam towards making the bestE3 demo that we could. Thiswould be the time that the

industry would get its first glance atour game and we wanted to come out awinner. Fortunately, everything turnedout all right. The fans who got aglimpse at DESCENT 3 were very impres-sed and the comments from the presswere overwhelmingly positive.

A lot of what kept the team’s energyhigh was the amount of pride that eachperson had in their own particulardomain. The level designers wanted tomake the absolute greatest levels ever,the programmers wanted their particu-lar systems to stand out, and the artistswanted the art style of the game to beunique. So this pushed people to dotheir very best — the atmosphere wasalmost competitive. There were a cou-ple of times when things got out ofhand and egos had to be held in check,but for the most part, the individualteam members were allowed to shinewithout stepping on the toes of a fel-low colleague.

What Went Wrong

1.LACK OF DIRECTION OR VISION. Thebiggest problem on DESCENT 3

was the weak management structure.DESCENT and DESCENT II were devel-oped by small groups that workedclosely together (often in the sameroom), and as we grew to a team ofalmost twenty people, we didn’t intro-duce enough management to controlthe process. Even though people haddesignated titles, there was no realauthority attached to those titles. No

code reviews, no art reviews, no way ofsaying, “This is bad and we should begoing in a different direction.” Whatwe needed was more of a hierarchyand a systematic way to get thingsdone. People would have disagree-ments that were never settled, andthat led to bad feelings among teammembers. It would have been muchbetter if some sort of hierarchy hadbeen in place to mediate disputes, butunfortunately this didn’t materializeduring the entire development cycle ofthe game. For example, if a couple ofpeople had a problem with the way aparticular level played, there was norecourse to get that level changed.Bringing up the faults in an individ-ual’s level, system, or art would startarguments, and that got us nowhere.Next time we’ll know better. An anar-chistic development environment isgreat in theory (total freedom), butyou really do need a hierarchy of somesort, a chain of command where peo-ple know whom to go to with prob-lems. It was a painful lesson that couldhave been avoided if we had set up ourteam to be more like a company andless like a garage band.

2.NO STANDARDIZED LEVEL DESIGN

TOOLS. Another major problemon DESCENT 3 was the tools the leveldesigners used to make their levels.Some people used 3D Studio Max, someused Lightwave, and one designer evenwrote his own custom modeler fromscratch. Due to our somewhat anarchis-tic development environment, this wasseen as O.K., and not too many people

complained. However, the differ-ent tools led to inconsistent qual-ity across our game levels. Onedesigner would make great geom-etry that had bad texturing, whileanother designer would createthe opposite, especially if his toolof choice made texturing or geo-metric modeling difficult. Whatwe should have done is standard-ized using one tool (probably 3DStudio Max) and made thedesigners learn how to use itwhether or not they were com-fortable with it. This would haveallowed us to make use of certainfeatures that 3D Studio Max has(such as parametric surfaces)without worrying about whetherLightwave or the custom modelersupported that feature.


58

P O S T M O R T E M

Watch out for the dual Fusion attack of the Thresher.

After assembling their geometry, thedesigners took their rooms and mod-els, imported them into our customeditor (D3Edit), and tried to glueeverything together. Unfortunately,our editor was written by programmerswho didn’t give enough thought tothe user interface — they oftendesigned interfaces that were intuitiveto a programmer, but not to a design-er. Conversely, a designer would askfor a feature that might take a pro-grammer a long time to code, but thenthe designer wouldn’t use the featurevery much. This led to feelings thatthe designers didn’t know what theywanted, and the programmers didn’tcare enough to make things easier forthe designers. It was a vicious circlethat didn’t get cleared up until the lat-ter third of the project. Even in theshipped game you can tell which levelswere made early on and which weremade near the end of the productioncycle. The later levels are much betterlooking, have better frame rates, andgenerally have better scripts.

3.PROGRAMMERS WORKING ON DEDICAT-ED SYSTEMS. Many systems, such

as the graphics, AI, and scripting, werewritten exclusively by one person. Thisfostered a feeling of pride in a particu-lar system, but it also caught us withour guard down when we found thatone system was falling behind sched-ule. Our AI, for example, was verymuch behind schedule for the durationof the project because the programmerjust had too much to do. This caused aripple effect that was felt throughoutthe design of the game. After all, youcan’t tell how a level is going to play ifthe robots that you’re fighting aren’t

behaving at all as they should. Wecouldn’t simply add another program-mer to that particular system to helpout, because by the time the new pro-grammer became familiar with the newsystem, then his system would fallbehind. It might sound as if this was anunderstaffing problem, but it wasn’t. Itwas more of a case of “design as yougo,” where someone would suggest agreat feature and then the program-mers would implement it.Unfortunately, all these excellent fea-tures started adding up and taking atremendous amount of time to imple-ment. It would have been better ifthere were more programmers on a par-ticular system, or at least ones whowere familiar with it, so that if therewere concerns with slippage, otherpeople could have been broughtaboard to help.

4.WORKING ON A SEQUEL. Withsequels come high expectations

that can almost never be achieved com-pletely. (Just look at Star Wars: ThePhantom Menace to see what I’m talkingabout.) While we aimed high for theentire game, many times trying to meetthe varying expectations of our team(more in-level scripting and renderedcinematics), publisher (using more AIand levels), and fans (more of every-thing) resulted in half-implementedfeatures, such as our in-game cinemat-ics or items that went in untested at thelast minute (such as some Guide-Botfunctionality).

With a game so big and widely antici-pated, I’m not sure if we would haveever been able to manage everyone’sexpectations. And, one of our biggestproblems was that those expectationswere controlling the design of thegame. As developers, we should havebeen more confident in our abilities toproduce this type of game and shouldhave approached new ideas with a bitof skepticism. While I don’t dismiss thevaluable role that the fans and our pub-lisher played in the development ofDESCENT 3, we were too apt to deviatefrom our design document when otherswanted us to add features to the game.

It’s very important to stay true toyour design document and knowwhich systems are valuable. Every newfeature should be evaluated not onlyon its value to the game, but also froma production standpoint. When wedecided to create in-game cinematics, it

was simply to introduce the bossrobots. The effect was so impressivethat we decided to use the system toestablish the player’s location in thebeginning and ending of each level.This worked out so well (do you seewhere this is going?) that we used thesystem to help establish when puzzleelements were completed. This one-time only system was utilized in waysthat hadn’t been thought of before itsimplementation, which caused numer-ous problems.

5.FAST COMPANY GROWTH AND GREEN

EMPLOYEES. When we startedwork on DESCENT 3, Outrage had justeight employees on staff. Since some ofthe DESCENT II team left Ann Arbor towork at Volition during the project, weliterally had to build the team andcompany at the same time we startedproduction on the game. This resultedin a mixed bag of results ranging frompushing back larger projects or featuresuntil later in the project to adding mul-tiple tasks to someone’s already fullschedule.

One of the results of being under-staffed was the decision to contract outmost of our 3D animated door model-ing to an outside company, VectorGraphics, for completion. Our scheduleshowed that one animated door tookanywhere between three to five person-days to complete. With a design docu-ment that dictated more than 30 doorsin the game, we would have run out oftime. We made the decision to roundup all our sketches for doors and handthem over to the very capable hands ofVector Graphics. This allowed ourdesigners to concentrate on theirscheduled tasks and then add the doorslater as we received them.

What we didn’t account for were theproblems that came up because ourteams worked in different locations.(Somehow we forgot that our companywas split for this very reason.) Assem-bling our development environmentand building an editor for VectorGraphics was troublesome, and oncewe gave the editor to them, they reallydidn’t know how to use it. Our leaddesigner worked with them almostdaily to bring them up to speed and fixany file incompatibilities caused by ourconstantly evolving editor. This causedour lead designer to fall behind in hisschedule, and we had to shuffle arounddue dates for his specs and level deliv-


59

The DESCENT orb, now realized in full

3D.

erables. As we hired more people, hecaught up.

In the end, we hired an additionalnine employees, only two of whomactually had any professional gamedevelopment experience. And whileeveryone on the team gave the gametheir full attention, we definitely hadissues come up that were the result ofinexperience.

A loss of professionalism, maturity,and a standard of conduct was appar-ent during the development of DESCENT

3. Some of this was due to youngemployees who came to us directlyfrom school with no professional workexperience, while others had troubledealing with the long hours that comewith the job. This, coupled with thelack of a strong management hierar-chy, resulted in clashes over direction,seniority, and leadership on the pro-ject. More times than not, a personwould not follow the direction of thelead simply because of their personalissues with that person. This resulted inthe lack of respect for that person andthe very responsibilities that camefrom being the lead.

But our biggest problem was definite-ly with art direction. Without a dedi-cated art director on staff, we often sec-ond-guessed everyone else’s work. Eachartist and designer had specializedtasks, and without an art director tomake a final decision, art was simplyadded to the game without any formalapproval. In the beginning, we hadshow-and-tell meetings to show off thelatest work from people, but thisalmost always turned into a forum forcriticisms and led to animositybetween team members. An art directorleading us would have kept our artworkconsistent and would have been thefinal authority on all artwork-relatedmatters.END GAME DESCENT 3 was an incrediblychallenging project, to say the least.The design-as-you-go and design-by-committee aspects were a large part ofthe problem, and any future Outrageprojects will be more diligent in theirinitial design. We’ll make sure that thedesigners have absolutely the best toolsat their disposal and we’ll have bettermanagement to mediate design dis-putes. Without these problems duringthe development of DESCENT 3, I’m fair-ly confident the whole project wouldhave been a little less painful. ■


P O S T M O R T E M

about how much money is coming intothis business. Cowles/Simba projectsthat industry revenues will reach $11.6billion in 2001. These are real dollars,and I know a lot of the folks who aregetting rich in this business. Heck, Idevelop the games they’re getting richon. I’m not saying I need a new Ferrarievery year, but I’m pretty sure I’m notgetting my share when it takesme 15 years to save up for anew pickup.

So where’s the clog in thetrickle-down theory? Partof the problem beginsduring contract negotia-tions. I have this ongoingproblem of thinking theother guy wants a fair deal.The sad truth is that the lasttime I was involved in a nego-tiation where both parties wereinterested in a fair outcome waswhen I traded my kid brother awater pistol for his Slinky. Eversince, I’ve been cheated, lied to,ripped off, folded, spindled, andmutilated. It seems like almosteverybody I meet in this business is rip-ping off everybody else.

One common rip-off is the “bogusbonus” technique, and here’s how itworks. During an interview at some biggame company, they tell you howimportant the project is, how impor-tant you are to the successful comple-tion of the game, and how it’s going to

change the course of history when it’sfinished. But instead of paying youwhat you were making at your last job,they tell you they’re going to be payingbig, fat bonuses to all the team playerswhen the game ships on time. After all,they say, this makes it fair to boththem and you. So you agree.

Halfway through the project theywail about being short on cash, theylay off half the company, move thedelivery date up while adding features,and are, of course, forced to cancelbonuses. You manage to get a half-baked game out the door by working80-hour weeks, but the big, fat bonus is

long gone. The publisher got half ofyour work for free because you only gotpaid for 40 hours of those 80-hourweeks. One big company owner in L.A.has run this scam four years in a row,taking home a million-dollar bonus forhimself every single year, according tothe company’s SEC filings.

So how does an honest developeravoid this fate? Simply decide what’sthe minimum cash you want after work-ing 40 hours a week, then multiply thatby two. This is the minimum salary youcan settle for (because you’ll be working80 hours a week, remember?). If theyoffer you a bonus, ask them a few ques-tions, such as how many people gotpaid bonuses last year. You don’t really

care what the answer is, you just wantto see their reaction. If asking

questions makes themuncomfortable, soundthe red alert klaxon —

incoming bogus bonus.Another rip-off is the

“complicated conundrum”scam. This one is run by aprogrammer against theproducer. The programmeris running late on animportant part of the pro-

ject. The producer politelyasks the programmer if hiring acouple more programmers

would help get that part of theproject back on track. The pro-

grammer then explains that bringingon new hands would mean he’d have toexplain the extremely complicated codeto the new people, and by the time heexplained the whole thing he couldhave just finished it all up by himself.The producer thinks this makes sense.

As the project continues, more parts


64

b y M i k e K e l l e g h a nS O A P B O XWho’s Eating Your

Slice of the Pie?

My boss got a new Ferrari the other day,

the same day he laid off about a third

of the company. Somehow that smells

fishy to me. We’ve all heard the figures

Mike Kelleghan has a few uses for dishonest developers. Pernicious publishers he uses as filler in the cracks left by the last L.A.earthquake, malingering musicians are chopped up for kitty litter, crooked coders are ground into fertilizer for the nature preserve inthe backyard, and amoral artists are hung up as window coverings to keep out the light. Honest developers (yeah, both of you) areinvited to partake in ruminations about the good old days at [email protected].

illustration by Jackie Urbanovic

continued on page 63.

are late, until it seems like every part islate and the whole project is way offschedule. By the time the producer fig-ures out what’s going on, the project isyears late, the developer got an extrayear or two out of his or her contract,and the game ends up canned.

What’s an honest producer to do?First, keep a log of every task you assign,and the estimate to completion you getback from the developer. Calculate howfar off the actual completion date isfrom the developer’s projected date as apercentage. This is the developer’s“error rate.” Second, have the star devel-oper do about 75 percent of a giventask, and then hand it off to a junior

developer to clean up, debug, test, andfinally submit. The objective is that nosingle person is responsible for theentirety of any single task. This allowsthe junior developer to learn fromwatching the senior, frees the senior tofocus on what he or she does best, andgenerally allows honest developers togrow and expand in their specialty.

When a dastardly developer springsthe “complicated conundrum,” you canpull out the log of the developer’s errorrate. A good developer will have a verystable error rate. A poor developer, or acrooked one, will be late by differentpercentages every time. With this infor-mation you can say, “Gee, every time

you tell me how long it’s going to take,you’re wrong by x percent, so based onthese figures I can hire two new guys,have them look over your code withoutbothering you, and still have time leftover.” If your developer is a crook, thismight be a good time to duck.

The dastardly developer can’t threat-en to quit and leave your project highand dry, because you have a couple ofjunior programmers that have been fol-lowing in his or her footsteps and havea good handle on what’s going on. Firethe turkey, hire a new guru, and whenthe project finishes on time, remindthe publishers about that “on-time”bonus they promised you. ■

S O A P B O X


63

continued from page 64.

ATI Technologies 16

Auran Developments Pty. Ltd. 61

Aureal Semiconductor 11

Big Fat, Inc. 60

Black Ops Entertainment, Inc. 61

Busybox.com Inc. 46,47

Cinram 62

Conitec Datensysteme GmbH 63

Hewlett-Packard 19

Digimation 2

Duck Corp. 23

Evans & Sutherland 21

Immersion Corp. C3

Intel 5

Kinetix C2,1

MathEngine 6

Metrowerks, Inc. 27

Multigen 13

Newtek Inc. 29

Numerical Design 8

Rad Game Tools, Inc C4

Resounding Technology 60

Savannah College of Art & Design 61,62

Sound Werx 15

Vancouver Film School 62

N A M E P A G E N A M E P A G E

A D V E R T I S E R I N D E X

october 1999twvideo01.ubm-us.net/o1/vault/gd_mag_archives/gdm... · sumer 3d chips, such as...

Documents