JANUARY 1998 - twvideo01.ubm-us.nettwvideo01.ubm-us.net/o1/vault/GD_Mag_Archives/GDM_January_1998.pdf · in a love story or contemplative drama. The video game industry was breech-born,

JANUARY 1998

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

In Hollywood, reading an interviewis the most common way to findout about what's going on in astar's life. Magazines such as People,

Rolling Stone, Spin, and Interview are suc-cessful because the public wants to knowwhat's going on with the people behindthe movies and music. There's a naturalcuriosity about what projects they're cur-rently working on and what's going onin their personal lives. With the excep-tion of the rare autobiography, however,it's rare to get first-hand informationfrom well-known stars.

That's not true in the game develop-ment industry. Game developersexpound their opinions about life, theuniverse, and everything via .plan files,and outside of the academic world(where .plan and .project files wereprobably first used to keep colleaguesacross the country updated on researchprojects), this candor is fairly isolated toour industry. Some may dismiss finger-ing .plan files as an outdated mode ofcommunication now that web pages areubiquitous, but in terms of simplicityand beauty, there's nothing like purevanilla text to get your message across.

To help disseminate the contents ofthe various .plan files around the indus-try, a number of web sites have beenlaunched in the past two years, whicheffectively market .plans to the masses.A quick scan of the Stomped FingerTracker at redwood.stomped.comreveals constantly updated .plan filesfrom id, Rogue Entertainment, RitualEntertainment, Raven Software,3DRealms/Apogee, ION Storm,Quantum Axcess, and more. Over 100developers have .plan files listed on thesite, and about a quarter of those areupdated every week — quite a bit ofinformation.

At a business level, there are so manyreasons to author a .plan that it's hardto know where to begin. A good .planbrings developers closer to customers,letting consumers tap into the thoughtsand feelings of the people behind thegames. .plans build excitement forupcoming games and connect con-sumers with the creators of shippinggames. They bring game players closerto members of the development team,and they build company identity, loyal-

ty, and developer name recognition.Undoubtedly, all of these factors trans-late in some way to increased sales.

At a personal level, authoring a .plancan raise your personal stock — if it'swritten consistently and intelligently.And building name recognition withinthe industry and with customersshould be a high priority for anyonewho's serious about making a name forthemselves.

A word of caution, however.Remember that what the .plan giveth,the .plan can taketh away. Those whoforget to engage their brains beforeputting mouths in action often learntough lessons about making derogatorypublic statements on the Net. Off-the-cuff comments have been misconstrued,innocuous statements have been turnedagainst authors, and 3AM rants haveproven to be public relations messes thefollowing day. As with anything you runup the flagpole on Usenet and the Web,adopting a harsh tone or making inaccu-rate statements can get authors and theircompanies in hot water. Companieswhose developers author .plans shouldadopt guidelines that spell out whichtopics are acceptable to write about andwhich are not. This may sound authori-tarian and somewhat counter to theopen nature of .plan authorship, but italso prevents someone from exercisingpoor judgement in a .plan.

My point is this: don't overlook theobvious when you're trying to get someattention in today's crowded market-place. Web sites are great customer ser-vice tools and online productbrochures, but all too often they lacksoul. If you're management, encourage.plan authorship within your develop-ment teams' ranks. If you're creating agame and your company doesn'talready support the notion of .plans,approach management with the idea.Doesn't it make sense for you and yourcompany to do everything within yourpower to generate consumer interestand loyalty, especially when all that'srequired is a little time every week andsome space on your server? ■

G A M E D E V E L O P E R J A N U A R Y 1 9 9 8

4

P L A NG A M E

What's Your .plan?EDITOR IN CHIEF

MANAGING EDITOR

EDITORIAL ASSISTANT

EDITOR-AT-LARGE

CONTRIBUTING EDITORS

ART DIRECTOR

ADVISORY BOARD

COVER IMAGE

PUBLISHER

ASSOCIATE PUBLISHER

WESTERN REGIONAL SALESMANAGER

MARKETING MANAGER

AD. PRODUCTION COORDINATOR

DIRECTOR OF PRODUCTION

VICE PRESIDENT/CIRCULATION

GROUP CIRCULATION DIRECTOR

CIRCULATION MANAGER

CIRCULATION ASSISTANT

DIRECT MAIL MANAGER

NEWSSTAND MANAGER

REPRINTS

CEO - MILLER FREEMAN GLOBAL

CHAIRMAN - MILLER FREEMAN INC.

PRESIDENT

SENIOR VICE PRESIDENT/CFO

SENIOR VICE PRESIDENTS

VICE PRESIDENT/PRODUCTION

VICE PRESIDENT/CIRCULATION

SENIOR VICE PRESIDENT/SYSTEMS AND SOFTWARE

DIVISION

Alex [email protected]

Tor [email protected]

Wesley [email protected]

Chris [email protected]

Brian [email protected]

Josh [email protected]

Azriel [email protected]

Hal Barwood

Noah Falstein

Susan Lee-Merrow

Mark Miller

Darwin 3D

KoAnn Vikören

Cynthia A. [email protected]

Tony Andrade(415) [email protected]

Susan McDonald

Dave Perrotti

Andrew A. Mickus

Jerry M. Okabe

Mike Poplardo

Stephanie Blake

Kausha Jackson-Crain

Claudia Curcio

Eric Alekman

Stella Valdez(916) 983-6971

Tony Tillin

Marshall W. Freeman

Donald A. Pazour

Warren “Andy” Ambrose

H. Ted Bahr,

Darrell Denny,

David Nussbaum,

Galen A. Poss,

Wini D. Ragus,

Regina Starr Ridley

Andrew A. Mickus

Jerry M. Okabe

Regina Starr Ridley

Miller FreemanA United News & Media publication

www.gdmag.com

What Dave Said

I f we are to believe Dave Thielen("Goodbye For Now," Soapbox,

October 1997), then all of us in thegame industry are uneducated slothswho would do better to step aside andlet the "professional" programmers dothe job! If that is the way Mr. Thielenwants it, then scratch ULTIMA: It wasdeveloped by a young Richard Garriott.And scratch many other successfulgames while you're at it.

I have seen many games programmedby "professional" programmers. Thesegames all have "really slick code" — andthat's about it. No heart, no soul, nopassion. The game industry maychange, but it will never completelystamp out the Leonardos andMichaelangelos of the game industry.These are the hearty souls that otherindustries wish they had. They are thepioneers with the raw talent and stami-na to overcome the persecution perpe-trated by the arrogance so often seen inthe attitudes of those who deem them-selves "professional." Many of the gamesthat people love today were developedon an extremely tight budget. Howmany programmers working in otherindustries would go the extra yard to gettheir product out even though theyhadn't been paid for a month?

Concerning game publishers' will-ingness to decide for themselveswhether or not a product is worthy ofpublishing: This problem isn’t isolatedto the game industry. Publishers ingeneral have this problem. They havemany products thrust at them, andwhen a product doesn’t stand out fromthe crowd, it gets overlooked. Rejectionis part of the game; get used to it.

Concerning unqualified program-mers: Certainly there are some who areeccentric and maybe a few who are not"right" for the job. But to brand most ofthe industry as "unqualified" shows alack of reasoning.

Concerning self-taught program-mers: Every developer can benefit fromexperience working with a seniordeveloper. How can anyone invalidatean individual's desire to learn whetherit is through formal classroom or inde-pendent studies? Mr. Thielen's conceptis both unreasonable and contradictoryto many of the educational programsoffered through mainstream technolo-

gy companies. In fact, those interestedenough to spend their own time learn-ing a subject are usually more capablethan those force-fed in the classroom.If the heart, soul, and passion drivingthe individual are missing, no amountof training or experience that the indi-vidual has will help finish the project.

L a r r y D o l y n i u k

v i a E - m a i l

What Nancie Said

I feel compelled to write concerningNancie S. Martin's Soapbox (“Take the

Y Out of Computer Games,”September 1997”). My firstreaction was insultand anger, which hasquieted to mere hurtfeelings. Imagine herarticle being writtenby a Nathaniel S.Martin… imagine thesneering tone and condescend-ing attitude of the article being appliedto females, rather than males. Instead ofthis one, lonely missive in protest, youwould be flooded with e-mail, demand-ing blood payment.

The nature of video games, to date,has been largely determined by theaudience, the nature of those writingthe games, and the limitations of thehardware/software. Conflict, the heartof storytelling (which is what videogames are about), is difficult to pro-gram, except through violent, physicalactivity. Consider the complexity ofthe plot in an action movie vs. the plotin a love story or contemplative drama.

The video game industry wasbreech-born, in the spare time of realprogrammers doing “real” program-ming. It's hardly surprising that videogames appealed to those writing them.If Ms. Martin wishes for there to bevideo games that appeal to her tastes,let her write them. One of my all-timefavorite games is MYST. DOOM, and allof its spin-offs, literally leave me ill.DIABLO bores me. Granted, I do lovethe CRUSADER games, but consider theplot they have and the lengths towhich the authors went to draw theplayer into that plot. Most of my all-time favorite games involve explo-ration rather than physical action. If

her suppositions concerning what doesand does not interest men, and the dif-ferences between what men andwomen like are valid, how can sheexplain my taste, as well as my friends'taste, in video games? Women's tastesin video games are, by and large, dif-ferent from men's. Not better, notworse, merely different. However, thearea of overlap is so large, I stronglydoubt that it’s necessary to specificallytarget the female audience.

As the hardware, software, and toolsimprove, so will the overall quality andcomplexity of games of all genres. Forthat small bit of software that specifi-cally targets women, there will be plen-

ty of programmers and design-ers, probably female, to create

it. For the rest of it, I thinkthe developers should

concentrate on tellinggood stories.

J i m W i l l i a m s

v i a E - m a i l

Wal-Mart and the RSAC

A s one of the members of thecommittee who created the

RSAC ratings system, I can tell youthat one of our committee membersmet with Wal-Mart and received feed-back from their management beforemoving forward with the system. Weknew that publishers would not sup-port a system that couldn't get theminto Wal-Mart. I am therefore alarmedby your September editorial whichsuggests that RSAC ratings wouldn'tstand up to the scrutiny of the Wal-Mart management.

J o h n n y L . W i l s o n

E d i t o r - i n - C h i e f ,

C o m p u t e r G a m i n g W o r l d

E D I T O R A L E X D U N N E R E S P O N D S :

Rightfully admonished. Had I only dived

deeper into the RSAC web site

(www.rsac.org), I would have uncovered an

old press release stating that Wal-Mart was

one of the first on board to support the

RSAC ratings. While I did not attempt to

contact RSAC, my two messages with Wal-

Mart itself were not returned, so I never got

the opportunity to talk directly to store rep-

resentatives. Apologies to you and the

other RSAC committee members.

G A M E D E V E L O P E R J A N U A R Y 1 9 9 8 h t t p : / / w w w . g d m a g . c o m

6

Y O US A Y S

T

CodeWarrior Professional 2METROWERKS has just releasedCodeWarrior Professional 2, the newestversion of the company’s line of pro-gramming tools that combinesWindows- and MacOS-hosted desktoptools into a unified software develop-ment package.

CodeWarrior Professional 2 com-bines a project manager, a source-codeeditor, and a multilanguage code

browser together with compilers andlinkers. It supports development for avariety of target processors and oper-ating systems using plug-in compilersand linkers from third-party vendorsand other CodeWarrior products. Newfeatures include: project files that areinterchangeable between Windowsand MacOS, the ability to comparetwo source files and merge changes,version 2.0 of Metrowerks’ C/C++compiler, a “current target” column inthe project window, a code browserthat works across targets and subpro-jects, and subproject caching that


8

BIT BBBB LLLLN E W S F R O M T H E W O R L D

R O B E R T S D I R E C T S

W I N G

C O M M A N D E R

M O V I E .

ChrisRoberts, who cut

his teeth behind the cam-era during production of the video seg-ments of WING COMMANDER 3 and 4, stepsbehind the camera again this month asthe director of the upcoming WING

COMMANDER movie. This is Roberts' debutat the helm of a feature-length film. The$27 million movie has been picked up byTwentieth Century Fox for distribution inthe US and UK, and Roberts' own DigitalAnvil is going to create the digitalimagery for the film. No word yet on arelease date or who appears in themovie.B L I Z Z A R D S A Y S B Y E - B Y E T O

C O M M E R C I A L N E T W O R K S . With theintense popularity of Blizzard'sBattle.net, the company has announcedthat it it will not license future titles suchas STARCRAFT out to third-party networkssuch as Mpath and TEN, opting instead tohost them exclusively on their own free,proprietary network. The company alsoannounced that the site — which recent-ly reached the 1.4 millionth unique usermark — will begin serving paid banneradvertisements.P G L S I G N I N G S P O N S O R S . TEN'sProfessional Gamers League (PGL) haslined up over $2 million in sponsorshipsso far (including Levi Strauss's Dockerskhakis), and this thing looks like itmight have legs. Just as some gamedevelopers are reaching cult figure sta-tus outside of our industry, the PGL hasa good shot at turning highly-rankedplayers into recognizable figures in themainstream.

OrganicaIMPULSE has announced the completion of Organica, a new 3D modeling pro-gram that supports 3D object file formats such as Imagine, LightWave, and 3DStudio MAX.

In Organica, users build objectsin a method based loosely on themetaball concept. The programgives you 25 different magicblocks that you can put together,bend, taper, twist, shear, or resizeto meet your needs. Running inreal time, the product lets you puta high-quality 3D object togetherquickly. The images at right weremodeled in Organica by UK-baseddeveloperSyntheticDimensions fortheir upcominggame.

Organica runson Windows95/NT, and aMacOS version isscheduled forrelease in January1998. The programhas a suggestedretail price of $299.■ Impulse Inc.

Minneapolis, MN

(612) 425-0557

www.coolfun.com

I N D U S T R YW A T C HI N D U S T R YW A T C H

b y A l e x D u n n e

D

speeds multiproject builds and sup-ports browsing across subprojects.CodeWarrior Professional 2, like allCodeWarrior products, also featuresthe CodeWarrior two-machine source-level debugger. The Windows 95/NT-hosted version also features supportfor debugging Java in InternetExplorer 4.0.

CodeWarrior Professional 2 is avail-able for MacOS or Windows 95/NT,and is priced at $449.■ Metrowerks Inc.

Austin, TX

(512) 873-4700

www.metrowerks.com

fusion: VOCODEOPCODE recently released fusion:VOCODE, a cross-platform DSP plug-indesigned to enhance digital audiorecording by bringing the classic ana-log vocoder effect onto the desktop.

fusion: VOCODE launchesOpcode’s new line of DSP plug-ins,called fusion: EFFECTS. The seriesprovides a way to tailor individualsounds and add texture to mixes.VOCODE moves beyond the “hard-ware box” approach of most plug-ins(software reproductions of traditionalfunctions like reverb, chorus, andothers). It includes control featuresnot commonly found on analogboxes, including level, resonance,depth, and mix — in addition to five-band tonal control. VOCODE willalso allow you to fuse one sound’s

personality with anothers. By doingthis, distinctive effects can be gener-ated such as guitar talkboxes, robotvocals, and even pulsating rhythmparts derived from sustained chords.

fusion: VOCODE and the fusion:EFFECTS platform currently supportplug-in formats including AdobePremiere, Audiosuite, and DirectXMedia. The plug-ins run on both MacOS and Windows 95. fusion: VOCODEhas a suggested retail price of $149.95.■ Opcode Systems Inc.

Palo Alto, CA

(650) 865-3333

www.opcode.com

Shag: FurDIGIMATION is shipping Shag: Fur, anew environment plug-in for 3D StudioMAX that adds fur (and even, to somedegree, long hair) to an object’s surface.

Shag: Fur generates fur with speedwithout sacrificing realism. It doesn’tcreate geometry for individual hairs, soit works quickly. However, eventhough no real geometry is generated,the fur can cast and receive shadowsand highlights. Other features allowyou to control exactly where fur isapplied, as well as the density, color,thickness, direction, leaning, and bendof the hairs. Separate texture maps canbe used for most of these options toprovide complete control. For exam-ple, a texture map of a tiger skin canbe used for fur color, while a separatemap image is used to control wherethe hairs are thick and thin. Almost allof these functions are animatable, somotion, growth and color changes areall possible.

Shag: Fur works with 3D Studio MAX1.2 and MAX 2.0, which run onWindows NT. Shag: Fur has a list priceof $295.■ Digimation Inc.

St. Rose, LA

(504) 468-7898

www.digimation.com

h t t p : / / w w w . g d m a g . c o m J A N U A R Y 1 9 9 8 G A M E D E V E L O P E R

9

AAAA SSSS TTTT SSSSO F G A M E D E V E L O P M E N T

M A R K E T R E P O R T S S I G N A L I N D U S-

T R Y H E A L T H . Recent market reports byPC Data and InfoTech indicate that bothonline and shrinkwrap game sales are onthe uptick. First, PC Data reported thatSeptember's game software sales wereup 27.5% over the previous period a yearearlier and were growing about about40% faster than the overall software mar-ket compared to the same period in theprior year. Second, InfoTech forecast thatworldwide revenue for interactive soft-ware publishing would reach $15.8 billionand grow to $26 billion by 2001. InfoTechexpects the fastest growth to come in theInternet multiplayer arena, at an estimat-ed compound annual growth rate of morethan 70% (to $3.7 billion in revenue)through 2001. But that pales in comparisonto their estimate for packaged sales,which InfoTech predicts will reach $22.3billion that year.A N D I C O M P L A I N A B O U T

D E A D L I N E S . In conjunc-tion with the launch ofthe movie StarshipTroopers inNovember, SonyPicturesEntertainment'sImageworks createdan VRML-based game forthe film's web site (www.starshiptroop-ers.com). While the game is a just simple2D obstacle maze, what's impressive isthat the game was written, developed, andstaged in just eight weeks — by the sameteam that did the special effects for themovie itself.J I M M Y J O H N S O N , V R S P O R T S T E A M

U P . To help promote their latest title andraise money for charity, VR Sports isdonating $1 to the United Way for everycopy of JIMMY JOHNSON VR FOOTBALL '98that's sold. Kudos to VR Sports for thisgesture. We here at Game Developer arewaiting for some publisher to pick up therights to MIKE DITKA FOOTBALL '98 — youknow the one, in which the Saints' AI ishard-coded to lose every game and afterwhich Ditka exclaims "We suck!"

h

b y B r i a n H o o k G R A P H I C C O N T E N T

the procedures in place at id are notperfect, they have resulted in the time-ly shipment of several popular prod-ucts, so take this for what you will.This column is pretty dry and matter-of-fact — it’s more like a laundry list,to be honest — so while it may not beamusing and entertaining, I hopemany of you will find it informative.And just to be clear, this is not a recipefor success.

This month, I’ll be talking aboutsome of the programming methodolo-gies that we’ve used during QUAKE 2’Sdevelopment. Next month, I plan todiscuss the tools that we employ, bothsoftware and hardware, and some relat-ed issues.

Team Programming

T he programming staff at id consistsof three programmers: John

Carmack, John Cash, and myself.Programming tasks are split into threedistinct groups: graphics, game logic,and “glue.” The graphics subsystems(OpenGL and software rendering) con-sist of the actual code used to render ascene and are encapsulated into two.DLLs, REF_GL.DLL andREF_SOFT.DLL. The game logic is alsoput in a .DLL, GAMEX86.DLL, which

handles all game-specificstuff such as monster intelli-gence, weapon behavior,physics, and power-upeffects. Finally, the “glue”code, which consists of win-dow system interaction,input management, sound,CD management, networkprotocols, and other not-easy-to-categorize crud, islocated in the executable,QUAKE2.EXE.

The sweet spot for ourteam size is working out tobe three programmers. Thegraphics subsystems are mydomain; the game logic isJohn Cash’s responsibility;and the glue code is usuallymodified by any of us. JohnCarmack is the grand dicta-tor and architect — he modifies broadexpanses of all the code at any giventime and is responsible for the overallarchitecture and making sure that thepieces of QUAKE 2 fit together logicallyand efficiently.

The current triangular hierarchy thatwe have in place is extremely efficientbecause John Carmack is the absoluteruler of the programming team. Eventhough Carmack is the undisputedboss because of his position within id,both Cash and I have extreme respectfor him, and it is this respect thatallows Carmack to manage the devel-opment process effectively. It is farmore important to have respect from

your employees than arbitrary authori-ty over them. Also, by taking care ofimplementation details and minutiae,Cash and I allow Carmack to concen-trate almost exclusively on large,sweeping architectural issues.

Also, a key to making the team pro-gramming approach work, at least forid, is that John Carmack is responsiblefor both the architecture and the initialimplementation of any new technolo-gy. This lets him reconcile any unfore-seen implementation and design inter-actions that may have globalrepercussions within the code base.

Another nice thing about the delega-tion of responsibilities is that there is


11

How I Spent My Summer Vacation,

or What I Learned While Working on

QUAKE 2

lot of people in the game industry have asked me about the software devel-

opment processes used at id software, so I thought I’d take the time to

write an article about the processes and philosophies used at id software

while interspersing my own opinions and reflections on them. WhileA

Brian Hook’s last Game Developer col-umn will appear in next month’s issue.Tell him how much you’ll miss him viae-mail at [email protected].

very little adversarial competitionbetween programmers. Neither Cashnor I is presumptuous enough to chal-lenge Carmack’s dominance, and sinceCash and I work on separate subsys-tems, our work is complementaryinstead of competitive in nature. Thelines of code ownership are clearlydefined and are something with whichwe’re all very comfortable — and werespect each other enough that wedon’t feel any urge to edit someoneelse’s code. This lets us work in a realteam atmosphere, and we manage toavoid the whole “Who’s The Man?”jockeying that is so common amongcomputer programmers.

One problem that team program-ming presents is source control. Asashamed as I am to admit it, id softwaredoes not use source code control. Rightnow, this discrepancy is largely theresult of expediency. We recognize theneed for proper source control, but wehave enough of a working system thatuntil source control becomes a crisis,we won’t address the problem — espe-cially when we’re this close to shippinga product. Our next generation soft-ware hopefully will be developed com-pletely within the framework of a large-scale source control system. Personally,

however, I use MicrosoftVisual SourceSafe on mymain workstation simplybecause I like to have ahistory of my changes atall times.

Another issue that ariseswhen multiple program-mers work together is cod-ing style. It’s importantnot to get wrapped up inreligious issues such as tabsize, brace and parenthesis

placement, or indentation style— you should be able to adjustto any style, even if it irks you.Fighting battles over something as per-sonal as this simply is not worth theeffort — make some compromises andmove on.

Other coding style issues, however,are worth specifying at the outset of aproduct’s development. Standard-ization and consistency are very impor-tant when working on large projects.Files, data structures, APIs, and vari-ables should have a clean, consistent,and intuitive naming convention sothat there is little room for confusionwhen looking at someone else’s code.Static and global variables should betagged as such, be it by a prefix, suffix,or some other convention. Parameterordering should be consistent: Is a des-tination address the first or last para-meter? Are prefixes used in ssttrruucctt mem-bers? Where are global variablesdeclared and under what conditions?Are globals stuffed into a single globalstructure or just tossed out into theglobal namespace? How are manifestconstants differentiated from ccoonnsstt dec-larations? How are directory structuresorganized?

NIH

F or quite some time (over adecade now), computer scien-

tists have been talking about mod-ular software, component soft-ware, or “software ICs.” Thetheory is that programmers shouldbe able to purchase a thoroughlydebugged and optimized prepack-aged software library (who are wekidding?) from some third-partydevelopment house and just dropit into a program — voila, instantnew features and functionality.

Obviously, there is a differencebetween that theory and the harshrealities of creating a product that hasto ship to real people on a real calen-dar. Libraries are written by program-mers, and programmers are human,and humans make mistakes. Manytimes, these programmers will evenhave a different set of priorities thanyour own.

This is the crux of the problem. Thesoftware component that you pur-chased might look great on paper, butwhen you drop it into your programand then spend a week looking for abug that turns out to be a part of yournew magic software IC, well, you tendto snap out of your dream world prettyquickly. Anyone who has wanted tofirebomb Redmond, Washington, afterusing Microsoft’s DirectX knows whatI’m talking about. And when a fix forthat bug isn’t going to arrive in a time-ly fashion, you’re suddenly in the posi-tion of hacking around broken code, aprocess pleasantly known as “comingup with a workaround.” Deal withenough “workarounds,” and you’lleventually reach a cross-over pointwhere you realize that you may havebeen better off if you’d just written thecode yourself.

And bugs aren’t the only problemyou’ll encounter — there are perfor-mance issues to contend with also.With WINQUAKE, GLQUAKE, and QUAKE

2, we had to work around some prettyserious performance problems inMicrosoft’s DirectSound. DirectSoundworks the way it’s supposed to, but it’sslow enough that you get all teary-eyedremembering the days of Sound Blaster16 programming under DOS.

Finally, not only do you have tocontend with bugs and performance

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


12

issues, but there’s always the specterof flexibility. That nifty new librarymight do everything you need now,but when you’re six months intousing that library, and you must havea couple new features implemented,and the library owner isn’t amenableto adding those features… well, you’rein trouble. You now have the optionof undoing months of work andrewriting everything from scratch, atwhich point you’ve tossed awaymonths of effort, or you forego theextra functionality, which may not bea feasible alternative. And, of course,if you want to port to a developmentplatform or operating system onwhich the library is not available,you’re in deep trouble. You canaddress many of these problems bylicensing the source code to whateverlibrary you’re using, but at that pointyou’re in the position of actuallylearning someone else’s code, not tomention maintaining, extending, anddebugging it. At some point, you mayfind that you’d have been better offwriting everything yourself fromscratch.

Don’t get me wrong — I’m not say-ing that using externally developedlibraries is absolutely a bad thing, butsome tradeoffs are definitely involved.We have a hard enough time dealingwith bugs in our compiler, the Win32API, Microsoft DirectX, and hardwaredrivers without adding someone else’scode to the mix. So the unofficial poli-cy at id is that we engineer all of ourown code unless we absolutely have nochoice, such as the necessity ofdepending on DirectX. It may not be

the most effective use of our resources,but it leaves our destiny in our hands,which has a certain warm and fuzzyappeal to it.

Programming Languages

A s technology-oriented as id soft-ware is perceived, we’re actually

knuckle-dragging primates when itcomes to our programming languageof choice. We use good old ANSI C forthe majority of our development.Objective-C, a version of C withobject-oriented extensions, was thelanguage of choice for tool develop-ment back when id was usingNextStep. However, during the subse-quent move to Windows NT, id wasforced to abandon Objective-C infavor of ANSI C for these tasks. We’recurrently evaluating the performanceand robustness of OpenStep forWindows NT, and if it turns out that itdoesn’t suck, we may switch back tousing Objective-C and OpenStep fortool development.

id software still uses ANSI C for itscore development; we have severalcompelling reasons why. We stressportability, and ANSI C is about asportable as a language can get — it’savailable across a wide range of plat-forms, and most ANSI C compilers areextremely stable. ANSI C is no longerevolving at a frantic pace, so it’s stablein terms of syntax, feature set, andbehavior. Mechanisms for interfacingANSI C with other languages, such asassembler, are well-defined and pre-dictable. Compilers and developmenttools support ANSI C more than anyother language. Finally, ANSI C isa pretty WYSIWYG language —when you look at a chunk of C,you can be reasonably certainwhat kind of machine code willbe generated.

C++, on the other hand, doesnot share these wonderful fea-tures. C++ is stuck on top of Cusing the programming languageequivalent of duct tape andtwine. It’s still evolving at a dis-turbing rate. It’s being designedby a committee. Compilers andtools that support C++ are con-stantly missing features or incor-rectly implementing them, andthe language, as a whole, is so

large that understanding all of it isnearly impossible. Any given chunk ofC++ code, assuming it uses even asmall portion of the language, can gen-erate seemingly random assemblycode. While you can pick up a booksuch as Bjarne Stroustrup’s Design andEvolution of C++ to help you under-stand why C++ is such a screwed uplanguage, it still doesn’t address theissue that C++ is a screwed up lan-guage. It’s constantly evolving, gettingbigger and uglier, and pretty soon it’sgoing to implode under its ownweight.

Seven years ago, I bought BorlandTurbo C++ 1.00 the day it wasreleased (yes, I’m that big a geek), andover the course of the ensuing five orsix years I used C++ as my only pro-gramming language. In that time, Ilearned most of its weird intricacies,adjusted to them, and accepted themas necessary evils, the price I had topay for object-oriented programming.When I started working at 3DfxInteractive, I had to start using ANSIC again because I was developing aprogramming library, Glide, thatneeded to be used by a lot of develop-ers, many of whom would not befamiliar with C++.

The amazing thing to me was thatwhen I switched back to ANSI C, I wasactually happier — I discovered a new-found appreciation for ANSI C’s sim-plicity (at least compared to C++).Sure, I lost some nice syntactic sugar,and I ended up missing classes and vir-tual functions a bit, but I was willingto eschew these niceties in return forsimplicity. By using ANSI C, I neverhad to crack open a reference book,



14

and I rarely had to work around lan-guage quirks. Since then, I’ve donevery little serious C++ programming,and the last time I looked at the spec,it was a completely different language.The language has mutated so muchover time that it’s become theHighlander 2 of programming lan-guages — you can see similar themesand names, but somehow the new ver-sion screws up so badly that it sulliesthe name of its parent.

id’s use of assembly language hasvaried over the years. DOOM had verylittle assembly language in it, but itwas primarily targeted at 486-classprocessors, where scheduling, pipelin-ing, and memory bandwidth issueswere not nearly as relevant as on latergenerations of processors. QUAKE, onthe other hand, was targeted at IntelPentium-class processors, and as aresult, there was significant room forhand-coded assembly optimization. Italso helped that Michael Abrash, Mr.Assembly Optimization Dude, wasworking at id then, and could devotelarge chunks of time to tweakinginner loops.

QUAKE 2 is also targeted at thePentium, and thus benefits fromassembly coding. However, there is avery significant chance that there

will be little to no assem-bly code in post-QUAKE 2products from id software.There are several reasonsfor this, the primary onebeing that hand codingfor advanced processorssuch as the Intel PentiumPro and Pentium II isoften a lost cause. At anygiven time, a Pentium Procan have a large amountof non-deterministicinternal state that radical-ly affects the efficiency ofhand-coded assembly lan-guage. With theseadvanced, superscalar,and superpipelinedprocessors that supportfeatures such as specula-tive, out-of-order execu-tion and branch predic-tion, it makes far moresense to use CPU-friendlyalgorithms as opposed toCPU-optimized code.

Optimization

O ur optimization rules are quitesimple: make sure that what

you’re optimizing makes a difference,don’t optimize before you’re doneimplementing features, and learn tooptimize up to the point of diminish-ing returns but no further. It’s amazinghow badly our intuition can deceive uswhen it comes to finding execution hotspots. You’ll often look at a programand intuitively label certain areas asdefinite bottlenecks only to find out,after analytical profiling, that someother heretofore-unknown hot spot isactually consuming all of your execu-tion time. Before diving into “prob-lem” routines, use a profilersuch as Intel VTune,Tracepoint HiProf, orRational Visual Quantify(skip the one in MicrosoftVisual C++, it's pretty muchuseless) to make sure thatyou are, in fact, going toedit code that makes a dif-ference in your program’soverall execution time.QUAKE had a hand-opti-mized routine responsiblefor clearing the screen to a

flat color. This routine only would becalled if the game had texture mappingdisabled. Optimizing that clear routineprobably wasn’t time well spent.

It’s easy to get sidetracked into opti-mizing a chunk of code that you’reworking on while you’re still thinkingabout it, then tossing away all of thateffort when you change your algo-rithms yet again. Until your overalldesign is set in stone, it’s wise to avoiddoing any optimization at all. I had achunk of code that I was pretty confi-dent wouldn’t need to be changedagain — it was responsible for trans-forming the points within an Aliasmodel — but as luck would have it, twomonths after I optimized that routine,we ended up needing a new featurethat required editing the optimizedsource. Luckily, this wasn’t overly trau-matic, but if it had been even a bitmore complex, it would have con-sumed far more time than if I had justdone all the optimization closer to theend of QUAKE 2’s development.

Premature optimization also hasanother, more sinister, side effect — itmakes you reluctant to make majorchanges to your overall design if itmeans rendering your previous opti-mization work irrelevant. A similaradage exists in the world of creativewriting — don’t keep a bad paragraphjust because it has a great sentence. Theonset of this mentality can often bevery subtle as you start unconsciouslyweighing the benefits of a potentiallybetter design against the hassle ofrewriting your cherished code.

Finally, make sure that you aren’tspending more time optimizing a spe-cific chunk of code than is truly neces-sary. In my experience, the biggestgains during optimization come withinthe first 25% or so of the time spent —after that the increases are only incre-



16

mental. There’s a cross-over pointwhere the extra effort spent optimizinga piece of code is not reaping commen-surate increases in performance. Ourblanket policy is that we wait until thefinal stretch — all features implement-ed — before doing serious “no retreat,no surrender” optimization work —stuff that requires lots of work and thatwill end up being wasted time if wechange higher-level algorithms anddata structures.

Portability

O ne of the nice benefits of usingANSI C is that our product porta-

bility is limited only by our coding dis-cipline. Throughout the developmentof QUAKE 2 a lot of thought was putinto the issue of portability, and byadhering to some general rules, wemake our lives a lot simpler when per-forming a port: segregate OS-specificcode from the rest of the code base,always maintain a C-only version ofyour code, avoid compiler and operat-ing system dependencies, and watchfor endianess assumptions.

The first step in writing portablecode is recognizing appropriate levelsof abstraction and managing your codeappropriately. The bulk of our softwarerendering and sound code only oper-ates on memory addresses — the con-cepts of DIB sections, DirectDraw, wavesound, and DirectSound aren’t knownto the actual graphics and sound-gen-eration code, and are instead handledby abstracted glue code. All OS-specificcode is sequestered into a set of welldefined files — porting QUAKE 2 to annew platform involves touching lessthan a dozen files, each dealing withsome OS-specific subsystem (CD audio,

OpenGL, software render-ing, window system man-agement, input handling,sound output, and OS-spe-cific utility routines, such astime routines). By doingabstractions at this level, wecan greatly minimize thenumber of conditional com-pilation directives in ourmain code body. As a matterof fact, the statement ##iiffddeeffWWIINN3322 only occurs twice in allof our OpenGL code, and it

doesn’t occur at all in thesoftware rendering subsystem.

We always keep up-to-date C-onlyversions of our assembly code, both toassist in porting and also because itmakes debugging the assembly codeextremely easy. It’s really easy to forgetto maintain your C-only paths, but itdoes pay off the moment you try to getthings up and running on anotheroperating system or CPU.

It’s easy to get sucked into compilerand operating system dependencies —for example, utilizing a compiler’s##pprraaggmmaa directives, or maybe an operat-ing system’s message box or memorymanagement functions. Unfortunately,##pprraaggmmaa directives are extremely usefulfor a lot of reasons, and it’s easy to for-get to bracket them with the appropri-ate preprocessor directives. The easiestway to avoid operating system depen-dencies in your main body of code is tomake sure that you’re not includingany OS-specific header files (for exam-ple, WINDOWS.H) — the compilershould complain when you start mak-ing calls that it doesn’t recognize, suchas MMeessssaaggeeBBooxx or VViirrttuuaallAAlllloocc.

Bugs related to CPU endianess can bepretty hard to find, so the best way toprevent them is to recognize codethat’s doing bad things — for example,casting between different sizetypes. A beneficial side effect ofporting to many platforms isthat it also forces you to writemuch cleaner and more robustcode, since hidden bugs in yourcode may only manifest them-selves on another compiler,operating system, or CPU. Youderive a feeling of confidencefrom knowing that your codehas compiled and run success-fully across a wide range ofoperating systems, compilers,

and CPUs. We had a divide-by-zero bugthat only generated an exception onthe DEC Alpha processor, and it wouldhave been a very long time before thisbug was detected in our code under anIntel x86 processor.

However, there are some prettysolid business reasons not to port agame to multiple platforms. WithQUAKE 2 we plan on supportingWin32 (x86), Win32 (DEC Alpha),Linux (various CPUs), SGI Irix (MIPS),and Rhapsody (x86 and PowerPC).Our publisher will likely receive a dis-proportionately higher number ofsupport calls for the non-Intel/non-Win32 versions of QUAKE 2 if werelease these versions on the QUAKE 2CD. Couple this with the fact thatports will probably account for lessthan 3% of our overall revenue, andthe argument for supporting a pletho-ra of system architectures becomespretty flimsy.

We do it anyway, though, becauseit’s cool.

In the end, porting to alternatearchitectures simply doesn’t make verygood business sense for most gamecompanies. We do our ports for onlythree simple reasons: it’s easy to do, welike seeing our games played by asmany people as possible, and we gainthe intangible benefit of havingextremely loyal consumers on systemswith poor mainstream support.

Stay Tuned

B ecause the story is just so darnbig, I’ve had to save some for

later. Tune in to this space next monthfor more on QUAKE 2. I’ll be explainingthe tool choices that we made, compli-menting some vendors, and denigrat-ing a few more. ■



18

b y J o s h W h i t e A R T I S T ’ S V I E W

course there isn’t an array of perfecttools out there yet.

The future is what scares me. Evenwhen tool makers listen, we artistsaren’t talking. Our tools aren’t going toget any better unless professionalartists explain their needs in a way thattool makers can understand. I’m onlyone artist in the industry. Tool makersneed to hear from other artists (or elsewe’ll get a Josh-centric tool — or morelikely, the brush-off). So, RT3D artists,tell me what’s wrong with your tools([email protected]), and I’ll publi-cize the gist of it. I’ll start with mymain issues.3D ART TOOLS AREN’T VERSATILE ENOUGH.Artists have a reputation as being inde-pendent (if not downright weird), andthat’s critical to art. RT3D artists’ toolsare forcing us all to work in very simi-lar patterns. That’s wrong. Artists needmany different ways of doing the samething — especially the small variationson the same basic idea. In writing, it’sobviously critical; imagine how lamewriting would be if an author couldonly use “good” instead of great, won-derful, terrific, excellent, amazing,superb, awesome, or stunning.

I’m talking about synonyms of fea-tures — multiple similar features. “Richfeature set” refers to a variety of fea-tures; that’s not what I mean. Forexample, AutoCAD’s hardly a world-standard for art tool excellence, butwhen AutoCAD users pick a point,their options are plentiful. They canuse over a dozen object snaps, includ-ing weird ones such as “tangent” and“perpendicular,” grid snaps, constraintto an axis or plane, offset from anexisting point (in polar or planar coor-

dinate systems), composition of thepoint from the coordinates of severalothers (“X from point B, but YZ frompoint C”), or completely custom func-tions via the built-in macro language.

Most technical 3D modeling soft-ware (SDRC I-DEAS, AutoCAD,PATRAN) lets the user choose a symbolto represent a point: a cross, a dot, abox, or a text label. This is unusual in3D art tools; we get only one choice for

vertex viewing. (Nitpicky? On-screenimage matters a lot to artists. For exam-ple, little “+” signs can easily draw overshort edges, obscuring subtle detail inthe mesh.) Even Windows 95 offersControl-S, Alt-F-S, mouse clicks, andcombinations of menu shortcut keypresses and mouse clicks. If you lovemouse and toolbar approaches, youshould have those options.

Clearly, tool developers face a majorchallenge. But they would be wise toaddress a few specific problems. Forinstance, developers have long lists ofplanned improvements to their prod-ucts, and sexy, major features make formore impressive advertising copy (orso they think). I suspect they would

consider my set of feature synonyms asmall “core functionality” improve-ment that would take significant devel-opment effort, and it’d get delayedendlessly.

Of course, these multiple interfacepaths to the same database edit startmaking developers’ flow charts looklike spider webs. This flexibility iswhere the underlying architecture ofthe software shows. If the software was-

n’t well designed and cleanly coded,it’s very difficult for the tool maker toavoid bugs when implementing thistype of new feature.

It’s damned hard to present the userwith a ton of different methods with-out overwhelming an already-compli-cated UI, and I think most tool devel-opers are overly focused on “easy touse” — they’re assuming artists won’tbother to learn their tool if they addtoo many features. Unfortunately, 3Dart tools often take the worst of theWindows UI and then strip out theversatility that makes it valuable. InMicrosoft Word, darn near every func-tion in the whole program is accessi-ble via the keyboard, either through


21

Part 1: Real-time

3D Art Tools Need Help!

C all me cranky, but I have something to say: we artists, especially low-

polygon modelers, have tools that are holding us back... and they aren’t

going to get better without our help. In a way, that’s to be expected; the

job title “real-time 3D artist” (RT3D) is only a couple of years old, so of

Artists have a reputation of being indepen-dent (if not downright weird) and that’s part-ly what makes great art. We need tools withlarge ‘vocabulary’ to express it.

Josh White runs Vector Graphics, a real-time 3D art production company. He wroteDesigning 3D Graphics (Wiley Computer Publishing, 1996), he has spoken at theCGDC and cofounded the CGA, an open association of computer game artists. Youcan reach him at [email protected].

menu shortcuts or with customizableshortcut keys. For example, there’s nodirect keyboard shortcut to changethe font of a style, but you can use themenu shortcuts (Alt-O,S,M,O,F). Thissequence is hardly intuitive, but if youforget it, you can look at the menusfor a reminder. If you’re a fast typist,six keystrokes are much faster andmore reliable than six mouse pointand clicks.

In most 3D art software UIs, themajority of the powerful editing com-mands are only accessible throughmouse-clicked toolbars. This requiresaccurate, repetitious mouse move-ment as you navigate through roll-ups and drop-down lists. Witness thelame “keyboard input” windowswhere you can type in coordinates,but you have to mouse over and clickexactly on the “+” roll-up button useit. It’s better than no keyboard inputat all, but it’s hardly an alternative tomouse movement.IT’S MY WORKSPACE — LET ME ARRANGE IT!The hundreds of buttons packed ontothe screen are impressive at tradeshows, and for new users, they’re con-venient reminders of a function’s exis-tence. For experienced users, however,they waste desktop space. Who usestoolbar buttons for Cut/Copy/Paste?Naturally, you want to remove them tosave space (as well as declutter yourwork area), but in most mainstream 3Dart software with nonstandard toolbars,this is impossible.

To me, an easy-to-learn but inflexibleinterface shows that the tool makerdoubts its users’ commitment to itstool. The tool is hard-wired to be E-Z,which means it’s meant only for userswho aren’t going to use it for long — aself-fulfilling prophecy.INNOVATE! Incremental improvementsare good, but tool makers also need togo out on a limb, design-wise. There’sno really smooth, easy-to-use interfacefor 3D modeling — until one exists,any convergence in software is prema-ture (and dangerous to market leaders,since it makes space for upstarts tostage revolutions). Artists need to be apart of this design process. Unlessyou’re 100% happy with the tools

you’re using, remember to keep anopen mind about new tools. One prac-tical way to do this is by keeping a wishlist. Whenever you find yourself gnash-ing your teeth about some 3D model-ing problem, pop up Notepad and jotdown the annoyance.

Then tell people who care. Attend atleast one trade show and when the salespeople attack you, attack right backwith the wish list. You may not find the

perfect tool, but by asking for specificfeatures, you’re giving feedback to thetool makers... and before long, you’llfind yourself confronted with a dozendifferent paradigms for 3D modeling.BORROW FEATURES. I want tool makers toincorporate (and improve on) competi-tors’ good ideas shamelessly. The sameapplies for 3D modeling in other indus-tries. Take a look at custom 3D soft-

ware for aerospace, training simula-tion, mechanical engineering, GIS,medical, and other specialized indus-tries. Skim off the few great ideas. We’llthank you for it.COMPATIBILITY. There are two forms ofcompatibility I think about: data trans-fer and backwards-compatibility (alsocalled legacy issues). The first is critical,not very sexy, and very difficult (nowonder so few tools do a good job ofit), but without a robust way to getdata in and out of a modeling tool, it’suseless. Tool makers need to improvethis by agreeing on a common file for-mat (for example, VRML for RT3D) andwriting really solid input/output func-tions for it. If you make it a plug-in,distribute source code so that develop-ers can understand what you did.

After a few years of gradual improve-ments, 3D art tools are often rebuiltentirely, retaining only the name ofthe last product. The transition istough, both for tool makers (who risktheir user base) and users (who feel

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


22

When paying customers need their product towork differently, tool makers listen closely.

T he top-down structure of large

software companies operates

on the architect/contractor

model. The product architect

assembles customer surveys into a clean

new product design, which is then thrown

over the wall to a complacent, obedient

programming department that never sees

the actual customer (or even knows how

to use the product it constructs).

The defending argument goes, “half-

finished ‘good ideas’ aren’t going to help

a project this size.” The only true gods

are the schedule and the specifications.

These companies don’t want freewheel-

ing cowboy coders who actually have

used the product and can form their own

opinions. A plague of feature creep (the

development of weird, sometimes bril-

liant, new features that weren’t in the

spec) will curse their clean environments

and incite revolution among the other

coders. The feeling is mutual: Creative

developers are scared away because

developing other people’s design is not a

creative job.

This leaves behind a group of calm,

balanced professionals who are extreme

team players, but don’t ever get to create

their own designs. If you’ve ever met the

staff of a really successful project, you

know why I find this upsetting — they’re

talented and organized, but not calm, and

they definitely build their own designs.

It’s true that feature creep hurts timely

production, but the alternatives are

worse. Complacent, user-ignorant pro-

grammers turn out bland, bloated prod-

ucts that don’t meet the needs of their

users. The teams are missing that intense

focus, that deep desire that motivates in

a way money never can.

To fix this, we don’t need a revolution,

but we do need change. One way is get

face-to-face with users. For example, cele-

brate beta ship dates with field trips to

customer sites. Regularly sit down with

users and watch them work, offering sug-

gestions and getting input. Key developers

can adopt a client and work onsite once a

month. If the wall between Research and

Development falls, then tool programmers

will understand their users, and the soft-

ware will improve mightily.

Research & Development: Break Down the Wall

abandoned). Still, I’m impressed withtool makers who have the guts tothrow away old code — it makes forbetter software. Ideally, tool architec-ture allows sections to be rebuilt with-out disturbing the remaining parts.

As a user, I can digest an incrementalimprovement (that is, tools createdfrom a section-by-section rebuild)much more easily than a complete rev-olution every year, but this incremen-tal approach usually introduces newbugs galore. Once old code is thrownaway, I think most tool makers do agood job of compromising betweennew functionality and old workingmethods.ENGINEERS, USE YOUR OWN TOOLS. If you’re aprofessional full-time tool program-mer, your company should be beggingyou to use your tool as the customerwould. I’m always amazed to meet tooldevelopers who don’t. Lots of program-mers grumpily call this “marketing”and think it’s not their problem. I sayit’s the “R” in R&D, and it’s critical tomaking killer tools. See “Research &Development: Break Down the Wall.” ADVICE TO ARTISTS. Artists, tool makersneed your help. We artists are tooquiet. We aren’t asking for better thanwhat we have. This is bad because pro-fessional tool makers will never betruly clued in to our needs. Withoutour input, they will assume they’redoing fine, and we’ll keep gettingmediocre tools.

Though you probably can’t guess itfrom this column, I’m very grateful totool makers for providing me any-thing that makes my job easier. Myway of thanking them is to tell themall the problems the tool has. Rude?Actually, that input (and, of course,payment for the tool) is the mostvaluable thing a user can offer a toolmaker. When paying customers needtheir product to work differently, toolmakers listen closely.

If you do RT3D modeling with gen-eral-purpose 3D tools, tool makersneed to know how you use their soft-ware — they probably think you rendermovies with it. Even tool makers whoare specialized in their attempts tomake tools for RT3D need input badly— a lot of their previous customerswere building from blueprints, notpencil sketches.

If you use 3D software regularly, youshould write the people who make it

and tell them what you think. E-mailthem, call them, visit trade shows andtell them in person. If you’re doingsomething new such as RT3D, thesqueaky wheel gets the grease — andwe seriously need some grease here.

OK, flame off. Let’s actually build thathuman character we started last time.

Part II: Low-polygon CharacterModeling

If you’ve joined us from last monthwhere we designed a RT3D charac-

ter, you’ll know that we’ve got 500 tex-tured triangles with which to make our


23

F I G U R E 1 . Character design sketch.

character come alive. We also have aclearly defined character, shown inFigure 1, and enough specifics aboutour environment that we can actuallybuild a model.

Last month, we decided on ourapproach (including mapping meth-ods and face counts on a per-partbasis), identified important areas, anddivided up our budgets accordingly.So our task at hand is building a tex-tured 3D model from our sketch andwithin our face count budget. Here’show we’ll tackle it: • Create the rough geometry. We’ll

walk through building the head stepby step.

• Tune the 3D model to perfection.• Paint textures on each part.• Map the parts together into a com-

plete model.After that, we’ll

get into animationand revisions.We’ll link theparts into a hierar-chy, place pivots,and adjust jointdesigns as neces-sary. Finally, we’llshow our work inthe applicationand do revisionsuntil the model isapproved andcompleted.FIRST-PASS MODEL-ING. Though weusually start withexisting geometry

and modify it, if we have to creategeometry from thin air, we start withlow-polygon primitives and move ver-tices, divide edges, and weld vertices inan iterative loop. Note that the illustra-tions here show complete heads, butwe usually erase half of the geometrybefore we start rough modeling, thenmirror the existing geometry occasion-ally to see how it really looks. Afterwe’ve taken a look, we erase the mir-rored half and keep working. Oncewe’re done, we mirror the geometryone last time and weld up unnecessaryvertices at the centerline.

Start with a simple sphere with theapproximately correct face count, asshown in Figure 2. In a top view, thisone has 12 pie slices and four height-lines between the poles, using 96

faces. Now we’ll mush this geometryaround until it looks like a face.That’s easier said than done. Start bylooking at the source art carefully andforming a profile along the edge ofthe sphere in the Left view, as shownin Figure 3. We do this by movingvertices, dividing a few edges as nec-essary to get the unique features ofthe profile. Next, we rotate the viewand keep moving vertices, turningand dividing edges to define majorfeatures. Push a few vertices in for aneye socket, which also forms a bridgefor the nose (Figure 4). From there,work the cheekbones a bit and formthe chin. For the chin we can changethe lowest height-line of vertices to asemi-diagonal edge of the chin. Thatlooks better, but it leaves the under-chin/neck area hurting. We’ll fix it bydividing a couple of edges, which cre-ates new vertices in approximatelythe right area. Move those new ver-tices to define the jaw/neck intersec-tion, turning any edges that connectdirectly below the chin so those ver-tices define the corner in profile (Leftview). It should now look somethinglike Figure 5.HEAD COVERAGE. As we look at the sketch,we run into a typical situation: we for-got to plan for accessories. How shouldwe handle the hat in the sketch? Beingconscientious artists, we stop model-ing and get back into planning modefor a minute. If we build the hat aspart of the head (as long as the charac-ter doesn’t ever need to bare his head),we’ll have better performance and less



24

F I G U R E 4 . Eye socket formed.

F I G U R E 2 . Basic sphere for head modeling.

F I G U R E 3 . Head profile defined in Left view.

work. After consulting with the artdirector and game designer, our deci-sion is to model the hair and hat aspart of the head.

To build the hat, we grab the top ofthe head’s vertices, move them so theyform a diagonal line in the Left view,and scale them a little larger. Then weselect a row of four edges near the hair-line and extrude them out to form thebill of the cap. Note that these edgesaren’t perfectly horizontal; they curvearound the face somewhat. This isclearly visible in the side view wherewe see that the profile of the bill issomewhat bulky. This gives us a nicethick-looking bill, even though wedidn’t spend faces modeling the thick-ness of the bill.

Once we’ve got the head roughedout (Figure 6), we mirror it, stand back,and compare it to our thumb just likereal artists. Close one eye and makesure the model doesn’t look like yourthumb. After you’ve taken a look, erasethat mirrored half — we’re not readyfor that yet.MEANWHILE, BACK IN YOUR MIND....Throughout this mushy geometryediting, we’ll constantly be revisitingour design decisions. Specifically,we’ll need to review which detailsneed to be 3D geometry, and whichcan be shown in textures. This is abasic decision that was effectivelymade early on when we sketched thewireframe outline over the pencilsketch; everything not represented bya vertex is assumed to be in the tex-ture. Now that we have the actualmodel, we’ll want to make sure those

decisions still make sense (and changeour minds as appropriate). For exam-ple, you’ll notice that we don’t haveany geometry for the mouth opening— that’s because it will look fine as atexture map. The eye sockets, on theother hand, need some 3D depth tolook good.

We also need to remember to keepmaterial boundaries represented ingeometry. Though it’s not an issue forthis example, we often need to showexpressions on our character. This iscommonly done by swapping facialtextures at run-time. In that case, we’ddo two things: 1) Separate the hat and hair textures

from the facial texture. Why? Sowe don’t waste texture memoryduplicating the hat and hairimages in eachfacial expres-sion texture.

2) Make edgesbetween theanimatingfacial area andthe rest of thehead. Sinceeach polygoncan have onlyone texturemap, we needseparate facesto map thefacial anima-tion area onto.

SECOND-PASS MODEL-ING: TWEAKING. Nowit’s time to tunethe rough model.

This phase is the pleasant pause afterthe mad thrashing. Calmly and careful-ly, we hone the model into a fine workof art. Often, artists will create texturemaps before doing this second pass onthe 3D model. It’s a personal thing —either way works, but since we haven’teven addressed material boundariesyet, this example will do second-passmodeling before texturing.

At this point, we need to take amore critical look at the overall pro-portions, adjusting features to moreclosely match the sketch. For exam-ple, this is a good time to scale thewidth of the head down a bit sinceheads aren’t usually as sphere-shapedas our model. We’ll also move verticesin the mouth area so that it looksmore like that of an old man; right



26F I G U R E 6 . Rough model completed.

F I G U R E 7. Modeling completed.

F I G U R E 5 . Chin, cheeks, and nose formed.

now the chin and cheeks look tootaut and young.

We also need to fix the face count— we’ll compensate for some of thefaces that we added with all thoseedge divisions by removing faces

that aren’t defining critical detail.For example, the base of the neck hasfar too many vertices, especiallysince it will be hidden inside thetorso. We’ll get rid of about half ofthem now.

Let’s revisit the design and see ifwe’re on track. Specific steps duringsecond-pass modeling are simply itera-tions of the same types of commandswe used in rough modeling, exceptthat the changes are more subtle.Instead of stomping an eye socket out asmooth sphere, we’ll be slightly adjust-ing the depth of the socket. The fin-ished geometry should look somethinglike Figure 7.TEXTURE MAP CREATION. Creating texturesfrom the pencil sketch is relativelystraightforward 2D artwork — essen-tially, we want to paint full-color,detailed versions of the pencil sketch.There aren’t many technical issues thatare unique to character texture cre-ation, but let’s go through the process.

We could paint the entire frontview in a single texture just like thesketch, but this wastes precious tex-ture memory in white space aroundthe arms. So we’ll create one texturefor each body part. This approach alsoallows us to use unique (nonsymmet-rical) texture for the torso, yet re-usethe arm and leg textures on the leftand right sides.

Good lighting is critical to good tex-tures. Keep in mind, however, thatcreating lights in the textures beforewe have the environment can be adangerous step to take. If you photo-graph a red cotton shirt under spot-lights and then paste it over a dimlylit room, the shirt will look like shinyred plastic because the white high-lights in the photo won’t match theroom’s lighting. This is especially truewhen the image is so tiny that youcan’t see the threads in the cloth.Often, the easiest and most versatilesolution is to avoid hot spots (brightor white reflections) on non-shinymaterials — skin, denim, cotton, andthe like should be pretty uniformly lit.



28

Meet Scared Sam, the artist

who builds 100,000-face

human models for TV

commercials. Sam

believes that it’s impossible to build any

kind of human model with only 500

faces. “Hah!” we reply, puffing out our

chests. “We could build a human in only

100 faces! Yes, that’s right, a mere 100

faces. Granted, it will kind of suck, but it

will be a recognizable human figure.”

“No way.” says Sam. “Prove it, brag-

gart.” And so we do.

First, we use triangular cross-sections

for the arms and legs. That means we’ll

have six triangles per straight section.

The face counts will be:

two sections

(forearm and biceps) 12 faces

cap the end of the limb 1 face

joints 4 faces

per limb: 17 faces Total, 4 limbs: 68 faces

That leaves us a luxurious 32 faces to

build a head and torso.

The concept for the torso is simple.

Start with the connection triangles where

the four limbs connect and join them with

as few faces as possible. We may notice

that the connection triangle’s shape has

changed some from the one on the limb.

This keeps the torso’s shape reasonable.

This kind of flexing is what sketching is

for; we shouldn’t feel bound by our previ-

ous sketches if they constrain the rest of

the model horribly.

This torso design uses 15 faces. With

the limbs, we’ve now used 83 faces, leav-

ing a paltry 17 faces for the head. That’s

not enough — we’ll have to go over our

polygon budget a bit.

The hardest part is the head. Here’s a

synopsis of how to built it: Start with an

uncapped extruded pentagon shape.

Twist the shape so that the top and bot-

tom pairs of five vertices aren’t aligned.

Scale the top vertices around their local

axis about 120%. Create five new faces

that cap the bottom end. Collapse one of

the lower edges, creating a four-sided

bottom connected to a five-sided top. The

long edge that was formed by the col-

lapse is the nape of the neck. Now build a

five-sided pyramid to cap the top of the

pentagon. Divide the edge in the middle

of the forehead. Move this new vertex

and the pyramid peak vertex until the

head is a little rounder looking.

Scared Sam is impressed. We used 20

faces in this head model, which means we

have a 103-face human. Yeah, it’s ugly as

sin, but it’s also surprisingly useful. How

else would you make a 50-person angry-

mob scene? And And why spend any more

faces than necessary on a six-pixel-tall

LOD model?

Simple Characters: How Low Can You Go?

Lisa Washburn is the lead RT3D

artist at Vector Graphics. With her

background in fine art, she uses

sculpturing skills as well as her 3D

modeling abilities to do her magic.

Lynell Jinks is a professional artist for

Vector Graphics. He created the pencil

sketches and textures shown in this col-

umn. His talent in 2D character artwork

spans natural media as well as

Photoshop texture and image creation.

Contributors

Related to lighting, but not the same, is the ambientlight level. It sounds obvious that the basic color of thetextures should be established and consistent, but it’seasy to get wrong. One technique for preventing confu-sion is to agree on a single RGB value as a backgroundcolor. The textures should be visible against it, which

essentially means that it should be somewhere nearan average color.

Enough preaching to the choir on how to draw tex-tures. I’m sure you’ve already concluded that weshould establish lighting levels and methods, and planon trying out a few different highlight/contrastschemes until we get good-looking cloth and skin.

Creating cylindrical textures from scratch is difficultbecause it’s harder to imagine how the texture willlook on the object. Placing highlights isn’t as intuitive.It’s much easier to work from existing textures, espe-cially for alignment of faces. If you can find aCyberware scan of somebody’s head, this is a greatstarting point for painting cylindrical maps of faces(Figure 8).

The Rest

W e’ll build the rest of the body next month,then we’ll assemble the parts into a hierar-

chy, place pivots, and adjust joint designs as necessary.We’ll also prepare simple hand-keyframed animations,and walk through steps of applying motion capture dataonto the model.

Feedback is always welcome. E-mail [email protected] let me know what you thought. ■

29F I G U R E 8 . Head texture.


30

WORKING WITHMOTION CAPTUREF I L E F O R M A T S

oy am I glad that 3D acceleration hardware is here to stay. I’m

sure you all feel as liberated as I do by not having to write

all that basic polygon stuff. Clipping, sorting, and draw-

ing pixel-by-pixel is about as dull as 3D programming

gets. Now I have all this great hardware to do the mind-

numbingly dull texture mapping and Z-buffering for me. I

also have the render speed and horsepower to do some

really interesting stuff. What am I going to do with all

this spare time? Really cool real-time 3D characters!

Sure, we’ve all seen real-time 3D characters. We’ve even

seen real-time 3D characters with a restricted use of ani-

mation. However, there have been so many limitations,

B Y J E F F L A N D E R

C A P T U R EM O T I O N

BBJeff Lander is a Digital Evolutionist at Darwin 3D, where he crafts technology for the future of gaming, entertainment, and networkcommunication. He can be reached at [email protected].


and we all want so much more. Wewant realism, but how do we go aboutfulfilling these sick desires? Theanswer: motion capture.

Motion Capture

L et’s face it, motion capture is hot.In the last couple of years, motion

capture has spread everywhere — frommovies to television commercials,from sports titles to action games,even to click-and-explore adventures.Publishers are climbing all over eachother trying to get the words “Motion-Captured 3D Characters” on theirboxes. A lot of hype has been loadedonto those words, often to the player’sdisappointment. As usual, our expecta-tions exceed what the technology cantruly deliver. But we’re getting somuch closer; we have new rippinghardware and the experience frompast-generation motion capture down-falls. Yet the desire for more keepsincreasing.

The hype has gotten so over-the-topthat for the last couple of years, I’vebeen threatening to put out VIRTUA

HANGMAN as a demo at E3. I can justsee it, these realistic real-time 3D char-acters marching up to the gallows asyou relentlessly guess letters. If wewant to be cliché, we could even havea 3D character turning the letters.Now that would be an excessive use oftechnology.

While I wouldn’t consider usingmotion capture for characters bettersuited to traditional keyframing,motion capture technology clearly hasa place in game development. Luckily,

the techniques needed forprogrammers to applymotion capture data to real-time characters work equallywell with any type of anima-tion data, be it keyframed,motion captured, or animat-ed through proceduraldynamics.

The Need

L et’s imagine a scenario inwhich your brilliant pro-

ducers have assigned you,the programmer, to developa real-time 3D character-

based game. They have charged youwith the tasks of designing the gameengine and creating the productionpathway. For a variety of design, bud-getary, and staffing reasons, you’vedecided to use motion capture to sup-ply the bulk of your animation data.

Your first task is to decide whereyou’re going to get this data. It does-n’t really matter whether you haveyour own capture setup or a servicebureau is doing it for you — plan onplenty of cleanup time. Motion cap-ture is not simple. The data needsquite a bit of massaging to get it readyfor the game, and you can get in trou-ble by underestimating the amount ofpost-production work the data needs.You also need to be aware that motioncapture data is specific to the hierar-chy and body dimensions of the per-

son captured. It’s possible, but tricky,to scale this motion to other bodytypes and sizes. However, I would rec-ommend getting all your data fromone session with one capture artist.This will make your life much easierin the long run.

Still, as an experienced productioncompany, you won’t be burdenedwith these details because your pro-ducers have budgeted the motion cap-ture session correctly. Now you needto decide how you want this data tocome to you. Other formats exist, butthe Biovision (.BVA/.BVH) formatsand the Acclaim Motion format arethe big ones, and all the servicebureaus and animation packages sup-port these.

Your file format decision depends onyour application and engine needs.You can bring these formats into acommercial animation package andexport the data from there, but the for-mats are very compact and easy to usewith your own tool set.

Definition of Terms

I ’ll refer to the character that youapply motion capture data to as a

skeleton. The skeleton is made up ofbones. To create the character’s look,you attach geometry or weightedmesh vertices to these bones. Theattributes that describe the position,orientation, and scale of a bone willbe referred to as channels. By varying


32

M O T I O N C A P T U R E

SSeeggmmeenntt:: HHiippss

FFrraammeess:: 2299

FFrraammee TTiimmee:: 00..003333333333

XXTTRRAANN YYTTRRAANN ZZTTRRAANN XXRROOTT YYRROOTT ZZRROOTT XXSSCCAALLEE YYSSCCAALLEE ZZSSCCAALLEE

IINNCCHHEESS IINNCCHHEESS IINNCCHHEESS DDEEGGRREEEESS DDEEGGRREEEESS DDEEGGRREEEESS IINNCCHHEESS IINNCCHHEESS IINNCCHHEESS

00..000000000000 3344..551199668844 00..000000000000 --1144..998888003399 --1122..224400660044 --33..448811115555 ......

00..110022774488 3344..007788773399 33..115599997799 --1155..333377665544 --1144..332200441133 --33..998833440077 ......

00..226600668800 3333..883366661133 66..448877889955 --1166..330088772233 --1155..009900779999 --33..886611226600 ......

...... RREEPPEEAATTSS FFOORR AA TTOOTTAALL OOFF 2299 FFRRAAMMEESS

SSeeggmmeenntt:: CChheesstt

FFrraammeess:: 2299


XXTTRRAANN YYTTRRAANN ZZTTRRAANN XXRROOTT YYRROOTT ZZRROOTT XXSSCCAALLEE YYSSCCAALLEE ZZSSCCAALLEE

IINNCCHHEESS IINNCCHHEESS IINNCCHHEESS DDEEGGRREEEESS DDEEGGRREEEESS DDEEGGRREEEESS IINNCCHHEESS IINNCCHHEESS IINNCCHHEESS

00..227722115566 3388..999933556611 --11..119999998811 --44..002222775533 --00..441111008888 11..335544661111 ......

00..441133559977 3388..554422667711 11..993322666666 --44..337711226633 --00..559911113300 11..110000888877 ......

00..556600556688 3388..227799880000 55..118844992299 --55..002200008822 --00..665577002200 00..776688886633 ......

......FFOORR TTHHEE RREESSTT OOFF TTHHEE SSEEGGMMEENNTTSS

L I S T I N G 1 . Sample Biovision .BVA file.

the value in a channel over time, youget animation. These channels arecombined into an animation stream.These streams can have a variablenumber of channels within them.Each slice of time is called a frame. Inmost applications, animation data has30 frames per second, though that’snot always the case.BIOVISION’S .BVA FORMAT. This is probablythe easiest file format to handle. It’sdirectly supported by most of the 3Danimation packages. Let’s take a look ata piece of a .BVA file (Listing 1).

This is as simple as animation datagets. For each bone in the skeleton (orwhat Biovision calls Segments), thereare nine channels of animation. Theserepresent the translation, rotation, andscale values for each bone for eachframe. You’ll also notice that there isno hierarchy definition. That’s becauseeach bone is described in its actualposition (translation, rotation, andscale) for each frame. This can lead toproblems, but it sure is easy to use.

Figure 1 shows the hierar-chy of a sample .BVA file.

In Listing 1, we see thatHHiippss as the first bonedescribed. There are 29frames of animation in theHHiippss. The frame time isdescribed as 0.03333 seconds(per frame), which corre-sponds to 30 frames per sec-ond. Next comes a descrip-tion of the channels andunits used, then the actualchannel data. There are 29lines of nine values, fol-lowed by a segment blockthat describes the next bone,and so on, continuing to theend of the file. That’s all there is to it.BIOVISION’S .BVH FORMAT. This format issimilar to the .BVA format in manyrespects. In practice, I know of no off-the-shelf way to import this file formatinto Alias|Wavefront or Softimage,although Biovision’s plug-in, MotionManager for 3D Studio MAX, reads it.

Still, it’s an easy-to-read ASCII formatthat can be useful for importing andstoring animation data. Obtaining datain this format should be easy becausethe format is supported by manymotion capture devices and servicebureaus.

The .BVH format differs from the.BVA format in several key areas, themost significant of which is that .BVHcan store motion for a hierarchicalskeleton. This means that the motionof the child bone is directly dependenton the motion of the parent bone.Figure 2 shows a sample .BVH formathierarchy.

In this sample, the bone HHiippss is theroot of the skeleton. All other bonesare children of the HHiippss. The rotation ofthe LLeeffttHHiipp is added to the rotation andtranslation of the HHiippss, and so on.

This hierarchy will certainly compli-cate the game engine’s render loop.Why would you want to bother? Youcan do many more interesting things ifyour motion is in a hierarchy. Let’stake the example of wanting to com-bine a “walk” motion with a “wave”motion. In the .BVA format, there is norelationship between the LLeeffttUUppAArrmm andthe HHiippss. If we were to apply a differentmotion to the different bones, nothingwould stop them from separating. Amotion hierarchy allows you to com-bine such motions fairly easily. Also,should we ever want to add inversekinematics or dynamics to the gameengine, a hierarchy would make thispossible.

Listing 2 shows a fragment of a .BVHfile. The word HHIIEERRAARRCCHHYY in the first linesignifies the start of the skeleton defini-tion section. The first bone that is


33

HHIIEERRAARRCCHHYY

RROOOOTT HHiippss

{{

OOFFFFSSEETT 00..0000 00..0000 00..0000

CCHHAANNNNEELLSS 66 XXppoossiittiioonn YYppoossiittiioonn ZZppoossiittiioonn ZZrroottaattiioonn XXrroottaattiioonn YYrroottaattiioonn

JJOOIINNTT LLeeffttHHiipp

{{

OOFFFFSSEETT 33..443300000000 00..000000000000 00..000000000000

CCHHAANNNNEELLSS 33 ZZrroottaattiioonn XXrroottaattiioonn YYrroottaattiioonn

JJOOIINNTT LLeeffttKKnneeee

{{

OOFFFFSSEETT 00..000000000000 --1188..446699999999 00..000000000000


JJOOIINNTT LLeeffttAAnnkkllee

{{

OOFFFFSSEETT 00..000000000000 --1177..995500000011 00..000000000000


EEnndd SSiittee

{{

OOFFFFSSEETT 00..000000000000 --33..111199999999 00..000000000000

}}

}}

}}

}}

......

}}

MMOOTTIIOONN

FFrraammeess:: 2200


00..0000 3399..6688 00..0000 00..6655 ......

......

L I S T I N G 2 . Sample Biovision .BVH file.

F I G U R E 2 . .BVH file

hierarchy.

F I G U R E 1 . .BVA file

hierarchy.

defined is the RROOOOTT. This bone is the par-ent to all other bones in the hierarchy.Each bone in this hierarchy is defined asa JJOOIINNTT. Braces contain the root and eachjoint. All joints within a set of braces arethe children of that parent joint.

Within each braced block is theOOFFFFSSEETT and CCHHAANNNNEELLSS definition for thatbone (or JJOOIINNTT). The OOFFFFSSEETT describes dis-placement of the root of the bone fromits parent. This (x,y,z) coordinate is theworld coordinate offset from the par-ent bone. In the example, the HHiippss boneis located at offset (0,0,0) and theLLeeffttHHiipp is 3.43 world units away fromthe HHiippss in the x axis.

The CCHHAANNNNEELLSS line defines whichbone parameters will be animating inthe file. The first parameter is thenumber of channels animated forthis bone. Next is a data type for eachof these channels. The possible typesare: XXppoossiittiioonn, YYppoossiittiioonn, ZZppoossiittiioonn,XXrroottaattiioonn, YYrroottaattiioonn, and ZZrroottaattiioonn. Notethat the scale channels have beendropped in the .BVH format.Normally, only the root bone has anyposition data — the rest of the boneshave only rotational data and rely onthe root and the hierarchy for theirposition. The CCHHAANNNNEELLSS can be in anyorder. This order defines thesequence in which the operationsneed to be processed in the playback.For example, in the LLeeffttAAnnkkllee joint,the order of channels is ZZrroottaattiioonnXXrroottaattiioonn YYrroottaattiioonn, meaning that thebone is first rotated around the zaxis, then the x axis, and finally the yaxis. This becomes important whenwe try to display the data.

The branch of the hierarchy endswith the EEnndd SSiittee joint. This joint is off-set is only useful in determining thelength of the last bone.

Following the HHIIEERRAARRCCHHYY section is theMMOOTTIIOONN section. This section actuallydescribes the animation of each boneover time. As in the .BVA format, thefirst two lines of this section describethe number of frames and the timefor each frame. However, unlike the.BVA format, the next lines describethe animation for all the bones atonce. In each line in the rest of theMMOOTTIIOONN section, there is a value forevery CCHHAANNNNEELL described in the HHIIEERRAARRCCHHYYsection. For example, if the HHIIEERRAARRCCHHYYsection describes 56 channels, there

will be 56 values on each line ofthe MMOOTTIIOONN section. That continuesfor the total number of frames inthe animation.

That’s it for the .BVH format.While it’s a bit more complex, itgives the programmer designing theengine greater flexibility.ACCLAIM SKELETON FORMAT. This is themost complicated of the three fileformats. It’s also the most compre-hensive, and supported by most ofthe 3D animation packages. AnAcclaim motion capture file is actual-ly made up of two files; the .ASF,

which describes the actual skeleton andits hierarchy, and the .AMC file, whichcontains the motion data. The separa-tion of these two files has a nice benefit.In a single motion capture session, youcan have one .ASF file that describes theskeleton and multiple .AMC motionfiles. The Acclaim format is such a tech-nical and complex file format that thisoverview may not provide all the need-ed information. Documents describingthe format in greater detail are availableon the Game Developer web site(http://www.gdmag.com).

The .ASF file issimilar to theHHIIEERRAARRCCHHYY sectionof the .BVH filein many ways.Both filesdescribe thejoints and thehierarchy, butthe .ASF fileextends this abit. Listing 3 dis-plays a portionof an Acclaim.ASF file.

In this file for-mat, lines begin-ning with apound sign (##)are ignored. The.ASF file is divid-ed into sections.Each sectionstarts with a key-word precededby a colon. Thesection contin-ues until anoth-er keyword isreached. The::vveerrssiioonn, ::nnaammee,and ::ddooccuummeennttaattiioonn

section are self-explanatory. The ::uunniittsssection describes a definition for allvalues and units of measure used.

The ::rroooott section describes the parentof the hierarchy. The aaxxiiss and oorrddeerr ele-ments describe the order of operationsfor the initial offset and root nodetransformation. The ppoossiittiioonn elementdescribes the root translation of theskeleton and the oorriieennttaattiioonn elementdefines the rotation.

The ::bboonneeddaattaa keyword starts a blockthat describes all of the remainingbones in the hierarchy. Each bone isdelimited by bbeeggiinn and eenndd statements.


34


This bone description section is whatmakes the Acclaim format very useful.

The iidd and nnaammee elements describethe bone by number or string. The ini-tial rest position of the bone isdescribed by the ddiirreeccttiioonn vector, andthe lleennggtthh describes the physical lengthof the bone. The aaxxiiss parameterdescribes the global orientation via anaxis vector, and the token letters xxyyzzdescribe the order of rotations. Notincluded in the sample are two option-al elements: bbooddyymmaassss, which defines themass of the bone, and ccooffmmaassss whichpinpoints the center of mass via a dis-tance along the bone.

The ddooff element describes the degreesof freedom possible in the bone. This isa list of tokens. The possible values are

tx, ty, tz, rx, ry, rz, and l. The first ofthese six define freedom to translateand rotate around the three axes. Thelast ddooff defines the bone’s ability tostretch in length over time. Each ofthese tokens represents a channel thatwill be present in the .AMC file in thatorder. The order of these channeltokens also describes the order of opera-tions in the transformation of the bone.

The lliimmiittss element is very interesting.It describes the limits of the degrees offreedom. It consists of value pairs ofeither floats or the keyword iinnff, mean-ing infinite. This information can beuseful for setting up an inverse kine-matic or dynamic 3D character.

The next section in the .ASF file is::hhiieerraarrcchhyy. Just as it sounds, it describesthe hierarchy of the bones declared inthe ::bboonneeddaattaa section. It’s a bbeeggiinn…eenndd

block in which each line is the parentbone followed by its children. Fromthis information, the bones should beconnected together in the proper hier-archy. Figure 3 displays the hierarchyin the sample .ASF file.

The .AMC file defines the actual chan-nel animation. Listing 4 contains a sam-ple .AMC fragment. Each frame of ani-mation starts with a line declaring the

frame number. Next is the bone anima-tion data, which is comprised of thebone name and data for each channeldefined for that bone. This informationwas defined in the ddooff section of eachbone in the .ASF file. The frame sectionsin the file continue until the end of thefile. After the complexity of the .ASF file,the .AMC looks pretty simple.


35

::FFUULLLLYY--SSPPEECCIIFFIIEEDD

::DDEEGGRREEEESS

11

rroooott --11..224444220055 3366..771100118866 77..559911889999 00..995588116611 44..119900004433 --1188..228822999911

hhiippss 00..000000000000 00..000000000000 00..000000000000

cchheesstt 1155..551111777766 --22..880044999966 --00..772255331144

nneecckk 4488..555599660055 00..000000000000 00..001144223366

hheeaadd --3388..333322666611 11..446622778822 --11..775533668844

lleeffttccoollllaarr 00..000000000000 1155..995588778833 00..992211116666

lleeffttuuppaarrmm --1100..331199668855 --1155..004400000033 6633..009911119944

lleeffttlloowwaarrmm --2277..776699117766 --1155..885566665588 88..118877001166

lleefftthhaanndd 22..660011775533 --00..221177006644 --55..554433777700

rriigghhttccoollllaarr 00..000000000000 --88..447700007766 22..889955000088

rriigghhttuuppaarrmm 66..449966114422 99..555511558833 --5577..885544111188

rriigghhttlloowwaarrmm --2266..998833449900 1111..333388227766 --55..771166337777

rriigghhtthhaanndd --66..338877774455 --11..225588550099 55..887766006699

lleeffttuupplleegg 2233..441122226622 --55..332255991133 1122..009999339955

lleeffttlloowwlleegg --66..993333444422 --66..227766005544 --11..336633999966

lleeffttffoooott --11..887777664411 44..445555666677 --66..227755002222

rriigghhttuupplleegg 2200..669988669966 33..118899669900 --88..337777224444

rriigghhttlloowwlleegg 33..444455884400 --66..771177112222 22..004466003322

rriigghhttffoooott --88..116622331144 00..668877880099 99..000000226644

22

rroooott --44..223322443322 3366..772233993344 99..559966110000 --77..005511114477 11..667788111177 --77..771111993377

hhiippss 00..000000000000 00..000000000000 00..000000000000

cchheesstt 3311..886633449999 --1199..001177111111 66..449900554477

......

L I S T I N G 4 . Sample .AMC file.

F I G U R E 3 . .ASF file hierarchy.

::vveerrssiioonn 11..1100

::nnaammee BBiiooSSkkeelleettoonn

::uunniittss

mmaassss 11..00

lleennggtthh 11..00

aannggllee ddeegg

::ddooccuummeennttaattiioonn

DDaattaa ttrraannssllaatteedd aanndd pprroovviiddeedd bbyy

BBiiooVViissiioonn MMoottiioonn CCaappttuurree SSttuuddiiooss

::rroooott

aaxxiiss XXYYZZ

oorrddeerr TTXX TTYY TTZZ RRZZ RRYY RRXX

ppoossiittiioonn 00..00 00..00 00..00

oorriieennttaattiioonn 00..00 00..00 00..00

::bboonneeddaattaa

bbeeggiinn

iidd 11

nnaammee hhiippss

ddiirreeccttiioonn 00..000000000000 11..000000000000 00..000000000000

lleennggtthh 00..000000000000

aaxxiiss 00..0000000000 00..0000000000 00..0000000000 XXYYZZ

ddooff rrxx rryy rrzz

lliimmiittss ((--118800..00 118800..00))

((--118800..00 118800..00))

((--118800..00 118800..00))

eenndd

bbeeggiinn

iidd 22

nnaammee hhiippss11

......

eenndd

::hhiieerraarrcchhyy

bbeeggiinn

rroooott bbooddyy__rroooott11

bbooddyy__rroooott11 hhiippss

hhiippss hhiippss11 hhiippss22 hhiippss33

......

eenndd

L I S T I N G 3 . Sample Acclaim .ASF file.

You should be aware of one impor-tant aspect of the Acclaim and .BVHformats. While both formats can storerotations in arbitrary order, bothSoftimage and Alias|Wavefront expectthe order of rotations to be tx, ty, tz, rx,ry, rz. This is important if you plan ongoing back and forth between the gameengine and one of these packages.

Working with Data

O nce you have your data in a for-mat that you’re happy with, it’s

time to start working on it. I’ve createdan application that loads motion cap-ture files of different formats andallows the user to play them back. Youcan download it from the GameDeveloper web site. When full produc-tion kicks in, such tools are very usefulfor file conversion and formatting.Also, it serves as a good test applicationto try out new ideas and benchmarkcode.

I decided to create the motion cap-ture viewer as a MFC OpenGL applica-tion — I find it very quick and easy tocreate tools this way. If you’re carefulabout how you design the tool, muchof the code can be used directly in thegame engine itself. Figure 4 shows asample animation that has been loadedinto the application.DATA REPRESENTATION. As we saw fromthe different file formats, there areseveral ways to store the animationdata from a motion capture session.The most important data is the orderof rotations in each stream. You mayremember from 3D matrix math thatmatrix multiplication is noncommu-tative (see “Inspecting the 3D

Pipeline,” CaseyMuratori, GameDeveloper,February/March 1997,pp.38-41). The order inwhich you performthese operations is criti-cal to getting theexpected result.

Because I wanted mymotion capture viewerto support several differ-ent file formats, it wasimportant to take opera-tion order into account.I created a series of

stream IDs that describe the order ofchannels in each stream.

Listing 5 shows the stream types thatI’ve needed. These are not all the possi-bilities, but they are the ones that I’vefound useful. By creating separatestream types for single operations suchas SSTTRREEAAMM__TTYYPPEE__TTRRAANNSS and SSTTRREEAAMM__TTYYPPEE__RRXXYYZZ, Idecrease stream size while animating.This operation isn’t as important whenthe animation can fit in RAM, but itbecomes critical when you have tostream animation off of a CD-ROM orthe Internet.

Next, I created a data structure torepresent a bone (Listing 6). I chose tostore the transformation informationas separate scale, translation, androtation vectors instead of a globaltransformation matrix. This made itmuch easier to handle the differentchannel types. I also find the rotationvalues, called Euler angles, easy tounderstand while debugging.Conversion to and from quaternionsfor animation or a transformationmatrix can also be done easily. Oncethe data format for a game engine isset, this can be optimized.

Looking at the pprriimmSSttrreeaammTTyyppee,pprriimmSSttrreeaamm, and pprriimmFFrraammeeCCoouunntt fields, itseems curious that I would want tohave a motion stream for each bone.It would certainly be easier to haveone animation stream that containsall the data for all the bones in theskeleton. However, this method allowsthe flexibility to have different streamtypes per bone. This can be usefulbecause it allows me to attach com-pletely different motions to the indi-vidual bones. Imagine a character in awalk cycle. The legs and hips are


36


////// SSTTRREEAAMM DDeeffiinniittiioonnss //////////////////////////////////////////////////////////////////////////////////////////////////////////////

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__NNOONNEE 00 //// NNOO SSTTRREEAAMM AAPPPPLLIIEEDD

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__SSRRTT 11 //// SSCCAALLEE RROOTTAATTIIOONN AANNDD TTRRAANNSSLLAATTIIOONN

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__TTRRAANNSS 22 //// SSTTRREEAAMM HHAASS TTRRAANNSSLLAATTIIOONN ((XX YY ZZ)) OORRDDEERR

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__RRXXYYZZ 44 //// RROOTTAATTIIOONN ((RRXX RRYY RRZZ)) OORRDDEERR

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__RRZZXXYY 88 //// RROOTTAATTIIOONN ((RRZZ RRXX RRYY)) OORRDDEERR

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__RRYYZZXX 1166 //// RROOTTAATTIIOONN ((RRYY RRZZ RRXX)) OORRDDEERR

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__RRZZYYXX 3322 //// RROOTTAATTIIOONN ((RRZZ RRYY RRXX)) OORRDDEERR

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__RRXXZZYY 6644 //// RROOTTAATTIIOONN ((RRXX RRZZ RRYY)) OORRDDEERR

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__RRYYXXZZ 112288 //// RROOTTAATTIIOONN ((RRYY RRXX RRZZ)) OORRDDEERR

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__SS 225566 //// SSCCAALLEE OONNLLYY

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__TT 551122 //// TTRRAANNSSLLAATTIIOONN OONNLLYY ((XX YY ZZ)) OORRDDEERR

##ddeeffiinnee SSTTRREEAAMM__TTYYPPEE__IINNTTEERRLLEEAAVVEEDD 11002244 //// TTHHIISS DDAATTAA SSTTRREEAAMM HHAASS MMUULLTTIIPPLLEE SSTTRREEAAMMSS

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

L I S T I N G 5 . SSTTRREEAAMM definitions from SSkkeelleettoonn..HH..

F I G U R E 4 . A sample animation in OGLView.

affected by the wwaallkk stream. Suppose Ithen attach a wwaavvee stream to the rightarm. Now I have a walking and wav-ing character. We can also begin toplan for the possibility of blendinganimations together to create dynam-ic motions on the fly.DISPLAY METHODS. Now that I have allthis data loaded, I have to display itin a way that provides the most infor-mation possible. In my tool, I choseto represent each bone of the skeletonas an axis. The axes are colored redfor x, green for y, and blue for z. Anarrow indicates the positive directionin each axis. Since I was usingOpenGL to create my motion capturetool, this seemed like a good opportu-nity to use display lists. Display listsare a method that OpenGL uses tooptimize sequences of commands.Listing 7 contains the OpenGL com-mands that I used to create a simplecolored axis.

I also created a hierarchy browserusing the CCTTrreeeeCCttll class in MFC. Thisgives a nice visual representation ofhow the skeleton is laid out. Fromthere, it’s easy to add dialog boxes toedit bone settings, a more proper ani-mation control window, andso on.

The animation is all handled via aWindows timer event. This isn’t thefastest way to animate a Windowsapplication, but it’s plenty fast for thisdemonstration. There’s a very good dis-cussion on animating OpenGLWindows applications in Ron Fosner’sbook, OpenGL Programming for Windows95 and Windows NT. I recommend thisbook and the OpenGL Super Bible byWright and Sweet to any WindowsOpenGL programmer.

The source code and executable forthis application, along with samplemotion files and two documents describ-ing the Acclaim file format can be foundon the Game Developer web site. ■


37

//// CCRREEAATTEE TTHHEE DDIISSPPLLAAYY LLIISSTT FFOORR AANN AAXXIISS WWIITTHH AARRRROOWWSS PPOOIINNTTIINNGG IINN

//// TTHHEE PPOOSSIITTIIVVEE DDIIRREECCTTIIOONN RReedd == XX,, GGrreeeenn == YY,, BBlluuee == ZZ

ggllNNeewwLLiisstt((OOGGLL__AAXXIISS__DDLLIISSTT,,GGLL__CCOOMMPPIILLEE));;

ggllBBeeggiinn((GGLL__LLIINNEESS));;

ggllCCoolloorr33ff((11..00ff,, 00..00ff,, 00..00ff));; //// XX AAXXIISS SSTTAARRTTSS -- CCOOLLOORR RREEDD

ggllVVeerrtteexx33ff((--00..22ff,, 00..00ff,, 00..00ff));;

ggllVVeerrtteexx33ff(( 00..22ff,, 00..00ff,, 00..00ff));;

ggllVVeerrtteexx33ff(( 00..22ff,, 00..00ff,, 00..00ff));; //// TTOOPP PPIIEECCEE OOFF AARRRROOWWHHEEAADD


ggllVVeerrtteexx33ff(( 00..22ff,, 00..00ff,, 00..00ff));; //// BBOOTTTTOOMM PPIIEECCEE OOFF AARRRROOWWHHEEAADD

ggllVVeerrtteexx33ff(( 00..1155ff,, --00..0044ff,, 00..00ff));;

ggllCCoolloorr33ff((00..00ff,, 11..00ff,, 00..00ff));; //// YY AAXXIISS SSTTAARRTTSS -- CCOOLLOORR GGRREEEENN






ggllVVeerrtteexx33ff(( --00..0044ff,, 00..1155ff,, 00..00ff));;

ggllCCoolloorr33ff((00..00ff,, 00..00ff,, 11..00ff));; //// ZZ AAXXIISS SSTTAARRTTSS -- CCOOLLOORR BBLLUUEE


ggllVVeerrtteexx33ff(( 00..00ff,, 00..00ff,, --00..22ff));;





ggllEEnndd(());;

ggllEEnnddLLiisstt(());;

L I S T I N G 7. Display list code from OGLView.CPP

I wish to give a special thanks to thosewho contributed necessary informationand assets: House of Moves(www.moves.com) and Biovision(www.biovision.com) for sample motionfiles; and Richard Hince of Probe andRichard Barfield of Oxford Metrics Limitedfor information on the Acclaim Motion fileformat.

Acknowledgements

ssttrruucctt tt__BBoonnee

{{

lloonngg iidd;; //// BBOONNEE IIDD

cchhaarr nnaammee[[8800]];; //// BBOONNEE NNAAMMEE

//// HHIIEERRAARRCCHHYY IINNFFOO

tt__BBoonnee **ppaarreenntt;; //// PPOOIINNTTEERR TTOO PPAARREENNTT BBOONNEE

iinntt cchhiillddCCnntt;; //// CCOOUUNNTT OOFF CCHHIILLDD BBOONNEESS

tt__BBoonnee **cchhiillddrreenn;; //// PPOOIINNTTEERR TTOO CCHHIILLDDRREENN

//// TTRRAANNSSFFOORRMMAATTIIOONN IINNFFOO

ttVVeeccttoorr bb__ssccaallee;; //// BBAASSEE SSCCAALLEE FFAACCTTOORRSS

ttVVeeccttoorr bb__rroott;; //// BBAASSEE RROOTTAATTIIOONN FFAACCTTOORRSS

ttVVeeccttoorr bb__ttrraannss;; //// BBAASSEE TTRRAANNSSLLAATTIIOONN FFAACCTTOORRSS

ttVVeeccttoorr ssccaallee;; //// CCUURRRREENNTT SSCCAALLEE FFAACCTTOORRSS

ttVVeeccttoorr rroott;; //// CCUURRRREENNTT RROOTTAATTIIOONN FFAACCTTOORRSS

ttVVeeccttoorr ttrraannss;; //// CCUURRRREENNTT TTRRAANNSSLLAATTIIOONN FFAACCTTOORRSS

//// AANNIIMMAATTIIOONN IINNFFOO

DDWWOORRDD pprriimmSSttrreeaammTTyyppee;; //// WWHHAATT TTYYPPEE OOFF PPRRIIMMAARRYY SSTTRREEAAMM IISS AATTTTAACCHHEEDD

ffllooaatt **pprriimmSSttrreeaamm;; //// PPOOIINNTTEERR TTOO PPRRIIMMAARRYY SSTTRREEAAMM OOFF AANNIIMMAATTIIOONN

ffllooaatt pprriimmFFrraammeeCCoouunntt;; //// FFRRAAMMEESS IINN PPRRIIMMAARRYY SSTTRREEAAMM

ffllooaatt pprriimmCCuurrFFrraammee;; //// CCUURRRREENNTT FFRRAAMMEE NNUUMMBBEERR IINN SSTTRREEAAMM

......

//// RREESSTT OOFF SSTTRRUUCCTTUURREE DDEECCLLAARRAATTIIOONN

}};;

L I S T I N G 6 . Structure definition from SSkkeelleettoonn..hh.


39

G A M E A I

ing the reasons for particular actions.We need to define these reasons andrepresent them in a way that the com-puter can manipulate. If we can do so,then the game’s agents — that is, theautonomous entities, be they simplemonsters, NPCs, military units, or com-puter-controlled players — can demon-strate several intelligent capabilities.• They can act in terms of goals.• They can carry out long-term plans.• They can adapt their behavior to situ-

ations not planned for by the gamedevelopers.Fortunately, there are means to

improve AI along these lines. This arti-

cle will explore research results in the AIsubfield of planning. This research hasbeen going on for over 30 years (a verylong time in computer research terms),and its goal has been to develop rou-tines for agents to achieve goals in anenvironment that the agents themselvescan change. Over time, this field hasexplored the representation of actionsand goals, the reasoning about time andcausality, and methods for dealing withunknown and dynamic environments.

Such a large field can only betouched upon briefly. The aim of thisarticle is fairly modest: to explore howsome of the basic ideas of planning can

be used for a game AI. Those who wantto explore the subject further shouldcheck out the references at the end ofthis article. While the techniques that Ipresent won’t give your game’s AI thereasoning skills of a human, they willhelp you understand how reasoningcan translate into action.

What’s in a Plan?

T he parts that go into a representa-tion of a plan or action become

apparent after some careful analysis.Think about the plans that you makeon a regular basis. Where should I gofor lunch? Which errands do I have todo on the way home from work? Howshould I schedule the development ofmy game? Most plans share commontraits.• A plan has a purpose — a goal to

reach. Perhaps there are several goals,

Adding Planning Capabilitiesto Your Game AIb y B r y a n S t o u t

Bryan Stout has worked professionally both in applied artificial intelligence and incomputer game development. He has lectured on game AI at several conferences,including the Computer Game Developers’ Conference, and has been working on abook about game AI. After a hiatus of a few months, he is pleased to announce thathe has signed a contract with Morgan Kaufmann, and his book, tentatively titledAdding Intelligence to Computer Games, will appear in 1999.

any complaints about artificial intelli-

gence (AI) in games can be attributed to

a single cause: the AI doesn’t under-

stand what it’s doing. Actions are deter-

mined by a combination of mechanistic

rules and internal dice rolls, but often

there is no explicit means of represent-MM©

19

97

Va

dim

Va

hra

me

ev

- A

ll r

igh

ts r

es

erv

ed

.


40

G A M E A I

and a meta-goal to achieve them effi-ciently, but each plan has a purpose.

• A series of subgoals must be achievedin order to accomplish a plan.Additionally, subgoals may in turnhave their own subgoals.

• A variety of steps must be be taken inorder to carry out a plan.

• Some steps have prerequisites, or con-ditions, that must be true before theycan be taken.

• The steps are taken in order to achievesome part of a goal, or a prerequisiteof some other step.

• The steps in a plan have an order.Some orderings are necessary becauseof prerequisites; other orderings arearbitrary.

• The steps often use a certain amountof resources — including items such asraw materials, money, manpower,fuel, or time — whose presence mustbe accounted for in order for a planto succeed.

• Some plans have conditional steps,which cause branches in the stepstaken depending on some other out-comes.

Implementing the Plans

O f course, the basic elements listedpreviously can be represented in

many ways, from simple to robust.HARD-CODING PLANS. The simplest way torepresent a plan is to write the plan-ning directly into the source code. Thequality of the plan being followeddepends on the thoroughness of thecode as it relates to various incidentalsituations. The plans can be implicit in

the code — the goals result from theinterplay between different parts of thecode — or perhaps global variables orobjects will keep track of goals thathave yet to be fulfilled and the progresstowards them. It’s tempting to hardcode this functionality into the game,since it doesn’t require designing spe-cial data structures. This solution isperhaps the most difficult to maintain,however, because any changes to theAI require modifying and recompilingthe code. It would be betterif we could separatethe knowledgefrom the reason-ing; we need toput the plansin data struc-tures that theplanning rou-tines can use.PRODUCTION RULES.Production rules arecondition/action rules,which have often been used inexpert systems and other traditional AIapplications. A production-rule systemloops through all the rules, takes note ofwhich ones apply (that is, which haveconditions that are true), and choosesone of them to fire (invoke). The basiccondition/ action rule is a very flexibletool and can be adapted to many situa-tions. For planning, the action, or right-hand-side (RHS), of the rule would bethe action to take. The condition, or left-hand-side (LHS), would be the prerequi-sites of the action. The regular rules canbe supplemented with variables thatkeep track of the desired goals and thestatus of the plans to realize them.

Production rules can be hard-codedor stored in explicit data structures thatare defined either in a code module orin an external file. Listing 1 showssome rules (in outline form) that couldrepresent a plan to get a treasure that isprotected by a guardian monster and alocked door.

One problem that rule systems mustdeal with is how to choose betweenmultiple rules that are supposed to fireat the same time. A way to solve thisproblem is to assign a priority to eachrule or to the different conditions thatcan appear in rules.

Another problem is that if a rule sys-tem gets too large, it’s inefficient to testall of the rules’ conditions every cycle.Fortunately, there are ways to speed upthis process. One way is to index all therules by the clauses in their LHSs.Then, for example, if a monster iswounded, the inference engine can fig-ure out what the monster should do byaccessing only those rules whose con-ditions depend on the monster’shealth.FINITE STATE MACHINES. Another usefulway to represent a plan is the finitestate machine (FSM), which consistsof nodes (representing states) and the

arcs between them (represent-ing the transitions from

one state to another).A node or a state in

a FSM can standfor a particularstage in the plan,and an actionassociated with

the node would bethe action to be car-

ried out. The transi-tions occur when an action

is completed, or some eventinteracts with the process of the plan;conditions on those transitions canindicate what the next state shouldbe. Figure 1 shows a simple transitiondiagram for the same scenario asListing 1.EXPLICIT GOAL, PLAN, AND ACTION STRUCTURES.A representation of plans will be morepowerful and robust if you can explicit-ly represent and reason about theseaspects of plans, rather than get atthem through indirect means. Thisrequires that you represent plans,goals, and actions in some explicit way.There are many ways to do this, andsince the needs of different games can

IIff nnoott ssuuffffiicciieennttllyy aarrmmeedd ttoo ffiigghhtt tthhee mmoonnsstteerr,,

tthheenn llooookk ffoorr wweeaappoonnss..

IIff ddoo nnoott hhaavvee tthhee kkeeyy ttoo tthhee ttrreeaassuurree rroooomm ddoooorr,,

tthheenn llooookk ffoorr tthhee kkeeyy..

IIff ssiiggnniiffiiccaannttllyy wwoouunnddeedd,,

tthheenn hheeaall sseellff..

IIff ssuuffffiicciieennttllyy aarrmmeedd aanndd hheeaalleedd,,

tthheenn aattttaacckk tthhee mmoonnsstteerr..

IIff ffiigghhttiinngg tthhee mmoonnsstteerr aanndd sseerriioouussllyy wwoouunnddeedd

aanndd tthhee mmoonnsstteerr iiss nnoott sseerriioouussllyy wwoouunnddeedd,,

tthheenn fflleeee..

IIff tthhee mmoonnsstteerr iiss ddeeaadd oorr ggoonnee aanndd hhaavvee tthhee ttrreeaassuurree ddoooorr kkeeyy,,

tthheenn uunnlloocckk tthhee ttrreeaassuurree rroooomm ddoooorr kkeeyy aanndd uunnlloocckk tthhee ddoooorr..

IIff tthhee ttrreeaassuurree rroooomm ddoooorr iiss ooppeenn

tthheenn ggeett tthhee ttrreeaassuurree..

L I S T I N G 1 . Sample rules for a plan to get past a monster and locked door to a

treasure.

vary widely (even within the samegenre), I won’t advocate one particularrepresentation.

The following are possible fields thatyou might include in a structure for aggooaall class:• A text string in which to store the

name of the goal, such as “OccupyCity.” You may need text strings forother needs too, such as comments.

• A defined constant representing the goalin a form the program can recognize.

• A set of slots that stand for the para-meters of the goal, such as the city tooccupy in a war strategy game.

• The bindings of the slots. A genericggooaall type will have a slot for the cityto occupy. A specific instantiation ofthe goal will state to which city it’sreferring. The binding could be apointer, an index to an array, adefined constant, and so on.

• A pointer to a function that can deter-mine whether the goal is satisfied.

• A pointer to a function that evaluateshow close one is to satisfying thegoal, which measures progress. Thisand the preceding could be the samefunction, with 100% representing fullsatisfaction, or they could be differ-ent, since progress measurement andsatisfaction tests may be more effi-ciently represented separately.

• A priority for the goal, to help decidewhich goals to work on first.As mentioned earlier, there are differ-

ences between the ggooaall class structure,general goal templates, and instantiat-ed goals. The ggooaall class structure isdefined at compile time within thecode. General goals all use this sameclass but represent different specificgoals. Thus, the fields would have dif-ferent values, such as “defend location”or “attack unit.” These goals wouldprobably be created during develop-ment and saved in a file, to be read inat run time and allocated as goal tem-plates. Instantiated goals are goalsassigned to a specific circumstance.They are like copies of the generic goalswith slots bound to specific objects(such as “defend Paris” instead of“defend location”). These two types ofgoals are probably best represented byhaving different classes for each,whereby the instantiated ggooaall classwould have a pointer to the appropri-ate generic ggooaall class as well as the slotbindings. These same principles applyto aaccttiioonn and ppllaann classes as well.

The fields for an aaccttiioonn class couldinclude:• The action name and other strings.• A defined constant representing the

action in a form the program canrecognize.

• Slots that represent the subject andobject(s) of the action, such as theagent doing the attacking, the agentbeing attacked, allies, and so on.

• Parameters for the action. For exam-ple, an action to purchase fuel wouldneed to know how much fuel to pur-chase. The slots and parameters couldbe represented in the same way.

• Bindings for the slots and values forthe parameters. These would be forthe instantiations, not for the actiontemplates.

• A pointer to a function that actuallycarries out the action (for instance,“monster attacks player”).

• The prerequisites for the action. If theprogram is building a plan fromscratch, the prerequisites give it addi-tional subgoals for which to plan.(For instance, needing a key tounlock a door makes obtaining thekey a subgoal.) While executing aplan, prerequisites provide a testwhose failure is a reason to abort theaction and perhaps the whole plan(such as the key that is lost ordestroyed before you can use it).

• The changes the action makes to thegame world (for instance, “the chestis now unlocked,” or “the city is nowoccupied”). If the program buildsplans, this field is used to look foractions that fulfill goals or precondi-tions. While executing plans, thisfield can be used to see if the action’schanges have already happened, inwhich case the action is skipped (forexample, there is no need to unlockan unlocked door). The changesshould be represented using the same

defined constants used for the goals,for easy comparison.

• The resources the actions consume,whether raw materials, fuel, money,or something else. The resourcescould simply be be part of the prereq-uisites (for instance, “x tons of ironare needed to build the ship”), orthey could be represented as a sepa-rate type of field. The resources con-sumed also count among the changesmade to the world.

• The time it takes to perform the action,if that’s important. The time couldjust be another resource, or it could beconsidered separately, since time hasits own attributes (everyone has thesame amount, it can’t be traded, andonce gone it can’t be taken back).

• The preference associated with theaction. A function that evaluateswhich action to invoke can judgebased on the various attributes, but anextra field can capture information notdirectly represented, or provide a short-cut past the whole evaluation process.The fields for a ppllaann class could

include:• The goal of the plan, such as “capture

location x.” While a plan is beingexecuted, the goal can be checked sothat the plan can be halted if or whenthe goal is fulfilled, whether deliber-ately or serendipitously. If a plan isbeing built, the goal needs an explicitrepresentation, as explained previous-ly, so that the builder can plan for it.

• The steps that comprise the plan.Depending on the needs of the game,these may include subgoals as well aslow-level actions. It’s no coincidencethat the fields for goals and actionsexplained previously have many simi-lar fields. Thus, a class implementationcould define ppllaannsstteepp as a superclass ofthe ggooaall and aaccttiioonn classes, for use inthe plan’s sstteepp field and other places.


41

Get KeyGet Weapons Heal Self

Attack MonsterUnlock DoorGet Treasure

Flee

F I G U R E 1 . Sample FSM for a plan to get past a monster and locked door to a

treasure.

• The changes the plan makes to theworld. This is a composite of thechanges that individual actions havemade which aren’t unmade by otheractions. Changes made to the worldare important to know because actionsmay have side effects that cause oneplan to be chosen over another.

• The order in which the steps aretaken. The order can be strict (forexample, “do A, then B, then C, thenD”) or it can be a partial order (forexample, “do A before D, and Bbefore C”). Partial orders are morepowerful and flexible, but they aremore complicated to track.

• The causal links in the plan’s steps.For example, the action OOppeennDDoooorr isfired to fulfill the OOppeenneedd((DDoooorr)) prerequi-site to the RReemmoovvee((CChheesstt,,RRoooomm)) subgoal.These links are useful during planconstruction to make sure that noth-ing affects the action’s result beforethe goal is fulfilled (for example,“make sure nothing shuts the doorbefore the agent can take the chestout of the room”).

• Control flow information. An advancedplanner can include loops and condi-tional branches such as those found inprogramming languages (for example,“if the city is found vacated, occupy it;otherwise surround and attack theforces there”).

• The time and resources used by theplan as a whole.

• A preference rating.Of course, not all of these fields need

to be used. When you’re developing aplan-building or plan-execution sys-tem, you’re better off starting simply

and gradually adding functionality. Asimple representation of a plan wouldbe a linear list of steps, assumed tooccur in their listed order.

You may have noticed that goals andactions possess a lot of similarities. Thisis not a coincidence, since either typecan be used as a step in a plan. Youmight want to make both classes descen-dants of a common ancestor class.

The explicit representationsexplained previously offer the mostdirect means of applying the planningalgorithms, which I will discuss short-ly. The explicit plan structure containsseveral lists: the steps in the plan(including their order), the causallinks, and the variable bindings thatrefer to the list of steps. The normaltrade-offs in data structure construc-tion occur at this point — you musttake into account the typical size andrange of size of the list, its usage, andso on. Usually, lists are constructed asarrays with their references representedby array indices, or built as linked listsand pointers.

Oh, The Plans You’ll Build

H aving examined ways of repre-senting plans, let’s look at run-

time methods for selecting plans,implementing plans, and recoveringfrom failed plans. We won’t cover thetopic of building plans, even thoughthis was one of the first efforts in plan-ning research. Building a new planfrom scratch (that is, from only primi-tive actions), is time consuming for

both AI and for humans. Most plan-making and following that people do isbased on the adaptation of previousplans to new situations; similarly, we’llassume that you’ll define plans foryour game during development andsave them to a file for the program tomanipulate.

Listing 2 shows the sorts of plansone can build for an autonomous dun-geon explorer. The number after thegoals and plans show an assigned pri-ority. As the explorer moves about, itacts upon the goals and plans that havethe highest priority — thus, if it’s in alife-threatening situation, the plans forself preservation will be invoked andfollowed, but if not, then the lower-pri-ority goals of monster slaying andexploration are pursued.

Note that there are several levels ofplans, incorporating different subgoalsthat can be used. The plans here arevery simple, only one or two actionslong, but longer plans can be devel-oped. The balance between the numberof subgoals, the number of plans, andthe length of the plans depends on theneeds of the game’s intelligence andthe efficiency needed for dealing withall the plans. A well-defined set ofplans can meet the needs of severalgenres of games and achieve many AIgoals.• Simple agents in an action game can

be given a sense of operating under aset of goals. If their plans are com-plete enough, they will act in a rea-sonable way regardless of the situa-tion in which they find themselves.

• In role-playing games, one mayassign nonplayer characters a set ofgoals to work from, such as earningextra money, seeking adventure, get-ting revenge on enemies, and so on,which makes them seem more likereal people with separate lives.

• War games can structure their strate-gic and tactical thinking aroundplans. Objectives can be defined andthen attacked or defended accordingto how they achieve some higher goalin the conflict.

• Strategy games can manage resourceswith plans as well. Plans can managethe economic infrastructure, militarybuildup, R&D, and so on, accordingto the player’s current goals.

• In both action and strategy games,plans can be used for group move-ment as well as individual action. For


42

G A M E A I

Goals:

SSttaayyAAlliivvee [[110000]]

GGeettEExxppeerriieennccee [[5500]]

Plans:

iiff BBaaddllyyWWoouunnddeedd ddoo GGeettHHeeaalliinngg ttoo SSttaayyAAlliivvee [[8800]]

iiff BBaaddCCoommbbaattSSiittuuaattiioonn ddoo RRuunnAAwwaayy ttoo SSttaayyAAlliivvee [[9900]]

ddoo GGeettTTrreeaassuurree ttoo GGeettEExxppeerriieennccee [[3300]]

ddoo KKiillllMMoonnsstteerrss ttoo GGeettEExxppeerriieennccee [[4400]]

iiff IIssHHeeaalliinnggSSoouurrccee((xx)) ddoo ((GGooTToo((xx)),, UUssee((xx)))) ttoo GGeettHHeeaalliinngg [[7788]]

iiff IIssTTrreeaassuurree((xx)) ddoo PPiicckkUUppTTrreeaassuurree((xx)) ttoo GGeettTTrreeaassuurree [[2255]]

iiff IIssMMoonnsstteerr((xx)) ddoo AAttttaacckkMMoonnsstteerr((xx)) ttoo KKiillllMMoonnsstteerrss [[3377]]

ddoo EExxpplloorreeDDuunnggeeoonn ttoo GGeettTTrreeaassuurree [[1155]]

ddoo EExxpplloorreeDDuunnggeeoonn ttoo KKiillllMMoonnsstteerrss [[1155]]

iiff nnoott EExxpplloorreedd((xx)) ddoo GGooTToo((xx)) ttoo EExxpplloorreeDDuunnggeeoonn [[1122]]

iiff DDoooorrCClloosseedd((xx)) ddoo OOppeennDDoooorr((xx)) ttoo GGooTThhrroouugghhDDoooorr((xx)) [[1122]]

iiff DDoooorrLLoocckkeedd((xx)) ddoo ((FFiinnddKKeeyy((yy)),, UUnnlloocckkDDoooorr((yy,,xx)))) ttoo OOppeennDDoooorr((xx)) [[1100]]

L I S T I N G 2 . Sample plans for a simple dungeon explorer.

example, an ambush or a flankingmaneuver can be coordinated byusing either an overall plan run by avirtual commander who tells theindividual agents what to do, or byseparate plans that tell each agentwhat to do when certain other agentshave done their parts.

Plan A, B, or C?

A ssuming that our game has severalplans built, the next issue to deal

with is how to choose which plan tofollow in a given situation. This issuecan be considered from several angles,leaving a wide range of approaches totake.

For instance, should you choose aplan based on optimized or simply sat-isfied conditions? In other words,should the game look for thebest plan of all or a plan thatis simply good enough? Asatisfying approach wouldtake the first plan whichmeets some minimalstandard — the first toscore over a given mini-mum, or perhaps thefirst that looks as if itwill work. This approachcan be helped by exam-ining candidate plans in aparticular order, such asfrom simple to complex, orcheap to costly. For example,in order to capture a city in a wargame, the player can first try march-ing into it (if it’s empty of enemytroops), then can try a simple attackfollowed by an advance, and finallycan attempt more involved and pro-longed attacks.

An optimizing approach wouldexamine several plans and choose thebest one based upon its score.Fortunately, not every possible planneeds to be examined (because thesame plan can have many instantia-tions with different variables or slotbindings, such an optimizing approachcan involve huge numbers of plans).The number of plans can be held downfurther by limiting the search to a cer-tain number of plans or a certainamount of time spent searching for thebest plan.

When I refer to a plan’s “score,” Imean some function that evaluates the

goodness of the candidate plan. Inshort, the score for a plan will consistof its “value” minus its “cost.” Valuecan be measured in terms of the fulfill-ment of goals, the value and quantityof goods received, the importance ofland occupied, the value of good rela-tionships established, and so on. Thecost could include resources consumed,time expended, estimated damagetaken or lives lost, the number of unitscommitted that could also be used else-where, or some other method of mea-

surement. Both the value and costestimates should factor in an

estimate of the certaintythat valuable things will

be gained or lost if thatplan is chosen.

Another issue inthe plan selectionprocess is whether touse an agent- orgoal-based system.In an agent-basedsystem, an agent triesto decide what to do

next, including whichgoals to work for as well

as which plans to followand which actions to take.

The agent is the center of thefocus — individual plans or goals

may be dropped or modified. In a goal-based system, the focus of attention isthe goal, and agents are used in order toachieve the goal, rather than vice-versa.The goal-based system is a more naturalapproach when there are many smallagents at the disposal of an overalldeciding entity — it is frequently usedin war games and strategy games. Forinstance, if the virtual general in a wargame wants to capture a location, thatgoal will look for units to use in thateffort. The units themselves aren’t con-sidered to have individual goals andexist only to follow orders.

Another decision you must make iswhether to use a top-down or bottom-up goal selection process. In the top-down approach, a high-level goal maybe fulfilled by achieving a few subgoals.These subgoals will have to be broken

down into further steps, and so onuntil actual actions are decided upon.A bottom-up approach works in thereverse direction: It looks at the currentsituation and decides which actionscan be done at the time, sees how theseactions might work toward achievinggoals or preconditions for otheractions, and then builds up plans fromthere. A combined opportunisticapproach is often useful, too, involvingeither top-down or bottom-up plan-ning as is appropriate. For instance, ina war game, a commander could builda top-down plan to drive through a cer-tain part of the enemy’s line. If theenemy responded by bringing in troopsfrom another sector, and thereby leav-ing that sector too weakly defended, abottom-up planner should notice theweakness and plan to send a force topuncture the line at that point.

Finally, you must decide whethercomplete plans, a partial plan, or onlyspecific goals will satisfy your AI. If asituation under consideration is fairlypredictable, and the plan takes only ashort amount of time, then making acomplete plan is useful, and theemphasis is on plan selection. But themore dynamic and unpredictable theenvironment, the less useful it is to layout complete plans. In such cases itmay be useful to plan in detail only thenext few actions and leave other sub-goals for later. In extremely dynamicenvironments, your action selectionprocess is concerned with the very nextaction. You can plan this in several dif-ferent ways. In a top-down approach,you choose the best high-level plan forthe desired goal, then choose the bestsubgoal within that plan, and so onrecursively until an action is selected.In a bottom-up approach, the action isselected that best fits the current situa-tion and seems to advance towarddesirable subgoals and goals. Yetanother approach is to look at severalpossible plans for the current goals andchoose the action that fits the greatestnumber of plans — in other words, theone that leaves the most flexibility forfuture actions.


43

rreeppeeaatt

ggeett tthhee nneexxtt aaccttiioonn iinn tthhee ppllaann

ppeerrffoorrmm tthhee aaccttiioonn uunnttiill iitt iiss ffiinniisshheedd

uunnttiill tthhee ppllaann iiss eemmppttyy

L I S T I N G 3 . Simple algorithm for plan execution.

Acting upon a Plan

O ur game AI knows how to repre-sent plans, our agent has chosen a

plan that advances toward a goal, andnow the agent must act upon that deci-sion. How should this be done? Thesimple, straightforward approach isshown in Listing 3. The agent repeated-ly looks up the next action in the plan,and then does it, until all the actions inthe plan are done. This is good enoughfor linear plans in a static environment.

If the plans aren’t linear — that is, ifthe steps are listed in a partial orderrather than in a complete order — thengetting the next action is a bit morecomplex than just reading the next stepof the plan. In this case, one needs tolook at all the unexecuted actions thathave no unexecuted predecessors andchoose one of them to do. You couldchoose the first such action found, orlook at several of them and choose thebest one according to some game-spe-cific criterion, or choose the one withthe highest priority rating (which couldbe attached to an action or to a produc-tion rule if rules are used).

Not all situations are static or pre-dictable, however, and this can affectwhich plan is chosen. These dynamicsituations often crop up in games,where there are usually multipleagents, each with its own agenda. As Istated in my discussion of actions andplans, you can monitor the plan duringexecution and adjust to violated expec-tations. The first level of monitoring isaction monitoring (an example ofwhich is shown in Listing 4), so calledbecause it runs the tests at the actionlevel and it helps avoid invoking stupidactions such as trying to open a pad-locked chest or a chest that is already

open. An action monitor performsthree types of tests:1. It tests the action’s intended

changes. If they’re already true, theaction is skipped since it would besuperfluous.

2. It tests the action’s prerequisites. Ifany of them are false, the action can-not occur, and the plan is aborted.(Note that this may also be put in thesearch for the next action when usingpartial ordering: Find an unexecutedaction with no unexecuted predeces-sors, whose prerequisites are true.)

3. It monitors the action’s execution,not only to stop the action when thedesired changes are true, but also toknow when to stop trying. It mayquit the action if the preconditionsare violated during execution, or if acertain amount of time has passed orcertain number of attempts havebeen tried. (The time-out test caneasily be added to the simple loop ofListing 3 without any reference to an

action’s purpose or preconditions.)Action monitoring is fairly robust,

but it’s not perfect. It will detect prob-lems with the current action, but itwon’t detect problems with futureactions. For example, if an AI-con-trolled general starts assembling forcesto take a city, action monitoring won’tnotice if the enemy abandons the cityuntil the whole force is assembled andis actually at the point of carrying outthe assault. For another example, con-sider an AI-driven character that founda locked chest and went off to look forthe key. If the character noticed someimp running off with the chest, thecharacter wouldn’t do anything aboutit until he returned to the scene with akey. Handling such problems requires amore robust form of testing called planmonitoring.

Plan monitors perform tests similar toaction monitors, but on a global level.First, they test to see if any upcomingaction (or subgoal, if it’s not brokendown to actions yet) has a violated pre-condition. This test only applies to pre-conditions whose causally-linked actionhas already been executed. If such a pre-condition is found, the plan has failed.Second, plan monitors test to see ifthere are steps that can be skipped. Aplan monitor checks all unexecutedparts of the plan to see if their desiredchanges have already occurred. If so,then their preconditions’ causal linksare followed back and marked as beingskipable. When looking for an action toperform afterwards, if all its changes aremarked skipable (in other words, every


44

G A M E A I

rreeppeeaatt

ggeett tthhee nneexxtt aaccttiioonn iinn tthhee ppllaann

iiff tthhee aaccttiioonn’’ss ppuurrppoossee oorr cchhaannggeess hhaavvee aallrreeaaddyy hhaappppeenneedd

ccoonnttiinnuuee

iiff tthhee aaccttiioonn’’ss pprreeccoonnddiittiioonnss aarree ffaallssee

aabboorrtt tthhee ppllaann

ddoo

ppeerrffoorrmm tthhee aaccttiioonn

uunnttiill tthhee aaccttiioonn iiss ffiinniisshheedd oorr ttiimmee rruunnss oouutt

iiff tthhee aaccttiioonn’’ss cchhaannggeess aarree ffaallssee



L I S T I N G 4 . Algorithm for plan execution with action monitoring.

rreeppeeaatt

iiff tthheerree iiss aa pprreeccoonnddiittiioonn ffoorr aann uunneexxeeccuutteedd aaccttiioonn

wwhhoossee vvaalluuee iiss ffaallssee

aanndd wwhhoossee ccaauussaall aaccttiioonn hhaass aallrreeaaddyy bbeeeenn eexxeeccuutteedd


ffrroomm tthhee ffiinnaall ggooaall aanndd wwoorrkkiinngg bbaacckkwwaarrdd

iiff tthhee ggooaall’’ss oorr aaccttiioonn’’ss cchhaannggeess aarree aallrreeaaddyy ttrruuee

ffoorr eeaacchh pprreeccoonnddiittiioonn ooff tthhee ggooaall oorr aaccttiioonn

mmaarrkk tthhee aaccttiioonn tthhaatt ccaauusseess tthhee pprreeccoonnddiittiioonn aass sskkiippaabbllee

ggeett tthhee nneexxtt aaccttiioonn iinn tthhee ppllaann wwiitthh aa nneeeeddeedd cchhaannggee

[[iiee.. wwiitthh aa cchhaannggee nnoott mmaarrkkeedd sskkiippaabbllee]]

ddoo

ppeerrffoorrmm tthhee aaccttiioonn

uunnttiill tthhee aaccttiioonn iiss ffiinniisshheedd oorr ttiimmee rruunnss oouutt

iiff tthhee aaccttiioonn’’ss cchhaannggeess aarree ffaallssee



L I S T I N G 5 . Algorithm for plan execution with plan monitoring.

plan that might have needed this actionno longer needs it), then the action isskipped. If the final goal is found ful-filled, you might want to add a specialcondition to exit the plan, rather thanmarking all remaining actions asskipable.

Once a plan is instantiated, it may bea good time to go through and anno-tate all of the preconditions to be test-ed before any actions are taken. Thisavoids having to do it each time anaction occurs. Since these tests aremore time consuming than actionmonitoring, you need to testcarefully to see if plan monitor-ing is worth the effort. Youmay prefer to do only one ofthese tests in addition to theaction monitoring, or to donone at all. If the plan islinear, using a full orderrather than a partial order,then it is much easier to dothe tests, since it’s easy todetermine which are thefollowing or precedingactions. You can just go upor down the list, rather thanfollowing causal links around.Listing 5 shows how the basicalgorithm for plan monitoringmight work.

The Best Laid Plans of Mice and MenGo Oft Awry

O r, as Von Moltke put it, “No bat-tle plan ever survives contact

with the enemy.” However you say it,the truth is that plans often don’t workout as they should. Whether from achanging world, an independentagents’ actions, or deliberate sabotage,things happen that make plans obso-lete. Discovering this condition wasthe subject of the last section; knowingwhat to do about it is the focus of thisone. There is a variety of differentresponses an agent can make to recoverfrom foiled plans.REPLAN. The simplest act one can per-form is to completely scrap the oldplan and find a new one to instantiateand follow. It’s the easiest to program,and in simple situations, it’s sufficient.In other situations, though, it may beinefficient — replanning means redo-ing much of the work that went intothe old plan.

However, if one is working withplans in a hierarchical fashion — plansthat have have subplans and so on —then the replanning can be fairly effi-cient. This is because you only have toreplan at a low level, leaving the high-level plans intact. If a situation getsreally messed up, then plans will fail athigher levels, which may necessitatereplanning at the higher levels. REINSTANTIATE. One of the simplest waysto salvage a broken plan is to find

another way to instantiate thevariables or slots of the old

plan. For example, if youplanned to go down a

road that is blocked, youmight look for a differ-ent road. Or, if oneagent is too damagedor otherwise involvedand cannot attack,then attack withanother unit.FIX THE PROBLEM.Another approach torecovering from afailed plan is to make

the violated precondi-tion true again. That is,

make the condition a newgoal, and find a plan to

make it true. For instance, ifthe road you wanted to travel

down is blocked, find some way toremove the barrier. TRY ALTERNATIVE PLANS. You may switchfrom one plan to another. For instance,if the dungeon crawler’s key doesn’tunlock the door, she may set off insearch for another key, or she maydecide to try destroying the door withher axe!USE CONDITIONAL PLANS. The original plancan have conditional tests meant tohandle contingencies, thereby avoid-ing the cost of determining what to dowhen a problem arises. For instance,the dungeon crawler may decide tobring along all her keys, her axe, and agunpowder bomb to deal with possibleproblems. The drawbacks to thisapproach are that you can’t anticipateall possible problems, you can’t preparefor all the problems that you can antic-ipate, and anticipating many problemssimply may not be worth the time tothink about them or the resources todeal with them. When deciding whichproblems to anticipate, it might be use-ful to consider both their probability

and their impact. For instance, if aparty of dungeon crawlers splits up, itmight be important for each person tocarry a weapon, not because they’relikely to run into a monster, butbecause it would be fatal to encountera monster while unarmed.ABANDON OR POSTPONE THE GOAL. This is asimple solution to the problem — giveup and do something else. It may bethat circumstances within the gamewill change and the goal will becomeachievable later.

All of these approaches need not bemutually exclusive. A routine for deal-ing with plan problems may considerseveral of them — reinstantiation, fix-ing the problem, using alternativeplans, and dropping the goal — andchoose the option with the bestcost/benefit trade-off.

This coverage of AI planning shouldgive you several ideas to play aroundwith — some of them should be applic-able to your particular game situations.Good luck! ■


45

This overview has been necessarily

general. Here are some books which are

very useful for further reading:

Allen, James, James Hendler and AustinTate. Readings in Planning. (MorganKaufmann, 1990.) A very good collection

of important historical papers covering

various aspects of planning.

Shapiro, Stuart C. Encyclopedia of ArtificialIntelligence. (Wiley Inter-Science, 1990.)Good article on planning (and many

other good articles).

Russell, Stuart and Peter Norvig. ArtificialIntelligence: A Modern Approach. (PrenticeHall, 1995.) This has the best discussion

on planning of current AI texts. In fact, I

regard it as the best of all current AI

texts, period, both in general and for

computer game developers. It has the

widest selection of topics, the most

recent research, and uses agents as its

organizing paradigm – rather than pre-

senting the different fields of AI in a

loosely-related manner, it treats all of

them from the viewpoint of software enti-

ties that are trying to perceive their envi-

ronment, make decisions, and act — just

the things that games are full of.

FF UU RR TT HH EE RR RR EE AA DD II NN GG

via DirectSound3D can be found invarious books as well as in Microsoft’sown documentation, knowing how notto write to this API is just as critical to asuccessful implementation in yourgame.

Defining the Vocabulary

Before diving into how and how notto use 3D audio, let’s clear up some

of the confusion associated with thetechnology. Often the terms “3Daudio,” “positional audio,” “spatializa-tion,” “virtualization,” and “stereoexpansion” are used interchagably. In

reality, 3D positional audio, virtualiza-tion, and spatialization are three differ-ent concepts, and their differences mustbe understood before they can be prop-erly applied to games or applications.

Spatialization, sometimes calledstereo expansion, uses signal process-ing to expand the perceived location ofspeakers. It is a nonlocalizing effect,meaning that it doesn’t localize asound or a channel to a specific loca-tion. In fact, it does the opposite.Spatialization disperses the perceivedlocation of the sound so that the listen-er can no longer determine the exactlocation of the speakers. It makes thelistener believe that the sound is com-

ing from an area that is much widerthan the actual speakers. The generalperception of spatialization is that itmakes a stereo stream sound muchricher to the average listener.

Virtualization uses signal processingto fool the listener into thinking thatthere are other speakers present thataren’t really there. For example, a systemcould use only two front speakers orheadphones and virtualize rear or sur-round sound speakers for a home theatereffect. Virtualization localizes a specificchannel of audio (such as left rear) to aspecific location, as opposed to localiz-ing a specific sound to an exact location(which is what occurs in 3D positionalaudio). Virtualization is only used whenthe source media has more than twochannels of audio — its usefulness forpositioning interactive sound sources(such as those found in action games) islimited. Examples of multichannelsource media are Dolby Prologic


46

A U D I O3 D

Avoiding a DirectSound3DDisasterb y R i c h W a r w i c k

Rich Warwick’s experience in the PC industry spans chip, gate array, and board levelhardware design, as well as DSP software development. Rich joined CrystalSemiconductor Corporation in 1995 as a software development manager. He wasresponsible for the software development for Crystal's CS4610 PCI audio accelerator.He is currently the Manager of DSP Software Technology, leading the development ofsoftware for Cirrus Logic's "Sound Fusion" line of PCI audio accelerators.

D audio can have a tremendous effect on a

gamer’s experience. Unfortunately, if a game

doesn’t use the DirectSound3D API correctly, the

effect can vary between little or no 3D audio

positioning to even more serious problems,

such as accidental system overloading. While

the methods for implementing 3D positional audio33

Surround or Dolby Digital audiostreams. In this article, when I refer to3D audio, I mean 3D positional audio.

3D positional audio uses signal pro-cessing to localize a single sound to aspecific location in three-dimensionalspace around the listener. 3D positionalaudio is the most common effect usedin interactive games, because a soundeffect, such as the sound of an oppo-nent’s automobile, can be localized to aspecific position. This position,for instance, could be behindthe listener and quicklymoving around the leftside while all the othersounds are posi-tioned separately.

3D posi-tional audio isalso referred to asHRTF-based 3Daudio. HRTF stands for“head-related transferfunction,” a method bywhich sounds are processed tolocalize them in space around theplayer. Although this technique isacceptable for 3D positioning, itrequires a large amount of processingpower. This is the reason 3D audiohardware accelerators are becoming socommon in PCs. For an explanation ofthe mechanics of 3D audio and HRTFprocessing, see “Exploiting SurroundSound using DirectSound3D” in theDecember/ January 1997 issue of GameDeveloper.APPLICATIONS FOR SPATIALIZATION. Spatial-ization is an effect for processingmusic, such as an audio CD or a stereomusic soundtrack in a game. This effectis especially useful for PC speakers thatare built into the monitor because itmakes the sound appear to come from

a much wider sound field than theactual speakers, which in this case arevery close together.

Care must be taken never to applythis effect to an audio stream that hasalready been processed by a 3D posi-tional algorithm, because spatializationalters the phase of the signal and candestroy the 3D positional effect.However, such conflicts are the con-

cern of the audio system designers, notthe developer of game or application.APPLICATIONS FOR VIRTUALIZATION. Virtual-ization is an effect that gives the listen-er the impression of a home theaterenvironment even when only twospeakers or headphones are present,which is typically the case with multi-media PCs. However, to use this effect,multichannel audio must be available,and the sounds to be played back onthe virtualized rear speakers must beencoded onto those tracks during pro-duction. This makes this solution lessthan ideal for the action portion ofgames, in which sounds might have to

jump from the front speakers to therear (depending on the player’sactions), but cannot due to prior encod-ing on a specific channel. However,multichannel audio and the virtualiza-tion of these channels are very effectivefor noninteractive game intro scenes.

Virtualization is typically used toplay back Dolby AC-3 or Dolby ProLogic audio streams on a system thatonly has two speakers. For example,

DVD movies can have a 5.1 channelDolby AC-3 audio track encoded

on the DVD. (The 5.1 chan-nels are actually left front,

right front, center, leftrear, right rear, and a

subwoofer. The sub-

wooferis referred

to as the “.1”channel of the 5.1.)

3D positional audiotechniques are used to

position a front centerchannel as well as right and

left rear channels at their virtuallocations. Virtualization simulates the

additional speakers that aren’t typicallypresent on a computer. Virtualizing rearspeakers is an example of using 3Dpositional audio for a noninteractiveapplication, because the virtual speakerlocations aren’t moving or respondingto the listener.APPLICATIONS FOR 3D POSITIONAL AUDIO. Oneof the reasons that 3D positional audiois so popular in action games is becauseit can be interactive. Sounds don’t haveto be preprocessed during the game’sdevelopment to position the sound. Asthe listener changes location in a virtu-al world, all the sound objects canmaintain their correct location speedand path of motion around the listeneras the action unfolds.


47

This is different from applicationsthat encode the audio into a certainchannel (such as a rear or surroundchannel) during development.Encoding the location of a sound intoa particular channel of a multichannelstream is an example of noninteractiveaudio placement. Multichannel audiois typically used in an environmentwhere the listener doesn’t have controlover the sounds — such as when youwatch a movie in a home theater.

Implementing 3D Audio Today

The use of 3D audio in PC games ini-tially wasn’t widespread, mostly due

to poor 3D audio support in theMicrosoft DirectSound3D 3.0 API. Thefirst iteration of this API didn’t allowspecialized 3D audio hardware to processthe 3D streams, and as a result, gamedevelopers couldn’t be certain that 3Dsound objects would sound satisfactoryand have the desired effect — even if aworld-class 3D audio accelerator was pre-sent in the PC. So there wasn’t muchincentive for game developers to incor-porate 3D audio into their games earlylast year. However, when Direct-Sound3D 5 started shipping in August1997, the situation changed. That APIsupports specialized 3D audio accelera-tors for processing 3D audio streams.

Using the DirectSound3D API

W hile there are a number ofsources for information about

using the DirectSound3D API, it’sequally important to know how not touse it. At last year’s Computer GameDevelopers’ Conference, a number ofprogrammers working on 3D positionalaudio for games explained problemsthat they had encountered and thelessons that they had learned duringdevelopment. Their problems resultedin poor performance in their games andlittle or no apparent 3D effect, even onthe sounds the developers most wantedto position in 3D space. I’ve boiled theircomments down to four rules that youshould follow when implementing 3Dpositional audio in your own title. 1. NEVER USE VARIABLE FREQUENCY BUFFERS

UNLESS THEY’RE ACTUALLY REQUIRED. It’simportant not to request variable fre-quency sound buffers when they’re not

necessary. This is a common mistakebecause it’s the default in some of theDirectSound SDK examples. To makebest use of a hardware DirectSoundaccelerator, pay attention to the flagsspecified in the llppccDDSSBBuuffffeerrDDeesscc..ddwwFFllaaggssparameter, which are passed toIIDDiirreeccttSSoouunndd::::CCrreeaatteeSSoouunnddBBuuffffeerr(()). Some ofthese flags are straightforward — forexample, DDSSBBCCAAPPSS__LLOOCCHHAARRDDWWAARREE asks for ahardware-accelerated buffer andDDSSBBCCAAPPSS__CCTTRRLL33DD asks for DirectSound3Dcontrol. Other flags have implicationsfor hardware accelerators that aren't sostraightforward. The worst offender isDDSSBBCCAAPPSS__CCTTRRLLFFRREEQQUUEENNCCYY, which specifies thatyou need to be able to adjust the buffer'splayback frequency after the buffer hasbeen allocated. There are circumstanceswhere this is a useful capability (someracing games use it to adjust the pitch ofan engine, for example), but most of thetime it's not required.

You also need to be aware thatMicrosoft's default llppccDDSSBBuuffffeerrDDeesscc..ddwwFFllaaggssvalue, DDSSBBCCAAPPSS__CCTTRRLLDDEEFFAAUULLTT, includes theDDSSBBCCAAPPSS__CCTTRRLLFFRREEQQUUEENNCCYY flag (in addition toDDSSBBCCAAPPSS__CCTTRRLLVVOOLLUUMMEE and DDSSBBCCAAPPSS__CCTTRRLLPPAANN), soyou're not safe from this potential per-formance-draining trap if you supplyMicrosoft's default flag value.

Every buffer that is created withDDSSBBCCAAPPSS__CCTTRRLLFFRREEQQUUEENNCCYY (that is, set for vari-

able frequency) will assign a sample rateconversion application to the audiostream. This consumes additional pro-cessing resources either on the hostprocessor or on the audio hardwareaccelerator. If the host PC contains amultitasking audio hardware acceleratorwith dynamic resource management,the resources consumed by these samplerate conversion applications could havebeen used to accelerate more 3D audiochannels. As you can see, blindly creat-ing all streams as variable frequencystreams will slow down the host proces-sor and/or prevent 3D audio streamsfrom being accelerated.2. NEVER USE 3D WHEN 2D WILL SUFFICE. Onlycreate 3D sound buffers when necessary.Many games have created all of theiraudio streams as 3D streams, but thispractice results in a poor listening expe-rience. An accelerated system will quick-ly run out of resources, and the resultwill be a complete lack of accelerated 3Daudio. After all the hardware acceleratorresources are consumed, the host willapply its 3D audio algorithm to theremaining streams. These streams willconsume much more processing powerthan 2D streams, and further burdenthe system. The bottom line is that it’svery wasteful to play every stream as 3Dwhen it isn’t necessary.


48

3 D A U D I O

Company GameAcclaim TUROK: DINOSAUR HUNTER; FORSAKEN

Activision HEAVY GEAR

Crack dot Com GOLGOTHA

Eidos THE DARK PROJECT

Electronic Arts MOTO RACER

GT Interactive TIGERSHARK; MAGESLAYER; BUG RIDERS

Interactive Magic Online WARBIRDS

Interplay STARFLEET ACADEMY

LucasArts OUTLAWS, JEDI KNIGHT

Maxis SIMCOPTER; STREETS OF SIMCITY; SIMCITY 3000

Microprose MECHWARRIOR III

n-Space TIGERSHARK; BUG RIDERS

Probe FORSAKEN

Raven Software MAGESLAYER

Reality Bytes DARK VENGEANCE

Ripcord Games SPACE BUNNIES MUST DIE

Sculptured Software TUROK: DINOSAUR HUNTER

SegaSoft ROCKET JOCKEY

Sony Interactive Studios TANARUS

Techland Software CRIME CITIES; SPEED THRILL; VIRTUA COMMAND;

CRUSHER; SPEEDWAY MANAGER 3D

Source: http://www.aureal.com/tech/A3Ddevs.html

TA B L E 1 . Games that currently support 3D positional audio or will do so in

coming months.

3. AVOID USING THE DDuupplliiccaatteeSSoouunnddBBuuffffeerr CALL. Acommon mistake that game developersmake is not checking for the failure of aDDuupplliiccaatteeSSoouunnddBBuuffffeerr call. Failure to checkfor a bad return code from this call canlead to audio streams or sound effectsbeing completely lost. The reason anapplication developer would use theDDuupplliiccaatteeSSoouunnddBBuuffffeerr call instead of usingCCrreeaatteeSSoouunnddBBuuffffeerr is strictly a matter ofconvenience. Instead of providing all thenecessary parameters for each 3D buffer,you can just reference, or duplicate theparameters of a previously createdbuffer. This practice is acceptable only ifyou understand what happens when acall fails and can take corrective action.

Here’s the problem: If a new 3Dsound buffer is created usingCCrreeaatteeSSoouunnddBBuuffffeerr, the buffer will be creat-ed on the hardware accelerator if thereis a free 3D channel. If no hardware 3Dchannels are available, the software 3Demulation in DirectSound 5 will auto-matically take over. However, if thenew 3D sound buffer is created usingDDuupplliiccaatteeSSoouunnddBBuuffffeerr, the host emulation

in DirectSound 5 cannot take over.This is because DirectSound 5 doesn’thave access to the parameters thatyou’re requesting to duplicate. Theseparameters only reside in the hardwareaccelerator. Therefore, theDDuupplliiccaatteeSSoouunnddBBuuffffeerr will fail, andDirectSound 5 won’t play the buffer onthe host. At this point, the buffer is lostand the sound will never be heard. Thisisn’t a problem if the game or applica-tion checks for the failure and thenreinitiates the call using CCrreeaatteeSSoouunnddBBuuffffeerrinstead. However, the best approach isnot to use the DDuupplliiccaatteeSSoouunnddBBuuffffeerr call.Only use CCrreeaatteeSSoouunnddBBuuffffeerr, and thisproblem can be avoided.4. ALWAYS CREATE THE MOST IMPORTANT 3DSOUNDS FIRST. To maximize the 3Dimpact on the listener, it’s important tocreate the most important sound buffersfirst. Each time a 3D sound buffer is cre-ated using CCrreeaatteeSSoouunnddBBuuffffeerr, the bufferwill be created on the 3D audio hard-ware accelerator — if one is present inthe system and has a 3D channel avail-able. If all the hardware accelerated

channels are already consumed, or therewas no accelerator in the system, thehost 3D algorithm in DirectSound 5takes over and processes the stream onthe host. This process is invisible to thegame or application. The steams that arerelegated to the host won’t be posi-tioned very well and will use more hostprocessing power than 2D streams.

Follow the Rules

A lways create the most critical 3Dsound buffers first. That way, if

there is an accelerator in the system, itwill be used for the sounds that willhave the most impact on the listener.

It’s no secret that 3D audio can be animmersive experience for game players.However, if you’re going to adopt thistechnology, make sure that you avoidthe common pitfalls associated withDirectSound3D. When followed, thesefour rules will maximize the impact ofyour audio and reduce unintendedaudio processing. ■

49


51

P R O J E C T M A N A G E M E N T

And, you can have your money if… you can ship yourgame by Christmas 1998. You glance at your notes and yourimpressive-looking Gantt charts, and then confidently say,“No problem.” If only that were true.

If you’re developing a new, innovative game, you’re goingto have problems. You’ll make mistakes. You’ll struggle tofind solutions. You’ll design and redesign through theprocess of trial and error. You’ll be forced to make trade-offs.Your plans will change. The unexpected will happen. You’llbe faced with crisis. You’ll have to divert at least one disaster.

When your goals are ambitious, chaos and crisis are thenorm, and anxiety is a constant companion. Creating a newgame can be nerve-wracking, even perilous (financially,physically, and emotionally). But taking risks also providesyou and your development team with challenge, excite-ment, and enrichment — perhaps even fame and fortune.

In my September 1997 Game Developer article, “The Gameof Risk,” I presented some techniques to identify and man-age risk in your development projects. In this article, I pre-sent some techniques for encouraging, embracing, andleveraging risk and chaos in product development.

A ChaosTheory

isten to this and see if it sounds familiar. You want to create

a new game. You think your game is going to be a hit, the

next big thing. You’ve assembled a team of talented people,

who have lots of great ideas and have created some fancy

technology. All that you need is time and

money. You present your idea. It’s well-received. LLb y M a r t i n S t r e i c h e r

Martin Streicher is an Executive Producer at Berkeley Systems, Inc. in Berkeley, CA. He graduated from Purdue University in 1986with a Master’s degree in Computer Science, and has been a software development manager since 1989. Most recently Martinproduced YOU DON’T KNOW JACK MOVIES and YOU DON’T KNOW JACK VOLUME 3. Martin is currently the executive producer,producer, and director of a new CD-ROM game show that he also created. Please send comments or questions about this article [email protected].

Misery Loves Game Companies

G ame development schedules arenotoriously volatile. Why? Because

creating great games is an art. And whilethat comparison may be overused andcliche, I think it’s apropos.

The people that create games —game designers, developers, artists,animators, modelers, musicians, andwriters — are all artisans who havemastered a specialized craft. Likeother craftspeople, the people thatcreate games require skill, insight,direction, materials, and time to pro-duce great work. I would argue thatgame developers face even greaterchallenges since their materials —

hardware, software, storytelling,game play, art — are so diverse andoften revolutionary. A new gamemakes the unreal real — certainly thestuff of art.

Additionally, the process of creatinga game — its design, execution, andimplementation — is not a science.Each software development “model”has advantages and disadvantages, anddevelopment methodologies varygreatly. Great games challenge the lim-its of technology — you should expectthat creating great games will likewisechallenge your status quo and the lim-its of your own abilities. If your goalsare ambitious, then you should expectthings to change. You should expect to

adapt your current practices and inventnew ones.

You’ll certainly face situations andproblems that you’ve never facedbefore, and you’ll be called upon tomake decisions for which you’re unpre-pared. You’ll make mistakes, but that’snormal. Game development has no for-mulas to follow, nor physical laws toobey. Development has no rules. Thereare no good nor bad decisions per se —it’s up to you to decide what works andwhat does not work.

All of this uncertainty can be terrify-ing, but it can also be compelling. Eachopen issue provides you with theopportunity to excel, create, invent,and imagine. If you’re a smart develop-ment manager, you’ll recognize thechaos, relate to the anxiety it cancause, and at the same time, harness itsenergy. Trial and error is good chaos. Itshows that you’re seeing faults in yourdesign and trying to address them.Tweaking performance is good chaos.Building several game prototypes isgood chaos. Developing more than onebackstory is good chaos. Juggling prior-ities is good chaos. Finding additionalfunding to continue development isgreat chaos. Even if you try and failseveral times, your final solution ulti-mately improves your game.

So how do you do encourage risk-taking, and embrace chaos and uncer-tainty without derailing your develop-ment project? Good question.

To leverage chaos during a project,you must budget it and then manage it— just as you budget and managemoney.

Budgeting Chaos

H ow do you budget chaos? Youestablish limits for chaos and

then decide how much chaos each partof your project can afford. Tasks thatyou want to control closely are “allo-cated” little or no chaos. Tasks thatrequire trial and error to perfect areusually afforded more chaos.

For example, you may choose to“allocate” a good portion of your chaosbudget on a task such as level design.However, a critical task such as 3Dengine development might be affordedless chaos since it’s critical to yourtitle’s game play and look-and-feel. Tocreate a chaos budget, you must first


52


Things to accomplish:• Ship PEZ by Christmas 1998 (sound familiar?)

• Stay within budget

• Develop a strong team of writers

• Create a supportive and collaborative culture for content development

• Develop techniques for content testing and refinement

Critical dates:• 6 October - PEZ funding presentation

• 1 December - End of feature testing; finish all refinements and complete game play

specification

• 7 January 1998 - End preproduction phase; start production phase

• July, August 1998 - External prereleases

• September 1998 - Product ships

People required:• 3 full-time artists/animators/modelers

• 1 part-time artist

• 3 software developers, a production coordinator

• Myself (acting as producer and director)

• A Software Quality Assurance (SQA) lead and several SQA engineers

• A composer and musicians

• A sound engineer

• An editor-in-chief

• 2 full-time writers

• Several part-time writers

Equipment required:• A 3⁄4” tape deck

• A video capture board

• A dedicated image scanning system

• A recording booth

• A Web-based database server

Project risks:• Developing a writing staff and creating content

• Developing and implementing an effective content test plan

• Time (time is always a risk; and if you are independent game developer and not a

developer/publisher, money is also always a risk)

• Creation of the marketing plan

PEZ

identify everything that’s critical to thesuccess of your project. Specifyingwhat is critical sets limits and ensuresthat you don’t spend so foolishly thatit endangers your project.

At a minimum, your list of criticalitems should include:• A thorough and detailed description

of the new product’s features• A list of critical dates (this list includes

your ship date and other milestonessuch as “feature complete,” “externalprerelease,” and other)

• A definitive list of things that youwant to accomplish in the project

• A list of risks to the project• A list of dedicated resources that are

required to execute the project plan(resources include money, people,information, and equipment)

• A list of the expectations that youhave for each person on the develop-ment teamFor example, the sidebar shows the

critical items that I identified for adevelopment project that my team juststarted (the product is code-named“PEZ”).

As you can see, my list of crucialitems includes the goals of the project,a description of the product that I wantto build, critical dates in the schedule,and the resources required to be suc-cessful. Armed with this list, I’m happyto let chaos reign free (or in my analo-gy, be spent freely) until it conflictswith or threatens anything crucial tothe project.

My lists are admittedly very broad inscope; they define limits, but are toogeneral for day-to-day chaos manage-ment. To complete a chaos budget,your team’s lead programmer, leadartist, and marketing manager shouldcompile their own lists of crucial ele-ments. When all of your lists are com-bined, the entire team can operateindependently within well-definedboundaries. In fact, reviewing all of thecritical items and individual “chaosbudgets” is an excellent way to managethe entire project.

As project requirements change —and we know that they will — redefineyour critical items and reallocate chaosas if you were shifting money betweeninvestments. Audit how people arespending their chaos. Work together tomanage chaos as if it were money.

Consider an extreme example (butnot necessarily an uncommon one):

You are developing a new game sched-uled for a Christmas 1998 release.Shortly after you begin development,you learn that your company is run-ning out of cash and that your shipdate for the game is being moved up toSummer 1998. Given this new informa-tion, you and your team have to reviewand revise all of your project goals andyour chaos budgets. You may decide tocut features, expand the staff, andaccelerate development of certain keytechnologies. You may decide to takemore risk (spend more chaos) in engi-neering to match the acceleratedscheduled. Or, you may decide toseverely cut your chaos budget bygreatly restricting the kinds of deci-sions each part of theteam can makeindependently.

Budgeting chaos is oddly similar tohow the Federal Reserve Board controlsinterest rates. If risk is costing the teamtoo much time, effort, and money, cutback on how much chaos is available.If your project needs or wants moreexperimentation, then make chaosmore readily available.

You may be wondering why mydetailed PEZ development schedulewasn’t included in my list of projectparameters. In a chaotic environment,I don’t necessarily care when or howthings happen as long as the team isachieving its stated goals. Am I advo-cating anarchy? No. Process and infra-structure are required for any large-scale project. You still need designdocuments, schedules, reporting struc-tures, and milestones. Ultimately, how-ever, a development schedule is onlyan estimate of how and when work willbe done. A pro forma schedule (such asthose usually created in MicrosoftProject) is useful only because it initi-

ates a process in which you and yourteam analyze, estimate, debate, design,review, and ratify a development plan.Once your team has completed theprocess of creating a project schedule,the schedule is useless.

A development schedule, no matterhow detailed, is not a substitute foryour leadership. All of your infrastruc-ture — Gantt charts, spreadsheets, sta-tus reports, e-mail, code reviews, designreviews, staffing, and meetings — areonly a means to an end.

Managing Chaos

T o manage chaos, you have to earnit, invest in it, keep track of your

investment, invest more when it’s need-ed, and know when it’s time to cut yourlosses. And, to continue the analogy,you cannot manage your investmenteffectively and safely without doingyour research. As the project leader, it isyour primary responsibility to measureprogress, assess risk, prevent and antici-pate problems, and adapt the projectwhenever a critical item is threatened.It’s your responsibility to lead, partici-pate, communicate with, and listen toyour team. In fact, accommodatingchaos and encouraging risk-taking putsan even greater onus on you to interactwith everyone on your developmentteam. Here’s how I recommend youmanage your project portfolio.ENGAGE AND PARTICIPATE. As the projectleader you must establish and thenprotect the autonomy and indepen-dence of your development team. Toestablish autonomy, you must estab-lish a creative, collaborative environ-ment that fosters innovation, risk-tak-ing, and experimentation. Enable all ofyour team members to make as manyindependent decisions as possible.Once you have autonomy, do not treatit as an entitlement. You have to workas a team to protect it. For example,during the development of YOU DON’TKNOW JACK MOVIES, the art team founditself five calendar days behind sched-ule. Rather than ask for additional per-sonnel or time to complete the work,the art team decided to work two week-ends in a row to make up the time. Theart team devised its own solution, exer-cised its autonomy, and simultaneous-ly increased the entire team’s cachet ofcredibility. The more credible your


53

team is, the more autonomous it willbecome.

Work with your development teamfirst to find solutions to problems, andtry to solve your problems without ask-ing for additional resources (money,people, time). However, if you do needhelp, by all means ask for it. Asking forassistance doesn’t discredit your team— in fact a team that asks for helpwhen it needs it actually reinforces itscredibility.

If you’ve established a collaborative,independent environment, your teamshould be able to disagree, debate, andreach consensus on its own. I encour-age you to foster debates to find thebest possible solutions. Let your soft-ware developers argue about imple-mentations — you’ll get better resultsif each developer has to present anddefend his or her design. If your teamcannot agree on an issue, it’s extreme-ly important for you to settle your dif-ferences within the team. If neces-sary, studythe facts,gatheropinions,and then insert yourself as anarbitrator. In the worst case, andif all else fails, make the final deci-sion. Settle the conflict and rally theteam to support the decision.COMMUNICATE. As the project leader, it’syour responsibility to defend yourdevelopment team’s priorities, opin-ions, and decisions. And to best repre-sent your team, you must be intimatelyfamiliar with every aspect of the pro-ject. Personal contact and interactionwith every member of your team is themost valuable technique for gatheringand disseminating information.Without information, no team mem-ber, including you, can make effectiveand appropriate decisions. Make sureto communicate regularly with everyteam member.

For example, I prefer short, one-on-one ad hoc discussions instead of largemeetings. I use these quick, frequentmeetings to ask and answer questions,gauge status, offer advice, change prior-ities, and assess risk. Talking to every-one on the team is time consuming,but it’s extremely easy to do. For me,it’s one of the most satisfying parts ofmy job. I socialize, learn, discuss, andteach every day. COORDINATE. Regular communication

with everyone on the team also allowsme to coordinate the team. When youare managing chaos, this is perhaps themost important task to perform. If youdon’t communicate and coordinate,you won’t be able to measure just howchaotic your project really is. As theproject leader, you have to simultane-ously envision the “big picture” andscrutinize the finest level of detail. Doyou remember my critical items for PEZdevelopment? That’s my big picture.The lists that the leads created are theirbig pictures, yet provide me withanother level of detail. By talking toeveryone on the team, I assemble botha panoramic and microscopic view ofthe project. And that’s how I managechaos in my projects — I always knowwhere to invest ordivest chaos.

REVIEW. Ultimately, your job as the pro-ject leader is to control chaos andensure that the goals of the project arebeing accomplished. You need tospend a good deal of time collectinginformation, and once you have it, youneed to analyze it and react. Reviewand answer these questions every day:What worked today? How can that beleveraged? What didn’t work? How canwe better solve or prevent the problemin the future? Is each team memberfocused on his or her critical list? Didthe parameters of the project change?

Reining in Chaos

R egular communication with every-one on your team provides you

with qualitative results — informationsuch as status, plans, design decisions,and risks. To get quantitative results, youhave to analyze your progress against itsstated goals. The best way to rein inchaos and yield an accurate appraisal ofyour progress is to try to build a run-ning, playable version of your game.

Set a deadline, broadcast it to yourteam, and then focus the entire team onintegrating all completed work. Takeyour art and process it with your tools.Take the data from that step and drop itinto your graphics engine. Attach AI tothe characters in the game and enablethe user interface. Take the output fromyour level editor and drop that intoyour engine, too. Start the game and seewhat happens. Some things will work,others won’t. Look at the game closely.Audit your team’s progress. Has thegame improved since the last incremen-tal build? Why? Why not? Did the teammake the right design decisions? Is any-thing missing? What adjustments needto be made? In staff? In assignments? Inpriorities? Is the project too chaotic?Incremental builds are excellent indica-tors of how your project is proceeding.Incremental builds as are like milemarkers along a highway — each incre-mental build gives you an indication ofyour project’s speed and location.

There are no rules for game develop-ment, no physical laws to obey. Theexcitement and challenge of gamedevelopment is to solve novel, hard,and critical problems with limited time,money, and people. At the start of yourproject, identify what is crucial to yoursuccess. If you remain true to your orig-inal intentions and manage with yourend-result in mind, how you ultimatelyaccomplish your goals is arbitrary.

Manage time, people, and tasks withyour goals in mind. Otherwise, letchaos reign. ■


54


I highly recommend the followingbooks if you are interested in improvingyour ability to create and manage achaotic environment.

Maguire, Steve. Debugging the DevelopmentProcess. Redmond, WA: Microsoft Press,1994. McCarthy, Jim. Dynamics of SoftwareDevelopment. Redmond, WA: MicrosoftPress, 1995. Peters, Tom. The Tom Peters Seminar: CrazyTimes Call for Crazy Organizations. NewYork, NY: Vintage Books, 1994. Yourdon, Edward. Rise and Resurrection ofthe American Programmer. Upper SaddleRiver, NJ: Prentice Hall, 1996.

FF UU RR TT HH EE RR RR EE AA DD II NN GG

hadows of the Empire is an action

game originally developed for the

Nintendo 64 video game console. It

formed part of a multimedia Star

Wars event consisting of a novel,

soundtrack, toy line, comic books,

trading cards, and other related merchan-

dising. The Nintendo 64 version was

released in December of 1996, and has

proven to be very popular with over one

million copies shipped to date. The IBM

PC version was released in early September

of 1997, and has enhanced cut scenes, Red

Book audio (both music and voice), and

high-resolution graphics. It requires the

use of a 3D accelerator card.


56

STAR WARS: SHADOWS OF THE EMPIRE

SSb y M a r k H a i g h - H u t c h i n s o n

Dinner in Kyoto, Japan, August 1996. (Left to right: Don

James, Hiro Yamada, Mark Haigh-Hutchinson, Shigeru

Miyamoto, Kenji Miki.)

P O S T M O R T E M

Why Shadows?

B ack in the summer of 1994,LucasArts was exploring the pos-

sibility of developing a new 3D title forone of the emerging “next-generation”platforms. After some discussion, theNintendo 64 was decided upon as theplatform of choice, even though therewas no hardware available at the time.Due to our close relationship withLucasfilm, we were aware thatLucasfilm Licensing was planning theShadows of the Empire event. JonKnoles, the lead artist and designer onthe Nintendo 64 game, took an activepart in deciding the timeline ofShadows. He suggested that it takeplace between The Empire Strikes Backand Return of the Jedi.

The Shadows story line deals mainlywith the criminal underworld of theGalaxy, and the new period allowed usto explore some of the things thatweren’t explained in Return of the Jedi.It also opened up some new charactersthat were not bound to the originalstory, which gave us more creative free-dom than using established figures. Abonus was that it allowed us to makeuse of everyone’s favorite bountyhunter, Boba Fett.

Since we were developing one of thepremier titles for an entirely new gamemachine, there was a conscious deci-sion to attempt to stretch out and covera number of different game-play styles.We wanted to ensure that the playerwould have as much variety as possible,yet still enjoy a satisfying experience.

A Reality Engine for $200?

B y early September 1994, we hadreceived our Silicon Graphics

workstations and the core team wasworking. Initially the three program-mers were using Indigo 2 Extremes,with 200mhz CPUs, 64MB of RAM, and

24-bit graphics. Eventually, we wouldhave to change our programmers’ com-puters to INDYs (still powerfulmachines) to install the Nintendo 64development systems.

In addition, we were fortunate thatLucasArts allowed us to obtain a SiliconGraphics ONYX supercomputer. Thisimpressive and somewhat expensiverefrigerator-sized computer boastedReality Engine 2 graphics hardware, fourR4000 CPUs, and 256MB of RAM. Itbecame an essential part of our develop-ment equipment, as it was the onlyhardware available that could possiblyemulate how the final Nintendo 64hardware would perform. Indeed,Nintendo and SGI supplied us with soft-ware that emulated most of the featuresthat the real hardware would support.

In late September, the programmerstook a trip down to Silicon Graphics todiscuss the Nintendo 64 hardwaredesign with its chief architect, Tim VanHook. The SGI engineers were rightlyproud of their design, and promisedthat they would deliver hardwarematching the ambitious specifications.Nine months later, we learned that theyhad indeed met those specifications.

By Christmas of 1994, we had thebasis of the first level of the game, TheBattle of Hoth, running quite nicely onthe ONYX — “quite nicely” being inhigh resolution (1280×1024), 32-bitcolor, and at 60 frames a second. By thispoint, we had also received a very earlyprototype of the Nintendo 64 con-troller. This consisted of a modifiedSuper Nintendo controller with a primi-tive analogue joystick and Z trigger. Dueto our strict nondisclosure agreement,we were unable to discuss the hardwareor the project with anyone outside thecore team. Consequently, we wouldfurtively hide the prototype controllerin a cardboard box while we used it. Inanswer to the inevitable questions aboutwhat we were doing, we replied jokinglythat it was a new type of controller — abowl of liquid that absorbed yourthoughts through your fingertips. Ofcourse, you had to think in Japanese….

In July of 1995, we received our firstactual hardware as a plug-in board for

the INDY. This later became known asthe Revision 1 board, but on inspectionit was extremely “clean” — no wirewraps or other temporary items insight. Within three days, technical leadEric Johnston and second programmerMark Blattel had ported the game tothe actual hardware. It was an awe-inspiring moment when we first sawthe Battle of Hoth running on the“real” machine. The first revision ofthe hardware was very close to the orig-inal specifications supplied by SGI.Other than the RCP (RealityCoProcessor) not running at quite thefinal speed, and one of the specialvideo “dither modes” not being avail-able, it performed extremely well.

Over the next few weeks, we wouldreceive an additional two boards, sothat all the programmers were devel-oping in a similar fashion. Threemonths later, we would receiveRevision 2 boards, which brought theRCP up to full speed as well as fixing afew minor bugs. Another pleasant sur-prise was the doubling of the amountof RAM to 4MB.

A further development was the hard-ware “dither modes” that perform sev-eral different kinds of functions at thevideo back end — mostly to reduce theeffect of Mach banding, which is com-mon when using 16-bit color.

Technology

S ince Eric Johnston and MarkBlattel had extensive experience

with the SGI platform, we undertook toprototype the game using thePerformer 3D API. This is an OpenGL-based system that is very flexible.Eventually, we would write our own


57

Images courtesy of LucasA

rts Entertainment Com

pany LLC, © 1997.

Mark Haigh-Hutchinson is a Project Leader and Senior Programmer at LucasArtsEntertainment Company. He has been developing computer and video games as ahobby since 1979, and professionally since 1984. Cutting his teeth on numerous 8-bitcomputers such as the Sinclair ZX Spectrum, he has contributed to 32 publishedgames, 16 as sole programmer. He may be reached at [email protected].

subset of Performer’s functionality onthe Nintendo 64. This allowed us tomove the game from a $140,000 SGIONYX to a $200 Nintendo 64 in a mat-ter of just three days.

Level designers used the tool set fromDARK FORCES to construct the first-per-son levels for the game. This allowed acrude form of preview using the actualDARK FORCES engine on an IBM PC. Thisworked fairly well, although later in theproject we were able to have a singleSGI for dedicated use by the leveldesigners. The PC solution, however,was also useful because the level design-ers were already familiar with theprocesses involved. Unfortunately,since the game engine wasn’t runningon the PC at that point, the develop-ment cycle was somewhat slow.

Additionally, the ONYX calculatedthe preculling visibility tree for each ofthese levels. The way it works is quiteelegant, thanks to Eric and Mark. Theworld is subdivided into “sectors” —that is, polygonal regions defined byeither geometry or some other criteria.These sectors control collision detec-tion, have properties relating to gameplay, and perform several other relatedfunctions. The visibility program tra-verses the world rendering the scenefrom the center of every sector in a 360-degree arc as well as three elevations.For every polygon to be rendered in thescene from a particular sector, an identi-fying 32-bit value, rather than textureinformation, fills the appropriate pixelsin the frame buffer. It’s then a simplematter of reading the frame buffer todetermine which sectors are visible fromthat location. This process becameknown as “pastelization” because theidentifiers written into the frame buffer

(effectively as RGBA values)caused the scene to appearas purely pastel colors.

Motion Capture

In the spring of 1995, wedecided to experiment

with the use of motion cap-ture to control the anima-tions of the main characteras well as enemies such asStormtroopers. Fortunatelyfor us, our sister company,Industrial Light & Magic(ILM), had a capture system

available for use. It was a tethered sys-tem, using a magnetic field to deter-mine the position of each of the sen-sors. The sensors were attached to theactor at 11 locations using a combina-tion of a climbing harness, sports jointsupports, bandages, and Velcro strips.

The nature of the system presentedseveral problems. First, the actor had toperform on a raised wooden platform,since the metal construction supportsin the concrete floor would affect thecapture system. Secondly, since theactor was on a platform as well as teth-ered, we couldn’t obtain a “clean” runcycle. Some of our more ambitiousmotions also proved problematic. Onthe positive side, once the system wascalibrated, we were able to capture over100 motions in a single day, each withtwo or three different “takes.” Weviewed the motions in real time on aSGI Indigo 2 Extreme computer run-ning Alias PowerAnimator. Thisallowed us to quickly ensure that everycapture was “clean” before continuingwith the next action.

Unfortunately, we were to discoverthat after analysis, the motion dataproved to be unusable. This was mainlybecause the angle information for thejoints wasn’t consistent on its represen-tation of the direction around eachaxis. Consequently, all the animationfor the characters was redone by hand,a somewhat time-consuming task.

MIDI Music

O ur initial approach to music forthe game was similar to that

taken on some of our PC titles —namely, a MIDI-based solution.

However, the first problem that wecame across was hardware incompati-bilities between the MIDI keyboardsused by our musicians and the SiliconGraphics computers used to developthe game. The theory was that thecompositions could be previeweddirectly on the Nintendo 64 hardwareas a musician played them on a key-board. Naturally, this would providethe best possible feedback to the musi-cian. Unfortunately, for someunknown reason(s), note on/off pairswere lost, causing chords to sound asone note. Additionally, note releaseswere sometimes missed completely.Before long, other unwelcome behav-iors surfaced. We worked around thesemysteries by having the musicians cap-ture the sample set and play it solelyon their keyboards.

After some experimentation, though,we felt that the MIDI music was good,but didn’t capture the essence of theJohn Williams orchestral soundtrackthat is so closely associated with StarWars. Furthermore, each additionalinstrument channel would require moreCPU time than we wanted to allocate.

At this point, we tried an experimentusing uncompressed digital samples ofthe Star Wars main theme. The qualitywas extremely good, even after subse-quent compression with the ADPCMencoder provided by Nintendo. After alittle persuasion, Nintendo generouslyagreed to increase the amount of car-tridge space from 8MB to 12MB. Thisallowed us to include approximately 15minutes of 16-bit, 11khz, mono musicthat sounded surprisingly good.Considering that most users would lis-ten to the music through their televi-sions (rather than a sophisticated audiosystem), the results were close to thatof an audio CD, thereby justifying theextra cartridge space required.

Art Path

A continuing problem throughoutthe development of SHADOWS was

the inability to import and export databetween the various 3D packages wewere using. Eventually, we managed tocircumvent these problems with anumber of translation utilities as wellas by using Alias Power Animator asour central “hub” format. However,there were still issues with scale, model


58

P O S T M O R T E M

Jon Knoles directs actor Amos Glick who recoils

from an imaginary shot. Mark Haigh-Hutchinson

wrangles the cables and provides a supporting

hand.

hierarchies, and animation data. It wassometimes difficult for the artists to seewhat their artwork really looked likeuntil it had been through the hands ofour polygon wrangler (thanks Tom!).Initially, it was difficult for our textureartist to visualize the restrictions ontexture size required by the hardware,as well as color reduction issues.

New Hardware

T here were a number of other issuesthat we had to deal with in devel-

oping the game, not the least of whichwas that for the first nine months ofthe project, we didn’t have any realhardware on which to run the game.This deficiency wasn’t insurmountableby any means, but it restricted ourchoices in certain ways, especially inlevel design. We were forced to makesome assumptions, especially regardingto performance. Fortunately, this was-n’t quite the bugbear that we anticipat-ed. Still, as is well known, those on thebleeding edge of technology are oftensacrificed upon it.

Other Issues

There was considerable pressure tofinish the game in time for the

Christmas 1996 deadline. This realitymeant many, many late nights, withsome team members regularly workingover 100 hours every week for the bestpart of a year. Hopefully, this sort ofworkload can be avoided in future pro-jects. Time pressure is, of course, a com-mon thing in the computer gamesindustry — and we were certainly nostrangers to the phenomenon. However,since we had to release our game shortlyafter launch of the machine, we wereunder more pressure than might usuallyhave been encountered. Game testingalso became an issue because there werevery few machines with which to actu-ally test the game.

Game Play Variety

W e were able to include a verywide variety of game play styles

in SHADOWS. In retrospect, this meantthat we couldn’t tune each type of gameplay as much as we would have liked. It

also meant an almost Herculean pro-gramming task in trying to write anddebug what amounted to five differentgame engines. These consisted of lowflight over terrain, gunnery action inspace, first/third person on foot or withjet pack (including a moving trainsequence), high-speed chases on aspeeder bike, and full 360-degree spaceflight. Nonetheless, the result was thatmost players’ experiences with the gamewere always interesting, at the expenseof displeasing some of the more hard-

core game players. A variety of gameplay was important for a game that, formany players, would be one of their firstexperiences in a fully 3D environment.

Hardware Performance

A s mentioned before, for the firstnine months of SHADOWS, we had

no real hardware with which to gaugethe performance of the game — otherthan a rather nice Silicon Graphics


59

Game Designer/Lead Artist - Jon Knoles

Project Leader/Senior Programmer -

Mark Haigh-Hutchinson

Technical Lead - Eric Johnston

Programmer/Lycanthrope - Mark Blattel

Polygon Wrangler - Tom Harper

Level Designer - Jim Current

Level Designers - Matthew Tateishi and

Ingar Shu

3D Artists - Paul Zinnes, Andrew

Holdun, and Garry M. Gaber

3D Animator - Eric Ingerson

Texture Artist - Chris Hockabout

3D/Background Artist - Bill Stoneham

Storyboard Artist - Paul Topolos

Music Editor - Peter McConnell

Sound Designers - Larry the O and Clint

Bajakian

Lead Tester - Darren Johnson.

Production Manager - Brett Tosti

Extra thanks go to Don James, Henry

Sterchi, Hiro Yamada, Kensuke Tanabe,

and Shigeru Miyamoto. Special thanks

as always go to the staff at LucasArts,

and particularly to George Lucas for his

gift of the Star Wars universe.

The Core Team

Back Row (left to right): Steve Dauterman, Peter McConnell, Jon Knoles,

Andrew Holdun, Paul Topolos, Mr. B. Fett; Middle Row (left to right): Jim

Current, Matthew Tateishi, Bill Stoneham, Brett Tosti, Ingar Shu, Tom Harper,

Chris Hockabout; Front Row (left to right): Garry Gaber, Mark Blattel, Eric

Johnston, Mark Haigh-Hutchinson; Not shown: Paul Zinnes, Larry the O, Clint

Bajakian, Eric Ingerson, and Darren Johnson.

The core team developing SHADOWS from inception to completion consisted of

mainly six people, although twenty people contributed to the game for varying

lengths of time, and to varying degrees. Nonetheless, everyone played a vital role

in the production of the game.

ONYX. Nonetheless, when we finallyreceived the real hardware, we werepleased to find that the performanceestimates given to us by SGI proved tobe very accurate. In fact, in large partdue to the parallel nature of the graph-ics hardware, we were able to use float-ing-point mathematics throughoutSHADOWS with no significant impactupon performance.

Additionally, SHADOWS was pro-grammed entirely using the C language— it wasn’t necessary for us to useassembler (a first as far as I was con-cerned, and a pleasant surprise eventhough I’m a long-time hardcoreassembler fan). Since our scene com-plexity was relatively high (usuallykept to around 3,000 polygons or so,but variable according to the level typeand design), the graphics task tooklonger to execute than the programcode (that is, we were graphics-bound).Consequently, optimizations to theprogram code didn’t significantlyimprove overall performance.

NTSC to PAL Conversion

A fter completing the American andJapanese versions of the game, it

was my task to convert the game so thatit could run on the European PAL televi-sion standard. Being British, I had a vest-ed interest in making sure that the con-version was a good one. This meant twothings: first, that the game used thewhole of the vertical resolution of thePAL display (625 lines vs. 525 lines ofNTSC); second, I wanted to ensure thatthe speed of the PAL game was the sameas the NTSC one, even though the PALrefresh rate is 50hz rather than 60hz.

Fortunately, when we started work onSHADOWS, we realized that one of themost important things to consider wasthat it had to be a time-based game,rather than a frame-based one. Thiswould allow for update rates that could

vary considerably depending upon scenecomplexity, as well as the simple factthat we didn’t have any real hardwarefrom which to measure performancecharacteristics. Essentially, the programkeeps track of the absolute time betweeneach update of the game. This value,which we called delta time, became amultiplicand for any movement or othertime-based quantity. By this method,the game runs independent of the videorefresh rate, with all objects moving andresponding at the correct frequency.

The other issue had to do with the“letterbox” effect that is common tomany NTSC to PAL conversions. In mostcases, there is no extra rendering orincrease in the vertical frame buffer size,leaving unsightly black bands above andbelow the visible game area. Since thevertical resolution is now greater thanthe original NTSC display, the aspectratio will also change, causing the graph-ics to appear stretched horizontally.

While I wasn’t willing to accept this, Ihad presumed that I couldn’t afford theextra CPU time necessary to render alarger frame buffer, even with the extratime available due to the 50hz videorefresh rate. There was also a question ofthe additional RAM usage required byour triple buffering of the frame buffer.My first attempt, therefore, was simplyto change both the field of view andaspect ratios of the 3D engine. This sim-ple fix solved the “stretching” problemquite nicely, although the displayremained letter-boxed, of course.Unfortunately, it also meant that any2D-overlay status information remained“stretched.” There was the potential thatgame play could be affected because thefield of view, by definition, would affectthe player’s perception of the 3D world.

Again, this just wasn’t good enough.What I needed was a solution that did-n’t require extra rendering, yet wouldfix the aspect ratio problems. After a lit-tle bit of research, I realized that I haddiscovered earlier that it was possible tochange the size of the final visible dis-play area on the output stage of the dis-play hardware. In reality, it’s possible toshrink or enlarge the display both hori-zontally and vertically. To compensatefor the letterboxing, all I had to do waschange the vertical display size by a fac-tor of 625/525 or 1.19. Once I did this, Iimmediately had a full-screen PAL ver-sion. Or so I thought….

One of things about SHADOWS is that

we had to compress everything in thegame to fit it into the cartridge spaceavailable. This included the thin operat-ing system that SGI provides as part ofthe development system. Therefore,upon machine reset, it’s necessary todecompress this OS to run the game. Toperform this decompression, we wrote asmall bootstrap program, which intro-duced a small amount of time betweenthe hardware being initialized and theOS starting. This lag introduced a one-time glitch on the screen as the videohardware started. Not very noticeable,except to me. After many late nights, Idiscovered a way to remove the glitchby directly accessing the Nintendo 64video hardware registers.

Bad Idea

W e then discovered that becausewe had accessed the hardware

directly, it caused an infrequent bug.Rarely (1 out of 50 times) the Nintendo64 would crash if the reset button werepressed at a particular point in thegame. Not only that, I couldn’t repeatthe bug on my hardware (I hate itwhen that happens).

After a number of very late nights(over the Christmas holiday), with thehelp of Nintendo of America’s techni-cal staff (thanks Mark and Jim), wefinally resolved the problem: first, byremoving the code that directlyaccessed the video registers, and sec-ond, by restoring the registers control-ling the scaling of the output in thevertical axis upon reset. Sometimes, thesimplest solution is the best.

Support from SGI and Nintendo

W e were very lucky to receiveexcellent support from both SGI

and Nintendo during the production ofthe game. The SGI engineers (thanks in


60

P O S T M O R T E M

particular to “Acorn”) were very helpfuland would normally have an answer toour questions within a day, sometimeswithin the hour. I would like to thankNintendo for their assistance in the pro-duction of the game. Nintendo ofAmerica’s technical support and QAdepartments also proved invaluable. Inaddition, three of Nintendo of Japan’sstaff spent some time working directlywith us at our offices.

I was also fortunate enough to visitNintendo’s head quarters in Kyoto,Japan, to discuss SHADOWS with ShigeruMiyamoto, creator of MARIO 64. Hisinsights were both fascinating andextremely relevant. He is simply agenius with an instinctive understand-ing of video games.

Of Wampas and Men

W hen developing a project onthe scale of SHADOWS, there will

always be some things that didn’tprogress as smoothly as they couldhave…1) The motion capture process proved

to be a red herring for us. Whileoriginally promising a much morerealistic animation solution, in ourcase the data proved unusable.However, I still believe that it hasgreat potential and deserves furtherinvestigation, even though we didn’tget to the point of dealing with thepotential problems matching themotions to the character’s environ-ment and so forth. Caveat emptor.

2) Attempting to use a MIDI-basedmusic solution also proved incorrectfor this game. While it promised tobe an efficient solution in terms ofmemory (an important considera-tion for a cartridge-based game), itsimply wasn’t suitable for an orches-tral soundtrack such as Star Wars.

3) When we started work on SHADOWS,

a major problem (that continuedthroughout the duration of the pro-ject) was the inability of various 3Dpackages to import and export data.Although we were able, for the mostpart, to write our own conversionutilities, it still proved to be a stum-bling block and prevented us fromhaving an efficient art path.Fortunately, the companies supply-ing these tools now recognize theneed for importing and exportingdata to other packages, and are tak-ing steps to remedy the situation —VRML, for example, is proving to bea useful format.

4) Time was the biggest enemy of all inproducing the game. This is nothingnew, but was exacerbated by the factthat we were working on a non-exis-tent machine for nine months.Nonetheless, even though this was,for the most part, out of our control,we were still able to produce a quali-ty game.

5) With hindsight, probably the mostimportant lesson to be learned fromthe game’s development is that offocus. Do one or two things and dothem extremely well. Although ourambitions were well placed in tryingto provide the player with as muchvariety as possible, we effectivelyhad to write five different gameengines. Additionally, we could havealso used a fourth programmer dedi-cated to all aspects of the front-endof the game; that is, level selection,controller options, and so forth. Thiswould have taken some of the pres-sure away from the main program-mers towards the end of the project.

Out of the Shadows…

T hanks to the talent, dedication,and experience of the SHADOWS

team, many things went well duringthe development process.1) By using the powerful SGI comput-

ers (fairly uncommon in the gamesindustry in 1994) to prototype, com-bined with our programmers’ knowl-edge of 3D technology, we were ableto develop the game rapidly, yetremain flexible in terms of perfor-mance requirements.

2) Our ability to reuse tools from ourearlier DARK FORCES title saved ustime and resources because we did-

n’t have to build all new tools,although a large number of dataconversion utilities were necessary.In addition, by reusing familiartools, our level designers could bemore productive earlier in the pro-ject than otherwise might have beenexpected.

3) Our decision to use digitized musicproved to be a crucial one. Becausemost users would listen to the musicthrough their televisions, the qualityapproximated that of an audio CD asfar as many customers were con-cerned. This alone justified the extracartridge space required and sur-prised many players who didn’texpect that level of quality from acartridge game.

4) The conversion of the game for thePAL television standard wentextremely well and was much appre-ciated by customers in those coun-tries. It would be fair to say thatSHADOWS has set the standard in thatit runs both full screen and fullspeed. There is no reason why allgames from this point on shouldn’trun just as well on PAL systems asthey do on NTSC.

5) Given that we were working oncompletely new hardware and forthe most part had to discover every-thing that we needed to know byourselves, the support from both SGIand Nintendo was invaluable to usthroughout the project.

Varying Shadows

E ven though we were not able tospend as much time as we would

have liked tuning the game, SHADOWS

does succeed in supplying the playerwith a variety of game-play styles. Itspopularity is a testament to the creativ-ity and talent of the team of which Iwas fortunate enough to be a part. ■

61


experiences with DirectX in generaland Direct3D Immediate Mode in par-ticular have been less than favorable.When Direct3D made its initial appear-ance, my first thought was somethingakin to, “What planet are these guysfrom?” I’ve been programmingOpenGL on PCs since it first debutedon Windows NT 3.5, so I didn’t under-stand why Microsoft would feel theneed to provide another 3D API. I likeOpenGL, I wrote a book on program-ming OpenGL, and I’m happy with it.It’s easy to understand, robust, andthere’s plenty of other folks to askquestions of, plenty of goodbooks on it, and plenty of pro-gramming examples. Direct3Dhas none of that. Microsoft neverdid provide anything resemblinga programming guide, the exam-ples required an Ouija board tounderstand, and they keptchanging the damn interface. Allvalid reasons to hate it, allacknowledged by Microsoft.

But after I read Chris’s article Ireflected back upon what a tem-pest in a teapot it all was. TheOpenGL programmers deridedDirect3D. Let’s face it, the firstrelease of Direct3D was abysmal.The game programmers whostarted (or were stuck) withDirect3D managed to get somereasonable results in spite ofDirect3D’s shortcomings, andthey, in turn, taunted theOpenGL folks about lack of dri-ver support. Hardware vendorswere annoyed because Microsoftwas telling them one thing,while John Carmack was proving

differently. The 3D graphics industryin general, and game developers in par-ticular, were shouting loudly. Veryloudly. All was in a glorious state ofturmoil. Now, is this really a badthing?

Stop and think for a minute. If youwent to the Computer GameDevelopers’ Conference or SIGGRAPHor E3 or Win-HEC last year, youcouldn’t help but notice all the videocard makers demoing both OpenGLand Direct3D software. They werefalling over themselves to show youthis stuff. They supported Direct3D

because they were scared of Microsoft(and they needed to hedge their bets incase Direct3D took off), and they sup-ported OpenGL because GLQUAKE

proved that OpenGL was a viable gam-ing API (and they needed to hedgetheir bets in case Direct3D flopped).The result of all this is that it suddenlyappears that you really will be able toprogram for either OpenGL orDirect3D, whichever API you like —although because Microsoft has cutIHVs off at the knees by dropping MCDdriver support for Windows 95, a lot ofthe video card makers are scramblingaround trying to pick up the pieces.

“Yeah,” you might be saying,“there’s been a lot of frenetic activityin the past year or so.” And you’d prob-ably agree with me that Microsoft insti-gated the whole thing by bringing outa premature implementation of

G A M E D E V E L O P E R J N A U A R Y 1 9 9 8 h t t p : / / w w w . g d m a g . c o m

64

b y R o n F o s n e rS O A P B O X

Why I Don’t Hate

Direct3D

I t was with some amusement that I read Chris

Hecker’s “An Open Letter to Microsoft” in the

April/May 1997 issue of Game Developer. I design

3D graphics software for a living, and frankly, my

Contrary to what you may think, Ron isn't a Microsoft employee. He's the author of OpenGLProgramming for Windows 95 and Windows NT published by Addison-Wesley, so hisheart is in the right place. Ron is the chief mechanic at Data Visualization, an OpenGL andDirectX custom software/driver house. You can reach him at [email protected].

Continued on page 63.

Illustration by Rick Eberly.

Direct3D and touting it as being “Theonly 3D gaming API you’ll ever need.”So ask yourself what effect this had onthe 3D community. It started the APIwars — an endless stream of vitriolicUsenet postings, a flurry of examplesand counter examples. It stirred upevery video card maker and even a fewPC makers. Hell, I don’t know aboutyou, but I had a great time!

Since Microsoft made that big boastand then tried for two years to deliveron it, there has been a veritable renais-sance of activity in 3D graphics. I usedto worry that the adoption of 3Dwould be slow, that to write a great 3Dgame would require, unreasonably,that the user have a 3D graphics accel-erator. Hah! That’s one worry that I canput to rest. This Christmas, practicallyevery PC made came with a 3D acceler-ator. There were an estimated 40 mil-lion 3D accelerator chips sold in 1997.That’s a heck of a target market. Just asyou no longer have to special order aCD-ROM or a fast Windows video cardwhen you get a PC, 3D chips are replac-ing the 2D-only systems.

Now, why has this happened? Well, Ithink it’s safe to “blame” Microsoftagain. If they hadn’t stirred things upas they did, and if the normally sedate3D graphics community hadn’t reactedso strongly, then we might still belooking toward a slow adoption of 3Das a standard feature. Direct3D certain-ly has lit a fire under the normallysedentary OpenGL ARB. The freneticpace at which Microsoft is revving theDirect3D API is forcing OpenGL tomove at a faster pace. This is good — itused to be that OpenGL was the featureleader. Now, with DirectX 5, we havehardware-optimized texture support (inthe form of optimized surfaces). That’sa feature that’s scheduled for therelease of OpenGL 1.2 sometime laterthis year. And Microsoft has no inten-

tion of letting up the pace.They recently gutted theirOpenGL graphics groupand merged them into theDirectX group (a shotgunwedding, no doubt). Whatthis means is thatDirect3D is going to con-tinue to get better, puttingmore pressure on theOpenGL side of things toincrease the pace as well.

So while I agree that lastyear, Chris raised some excellentpoints in his article in the OpenGL vs.Direct3D debate, I take the stance thatwhile Microsoft did a bad thing withDirect3D, it did provide a rude wake-up call of the 3D community. Twoyears ago, most game programmersdidn’t have a clue what a BSP tree was,what the “A” in RGBA stood for, orhow a Z-buffer worked.

Now I see video card makers pon-dering trilinear and anisotropic tex-ture filters, while Microsoft andHewlett-Packard are introducing APIswith automatic level-of-detail geome-try functionality. These are featuresthat I previously saw onlyin ultra–high-end sys-tems, that I never wouldhave thought would makeit to the PC before thenext century. While I stillhave no love forDirect3D, I admireMicrosoft for listening(somewhat) to the criti-cisms of Direct3D andaddressing them.

If the cost of getting 3D acceleratorson PCs everywhere by 1999 is that Ihave to live with Direct3D, then I canlive with it. While I personally feel thatMicrosoft was stupid to bring outDirect3D while they had OpenGL, ifthey’re going to support both of them,then I can live with having two APIs tochoose from. I’m not too happy withthe active lack of support for OpenGLthat Microsoft has demonstrated in thelast few months. I think that this is amistake that will do them more harmthan they estimate.

OpenGL on PCs has too much indus-try support to get killed from lack ofattention by Microsoft. Time will tell.Meanwhile, I’m just going to bask inthe radiant glow of 3D, giggle when Iget a new 3D board to test, play some3D games and admire those nice multi-pass rendering tricks, write some codethat does some effects from ChrisHecker’s physics articles, and sleepsoundly at night knowing that nextyear, even better 3D features will bearound for me to take advantage of. If Ihave to blame Direct3D for causingmost of this, then so be it. ■


63

W hile I agree with

Ron's point that the

past year has been

fun in the roller-

coaster sense of the word, I disagree

that Microsoft and Direct3D can take

credit for the quick adoption of 3D hard-

ware. The truth is, it's simply time for

3D on the PC, and IHVs were already

well on their way to making it common-

place by the time Direct3D was even

conceived, let alone shipping. I believe

a coherent argument can be made that

Direct3D's machinations have actually

slowed down adoption of 3D hardware,

while early standardization on OpenGL

would not have had this problem

(although I do agree the ARB moves

much faster these days). However, hind-

sight is a wonderful thing. For now —

and looking towards the future — I only

hope Ron is correct when he says, "You

really will be able to program for either

OpenGL or Direct3D." I'm not so confi-

dent, and I think it will take eternal vigi-

lance from game developers to ensure

we have a viable choice of 3D APIs from

here on out.

Editor-at-Large Chris Hecker Responds:

Continued from page 64.