november 1999twvideo01.ubm-us.net/.../gdm_november_1999.pdf · 2013-07-12 · executive vice...

NOVEMBER 1999

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

W ith one of the largestconsole launches everjust behind us and atleast two more loom-

ing on the horizon over the next 18months, many people are speculatingabout the features of these next sys-tems. Upon seeing the impressive fea-ture sets of the new consoles, somehave raised questions as to the long-term viability of the PC as a gamingplatform. It’s tough to look at a consolespec sheet, read that it has broadbandInternet access, amazing graphics andaudio capabilities, a keyboard, DVDsupport, support for electronic softwaredistribution and backwards compatibil-ity, and not see that the PC faces stiffcompetition. The traditional strengthsof the PC are being co-opted by con-soles. I for one don’t believe PC gamingwill go away, but the platform mustconfront these challenges head-on.

To grow the PC market, prices mustcontinue to drop. Fortunately they are,and it’s one reason I’m bullish on thePC’s future. One big reason for recentdrops in PC prices is the direct result ofmarketing campaigns by ISPs likeCompuserve and AOL. Compuserve, forexample, is subsidizing the cost ofCompaq, HP and eMachine entry-levelsystems to the tune of a $400 rebate atpurchase. In return, these consumers(many of them first-time PC purchasers)agree to subscribe to Compuserve forthree years at $21.95 per month. TheseISPs are gambling that it’s better tounderwrite the cost of these newmachines today and recoup that invest-ment through extended online serviceagreements. The ISP gets reimbursed forits up-front investment from thesemulti-year service agreements, it gets“content” in the form of new chat par-ticipants, more eyeballs for which it cansell advertising space on its service, andother assorted benefits. If it persuadesthese indentured servants — I mean,customers — to stay with Compuserveafter the agreement is terminated, somuch the better for the ISP. The bottomline is that as I write this, you can buy abrand new 400MHz eMachine with 15-

inch monitor and a color printer forabout $90 more than a Dreamcast.

While I’m glad that more PCs areworking their way into homes — it cer-tainly will grow the base of casualgamers — there are a couple of aspectsto these incentives that don’t bode wellfor the PC game industry. First, theserebate programs are seeding householdswith machines barely equipped to playtoday’s games. The latest graphics andaudio hardware won’t be found in a$289 computer, and without these capa-bilities, the systems offer little in termsof a cutting-edge gaming experience.Second, long-term service agreementswith online services like Compuservecould hamper the growth of broadbandaccess to the Internet, and enablingbroadband access is essential for grow-ing the online gaming market.

It would be interesting to see a majorgame publisher like Electronic Arts stepup and subsidize a line of high-endgame PCs, targeting veteran PC ownersand hard-core gamers. In return for therebate at purchase, these consumersmight agree to buy a certain number ofgames from EA over a span of years (theColumbia House music club model), orsign a multi-year subscription to a per-sistent game world like ULTIMA ONLINE.The latter option is especially intrigu-ing, since the risk to publishers of thesegames is high — developing and main-taining a persistent world is expensive,they are more difficult to manage, andmore rides on their success than withtraditional games. A publisher couldensure that when the game was built,some percentage of players would belocked into the game. A guaranteed rev-enue stream over a period of years looksgood on the books, and in the hit-or-miss world of game publishing, that’simportant to Wall Street.

Of course, there’s nothing stoppingany of the console manufacturers fromlaunching a similar rebate program toentice their customers. It may simplybe a matter of who strikes first. ■

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

4

P L A NG A M E

Can Subsidized Hardware

Save PC Gaming?

D E V E L O P E R

ON THE FRONT LINE OF GAME INNOVATION

www.gdmag.com

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

PublisherCynthia A. Blair [email protected]

EDITORIAL

Editorial DirectorAlex Dunne [email protected]

Managing EditorKimberley Van Hooser [email protected]

Departments EditorJennifer Olsen [email protected]

Art DirectorLaura Pool [email protected]

Editor-At-LargeChris Hecker [email protected]

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

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

ADVERTISING SALES

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

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

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

ADVERTISING PRODUCTION

Senior Vice President/Production Andrew A. Mickus

Advertising Production Coordinator Dave Perrotti

Reprints Stella Valdez t: 916.983.6971

MILLER FREEMAN GAME GROUP MARKETING

Marketing Director Gabe Zichermann

MarCom Manager Susan McDonald

Junior MarCom Project Manager Beena Jacob

CIRCULATION

Vice President/Circulation Jerry M. Okabe

Assistant Circulation Director Sara DeCarlo

Circulation Manager Stephanie Blake

Assistant Circulation Manager Craig Diamantine

Circulation Assistant Kausha Jackson-Crain

Newsstand Analyst Joyce Gorsuch

INTERNATIONAL LICENSING INFORMATION

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

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

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

New Productsby Jennifer Olsen

A New Chip off the Old Block

METACREATIONS has unveiled Carrara,its newest entry into the fray of “bar-gain” 3D modeling and animationpackages. The name is appropriateenough: Italy’s Carrara marble hasbeen prized for its unsurpassed qualitysince ancient times, back when a hugeslab of marble was the original model-ing environment for 3D artists.

Carrara is actually the marriage ofMetacreations’ Ray Dream Studio andInfini-D products. So what separates itfrom the rest of increasingly crowdedpack of 3D modeling and animationprograms? It has much the same laun-dry list of features and effects as manyof its competitors, including multiplerenderers, Direct3D and OpenGL sup-port, importing and exporting of mostindustry-standard 2D and 3D file for-mats, scads of shaders and presets, andan SDK for customization. However,one feature that sets it apart is its clean,attractive user interface, which lacksthe screen-clogging blizzard of buttons

characteristic of certain wildly popularhigh-end packages.

Carrara will sell for $499 and run onWindows 95/98/2000/NT 4.0 andMacintosh platforms.■ Metacreations Corp.

Carpinteria, Calif.

(805) 566-6200

http://www.metacreations.com

X-File Management and More

NXN SOFTWARE has announced Alien-brain, the successor to its groundbreak-ing asset management tool tailoredspecifically for game developers,MediaStation. Remember back in highschool when you wrote your first game?Maybe you had a few dozen files andkept track of them on the back of yourphysics homework. Whatever systemyou had, it wouldn’t work on today’sdevelopment projects which now com-prise thousands of files and mountainsof media to manage.

The folks at NxN feel your pain, andAlienbrain is their antidote to themind-boggling complexity of manag-ing a game development project. Theclient/server system includes four mod-ules to track file management, versioncontrol, process automation and pro-

ject tracking across differ-ent user groups: “Genius”is designed for the artistson your team, “Intelli-gence” for the program-mers, “Control” is thecommand center for pro-ject administrators andtool developers, and“Knowledge” is for pro-ducer-types. While thenomenclature won’t settleany debates about whothe real brains on yourteam are, each modulecontains features andfunctionality unique tothe needs of its users.

Alienbrain’s server systems requireWindows NT 4.0 or later, and clientsrequire Windows 95/98/2000/NT 4.0.Pricing was not yet finalized at presstime, but the servers are expected tocost in the neighborhood of $4,900,with client systems priced at around$1,900. NxN also offers flexible volumepricing packages.■ NxN Software AG

Munich, Germany

+49 (89) 27-32-24-0

http://www.alienbrain.com

Gearing Up for the Next Generation

CRITERION SOFTWARE has revealed thethird generation of its multi-platform3D development toolkit, Renderware.By now we’ve all gotten an idea ofwhat the near future of 3D gamingholds both for PCs and consoles. Asdemands on developers increase, plat-forms diversify and pressure builds todecrease development lead time, moredevelopers may be considering outsideresources for help.

Renderware is based on a streamlinedplug-in architecture that allows develop-ers to mix and match functionality byoverloading the pipeline with their owntools (physics or collision detection, forexample,) when they so desire. The PCversion supports Glide, OpenGL andDirect3D, with a device-independentarchitecture that will enable easier port-ing to consoles and tomorrow’s digitalTV platforms.

Renderware 3 will be available byyear’s end for PC, Playstation 2 andiMac at $1,000 per programmer perplatform per year with no royalties,and third-party plug-in development isin full swing. Linux, Dreamcast andNintendo Dolphin versions of Render-ware are also being considered.■ Criterion Software Ltd.

Guildford, Surrey, U.K.

+44 (0) 1483-406200

http://www.renderware.com

New Products: Metacreations intro-duces Carrara, NxN rolls out Alien-brain, and Criterion unveils its nextgeneration of Renderware. p. 7

Industry Watch: Dell snubs ATI,Microsoft shows off its new console,Sony divulges more PSX2 secrets, andAureal busts out with boards. p. 8

Product Review: Jeff Lander sings thepraises of multi-resolution meshes as hereports on Digimation’s MultiRes Toolkitand Plug-in for 3D Studio Max. p. 10News from the World of Game Development

7

Carrara’s modeling interface: its lack of clutter may

be inviting to some, limiting to others.

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

Industry Watchby Alex Dunne

DREAMS DO COME TRUE. Sega’s Dream-cast launch proved to be better thanthe company hoped, with preliminaryfigures indicating that $97 million insales were rung up around the U.S. on9/9/99. Sega claims it was the biggest24 hours in entertainment retail sales,easily surpassing the $28 million thatThe Phantom Menace took in on open-ing day last May.

PSX2 NEWS. Carefully timed to coin-cide with the Dreamcast launch, Sonystole some of Sega’s thunder with anumber of Playstation 2 announce-ments. The company revealed that thePSX2 will debut in Japan next March(three months later than originallyplanned, possibly due to chip manufac-turing problems), and in the U.S. andEurope next fall. Japanese consumerswill have to cough up 39,800 yen ($365at press time) for the system. Sony alsorevealed that it will distribute games viathe Internet, made possible by thePSX2’s broadband support and anupcoming hard drive Sony will sell. Tosupport this new means of distributingconsole titles, Sony is creating an elec-tronic transaction system, and an e-distribution server. In developer news,Sony will give PSX2 developers toolsthat support the regular Playstationprogramming/debugging mode as wellas a new workstation mode for creatingPSX2 graphics, all on the same system.

ENTER MICROSOFT... At ECTS, Micro-soft demo’d its upcoming console(code-named the “X-Box”) to variousdevelopers and analysts. As we go topress, no release date for this console

has been hinted at, and product specsare sketchy. But the word on the streetis that the X-Box will be based arounda 500MHz Intel chip, the NvidiaGeForce 256, a DVD drive, a multi-giga-byte hard disk, and of course, some fla-vor of Windows. Who will produce thisconsole? Not Microsoft, apparently —Dell, Gateway and Samsung have beenlined up as manufacturers.

IT’S TEN NO MORE. Total EntertainmentNetwork (TEN) ditched its name and itstarget market, deciding that the casualgame market is more lucrative than itsprevious focus on hard-core players. Thecompany, now called Pogo.com, isfocused strictly on card, trivia, boardand other “family” games. The site hasmore than 3.5 million members, andhas lined up has distribution relation-ships with @Home, Alta Vista, Cnet,Excite, Go, Netscape, and Sony.

BE LINES UP TITLES. Be Inc. and Mono-lith announced that SHOGO: MOBILE

ARMOR DIVISION will be brought to theBeOS. SHOGO will be developed and pub-lished for BeOS by Wildcard Design. AtECTS, Be showed CIVILIZATION: CALL TO

POWER, CORUM 3, and QUAKE 2 runningon its operating system.

DELL DECISION HURTS ATI. ATIacknowledged that Dell’s recent deci-sion go with Nvidia chips in itsOptiPlex computer line will cost ATI$10 million in sales per quarter. Thecompany still expects to meet fourth-quarter sales projections when itreports results on October 21, but thatdidn’t quell some panicked investors,and trading of ATI’s stock was haltedon both the Toronto and Nasdaqexchanges after the company revealedthe cost of that lost deal. ATI pointsout that it will still supply Dell’s note-

book PCs, and that its relation-ship with the big computercompany is still strong.

AUREAL LAUNCHES CARDS.Aureal entered the board busi-ness and is shipping two newAureal-branded sound cards,the Vortex SQ1500 and theVortex2 SQ2500. The newcards are marketed under theAureal name by I/OMagicCorporation, and are support-ed by a multimillion dollar

marketing campaign. Based onAureal’s AU8810 processor, theSQ1500 supports A3D 1.0 and featuresa 512-voice wavetable synthesizer. TheSQ2500 is based on a new version ofthe Vortex2 AU8830 processor andsupports A3D 2.0 with a 576-voicewavetable synthesizer. ■

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

8

1999 GDC RoadTrips

OGDEN ECCLES CONFERENCE

CENTER

Salt Lake City, UtahNovember 1, 1999

THOMPSON CONFERENCE CENTER

AT THE UNIVERSITY OF TEXAS

Austin, Tex.November 3, 1999

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

Software Development East

WASHINGTON CONVENTION CENTER

Washington, D.C.November 8–12, 1999Cost: variablehttp://www.sdexpo.com

RE:Play Real World Conference

TISCHMAN AUDITORIUM AT THE

PARSONS SCHOOL OF DESIGN

New York, N.Y.November 13, 1999Cost: freehttp://www.eyebeam.org/replay

Comdex Fall

SANDS EXPO & CONVENTION CENTER

Las Vegas, Nev.November 15–19, 1999Cost: variablehttp://www.comdex.com

UPCOMING EVENTS

CALENDAR

Sony took advantage of the Dreamcast launch

to divulge more tidbits about the Playstation 2.

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

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

10 Digimation’sMultiRes

by Jeff Lander

S calable 3D graphics has been amajor event in 3D graphics thispast year. With so many differ-

ent gaming platforms and such a varietyof graphics cards, making content thatperforms similarly on all systems is areal challenge. Game developers havecommonly used different level-of-detailmodels to balance the performance.However, creating LOD models is a timeconsuming and tedious project for anygame artist. Furthermore, dynamicallychanging between LOD models duringthe game can lead to annoying poppingas they switch. Graphics researchershave been promoting the idea of con-tinuous LOD algorithms for 3D models.In these algorithms, the model willsmoothly scale from very high to verylow polygon counts. In fact, Stan Melaxwrote an article in this magazine aboutimplementing a continuous LOD sys-tem (“A Simple, Fast, and EffectivePolygon Reduction Algorithm,” Novem-ber 1998). However, creating a systemthat handles all the lighting and textureinformation and smoothly integratesinto your production is a task thatcould easily tie up developmentresources for some time.

I DON’T HAVE THAT KIND OF TIME. Withthis in mind, I looked with interest atseveral commercially available continu-ous LOD systems at Siggraph 1998.One of these was a very interesting sys-tem developed by Intel. At the time,the project was not quite ready to be aproduct, but looked very promising.Well, at the GDC this year, Intelunveiled the fruits of this labor. Theyhave teamed up with Digimation toproduce the MultiRes Software Toolkitand Plug-in for 3D Studio Max.

The MultiRes Plug-in enhances 3DStudio Max by providing a method forreducing a high polygon mesh to alower polygon count mesh. In this way,the plug-in is similar to the Optimizeroutine that is built into 3D StudioMax. However, MultiRes is quite a bitmore powerful. For example, you canset exact polygon count targets as wellas a reduction percentage. Also, Multi-Res does an excellent job of preservingtexture coordinates and vertex normals.Artists are even able to fine-tune thereduction algorithm by a variety of con-trols as well as selecting the vertices notto remove.

As a modeling tool alone, this pro-vides a pretty powerful and useful wayfor artists to craft content. However, thereal power of MultiRes is realized bycreating a multi-resolution mesh. Thisspecial mesh file contains all the infor-

mation needed to create a mesh thatcan dynamically scale from its full reso-lution down to 1 polygon composed of3 vertices. This MultiRes mesh can thenbe used directly in your game as scal-able content. It can also be exportedinto the MetaStream 3D format that isused with tools from MetaCreations toview scalable 3D models on the web.

You can see an example of MRM inaction in Figure 1. The first image is theoriginal mesh at 6,126 vertices or11,766 faces. I then reduced this downto just 64 vertices for 120 faces. Obvi-ously, this looks pretty bad up close, butwhen the object gets far away it looksfine. The MRM algorithm preserved theoutline of the arms and legs. This iswhere real-time use of MultiRes reallymakes a difference. A herd of these ani-mals at full resolution would grind anysystem to a halt. But a herd of them at120 polygons is perfectly reasonable.HOW DO I USE IT? If you are a 3D StudioMax user, the plug-in couldn’t be anyeasier. You simply select your modeland select the plug-in from the Modifi-er panel. You can then “Generate” theMultiRes mesh and start interactivelyreducing the vertex count in themodel. The default generation optionsdo a good job of mesh reduction formany models. However, you can reallyfine-tune the operation.

The “Vertex Merging” option allowsyou to determine whether or notunconnected areas of the mesh will bemerged as the reduction proceeds. Youspecify the maximum distance in 3DSMax units that the algorithm will con-sider for merging. This can be useful ifyour mesh is composed of parts thatare not topologically connected.

“Boundary Metric” gives you theoptions with respect to any materialchanges in to model. It will then try toavoid collapsing vertices that crossthese material boundaries.

Most of the time, the algorithmalong with these options will allowyou to create a good mesh. However,there are times that you will want toselect vertices that you do not want tocollapse in the model. Perhaps there isa feature in the model that is distinctand you wish to be preserved. You canselect the “Maintain Base Vertices”option and then select the vertices youwish to preserve. These vertices willthen be maintained throughout thereduction process.

Jeff Lander is always trying to find a tool to make his life easier and cut down onunnecessary work at Darwin 3D. If you can recommend any nifty tools, pass themon to [email protected].

F I G U R E 1 . The bottom dinosaur’s

face count has been reduced dramati-

cally, but looks fine from a distance.

Excellent Very Good Average PoorBelow Average

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

11

The final option determines how thenormals in the model will be handled.While vertices are removed, the topolo-gy can change pretty dramatically. Youcan simply use the original vertex nor-mals throughout the reduction. Other-wise, by setting the “Multiple Normalsper vertex” option, the system will cre-ate new normals based on the surround-ing faces as the model reduces. Thisoption comes at the cost of increasingthe number of update records that mustbe recorded. Whether or not this isneeded depends greatly on your applica-tion and models.

That’s all there is to it. Once you arehappy with the reduction, you can saveit out, ready to use in your application.BUT I DON’T USE MAX. If you don’t use3D Studio Max, you won’t get the bene-fit of this nifty plug-in. However, the

benefits of MultiRes are still available toyou. The MultiRes Software toolkit con-tains all the functions you will need tocreate a scalable mesh. You simply setthe parameters for the reduction andsubmit a structure containing all thevertices, normals, and faces in themodel to the GenerateMRM function.

I found it very easy to take modelscreated in Softimage and convert theminto a MRM by modifying the Digima-tion sample viewer. This would be easyto do for any polygonal model.SO HOW DO I USE IT IN MY GAME? Now Ihave a nice MRM all ready to go and Iwant to use it in my game application.The examples provided with theSoftware Toolkit make this easy. Thereis both a Direct3D and OpenGL exam-ple of working with a MultiRes mesh.

One thing developers will appreciateis that while the MRM generation func-tions are in a Dynamic Link Library(DLL), all the run-time code needed todisplay and manipulate the meshes arestraight C. You need no extra librariesto ship with your project. This alsomakes it possible to use the MRM tech-nology on game consoles.

Also, as the algorithm works bychanging the connectivity of themeshes, the actual vertices are leftalone. This means that the MultiResalgorithm can work with most anima-tion schemes such as skeletal deforma-tion, morphing, or even QUAKE-stylemesh flipping.OTHER FEATURES. The MultiRes Toolkitalso offers another very valuable feature.In order to render polygonal meshes inthe fastest way possible, many 3Dgraphics cards prefer to receive the

meshes as triangle strips. These stripscan be tricky to create and often requirecustom tools to generate them.

MultiRes provides a way to generatetriangle strips from a polygonal model.However, since the model’s topologychanges, as the level of detail changesan initial triangle strip would becomeinvalid. To address this issue, the Multi-Res Toolkit provides a way to generatetriangle strips on the fly. Very cool...WHAT’S THE BOTTOM LINE? The 3DS MaxMultiRes plug-in is $295. By itself, thisplug-in may be of use to Max modelerswho wish to have a better polygonreduction tool or want to generateMetaStream objects for web viewing. Ifyou don’t use Max or really want thegame interactivity, this is probably notfor you.

The MultiRes Software Toolkitincludes three license copies of the Maxplug-in as well as all the libraries andcode needed to generate and displaycontinuous LOD meshes. The cost ofthe toolkit is a flat fee of $5,995 per fin-ished game title. When you consider allthe technology included and theamount of development time it wouldtake to create this functionality, thisseems like a great deal to me.

Obviously, I’m not the only one whothinks this is interesting. Both Valvewith TEAM FORTRESS 2 and PandemicStudios with DARK REIGN 2 have licensedthe MultiRes Toolkit for their upcoming3D titles. I expect many more to follow.

MultiRes is the first commercial pro-ject to come out of the collaborationbetween Intel and Digimation. I cer-tainly look forward to other productsthat come of this partnership. ■

Digimation Inc.St. Rose, La.(800) 854-4496http://www.digimation.com

Price: Plug-in is $295.Software toolkit is$5,995 per finishedgame, including threecopies of the plug-in.

Software Requirements:Windows 95/98/2000/NT 4.0; 3D Studio Maxfor the plug-in.

Pros:

1. Full source code for plug-in and run-time modulesfor Direct 3D andOpenGL.

2. High-quality polygon-reduction algorithm withgreat performance.

3. No per-copy royalties ongame sales.

Cons:

1. Plug-in only comes for3D Studio Max. Users ofother packages must rolltheir own conversionprograms from libraryincluded in SDK.

2. Toolkit cost is up-frontalthough pretty reason-able.

3. Users will need to adapttheir game engines towork with the multi-resolution meshes.

MultiRes:

F I G U R E 2 . The MultiRes user

interface.

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

In fact, many of these objects are noteven just lying around looking allorganic. They slop, splash, waddle, andplop about you all the time. Manyshapes around you are even in motion.These objects change shape effortlesslyas you game artists crumple under thepressure of having to model such phe-nomena. When was the last time yousaw a nice splashing fountain in agame, anyway?

Animators have faced the challengeof visually creating the organic worldwe live in for some time now. To helpthem out, commercial modeling pack-ages have provided the artist with toolsfor creating organic shapes. One of themethods for creating organic objects isthrough the use of blobby balls thatcan be combined together to form aclay-like sculpture. The commercialanimation package developers haverealized the usefulness of this tech-nique and coined all sorts of propri-etary terms for their version. You mayhave seen ads for meta-balls, meta-clay,blob-modeling, and various other waysof combining the term “meta” withsome form of goop.

To create an object from this meta-goop, an artist drags around primitiveelements, usually spheres, which repre-sent the rough shape of the object.Each of these elements has a centerposition and several parameters associ-ated with it. These parameters definehow the element will interact with theparticles and world surrounding it. Youcan see an example structure for ameta-goop particle in Listing 1.

The position describes the center ofthe element. I also need to keep trackof the radius of influence of the ele-

ment (actually squared so I save somemath later) and the strength of the ele-ment. This strength parameter defineshow the element will affect the spacesurrounding it.

The elements interact with eachother by creating an energy fieldaround them. This is similar to theway planets create a gravitational fieldfor a solar system. It is possible to eval-uate the energy of the system at anarbitrary point in space. The formulato determine the amount of energythat an element contributes to thepoint is given as:distance = squaredDistance(&goop->

position,&testPosition);

if (distance < goop->radiusSquared)

{

falloff = 1.0f - (distance/goop->

radiusSquared);

fieldStrength += goop->strength * falloff

* falloff;

}

By running this formula over all theelements in your system, you get theexact field strength for that position.The energy field creates some interest-

ing data but is not much of an object.What I want to create are particles thatwill visually grow together as they getcloser. You can see an example inFigure 1. In order to create an objectthat will show this visual aspect of theenergy field, it is necessary to define avalue that will represent the outer shellof the object — the threshold.

The energy field varies in strengthfrom zero on up at any position youmay evaluate. In fact, there is nothingto keep you from defining negativestrength for an element, creating nega-tive regions, or holes, in the energyfield. This is useful for effects such asdenting and the like. To define the sur-face of the object in the field, I can setan arbitrary threshold giving the objectits final shape.

The threshold value defines theboundary between the area inside and

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

13

The Blobs Go Marching

Two by Two

T his may come as a shock to some, but the world is not made up of corridors

composed of completely planar surfaces. We live in a wildly organic place.

Hills roll, muscles bulge and fountains splash. The world around you is

filled with organic shapes which cannot easily be created out of triangles.

When not splashing gloop around his kitchen floor, Jeff can be found creating real-time graphics applications at Darwin 3D. Fling some bits of your own his way [email protected].

typedel tMetaGoop

{

tVector position;

float radiusSquared;

float strength;

};

L I S T I N G 1 . A meta-goop particle.

The "meta-goop" seen here produces

results that are difficult to create with

traditional modeling techniques.

the area outside the shell of the object.Figure 2 shows how an example thresh-old value creates a boundary in a 2Denergy field created by three meta-goopentities.

By adjusting this threshold value forthe energy field, as well as adjustingthe strength, position, and effectiveradius of individual entities, a greatvariety of objects can be created. But Istill need to talk about how.

Walking on Eggshells

B y creating a few meta-goop parti-cles and setting some values for

them, I have created my meta-goopsystem. Run that goop through a func-tion that evaluates the energy field,apply a surface threshold, and I havethe surface shell for the meta-goopobject defined. But the problemremains, how do I draw it?

I could step across the entire 3Dspace defined by entity radii and eval-uate the field. Anywhere the returnedvalue is equal to the threshold, I coulddraw a solid cube the size of the stepstaken. This sounds pretty good.Sounds like it would work. Actually, itsounds kind of familiar. It soundskind of like volume rendering of vox-els for applications such as viewingCAT scan data. In fact, that is exactly

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

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

14

F I G U R E 1 . Our goal is to make our three particles visually grow together as they get closer to one another.

what I would be doing if I took thisapproach.

However, rendering the energy fieldthis way can lead to pretty chunky look-ing images unless the step size is fairlysmall. This is because the energy field iscontinuous over the entire range of themodel world. However, the steps I tookwalking across the field are in discretesteps. If the steps are too big, the imagecan look chunky. This is analogous todrawing a line on a computer graphicsscreen. If the resolution of the screen istoo low, the line can look very jagged.This unfortunate condition is known as“the jaggies” and requires some form ofsmoothing or antialiasing to make thelines look better.

Unfortunately, decreasing the stepsize in my energy field will greatlyincrease the amount of calculationsthat must be made. Therefore, it is nec-essary to find a way to smooth out thevoxel image — sort of antialias themeta-surface.

CAT Scans and Game Development

F ortunately for me, the graphicvisualization and medical imaging

industries have been dealing with thisissue for quite some time. Wyvill andMcPheeters in 1986 and Lorenson andCline in 1987 independently devel-oped a system called “marchingcubes” which enables you to render apolygonal approximation of a voxelfield. One possible unfortunate cir-cumstance is that this algorithm maybe tainted by a software patent and Iam investigating how this will affect

the issue (see Sidebar).That aside, the way marching cubes

works is pretty simple. Divide theregion you wish to render into a regu-lar 3D grid. Evaluate the energy field ateach position on this grid. Now, con-sider the grid cube by cube. If the ener-gy function at all eight corners of thecube are less than the threshold level,the entire cube is outside the meta-

object and the cube can be ignoredcompletely. Likewise, if the corners areall greater than the threshold, the cubeis completely inside the object and canalso be ignored. The only cubes thatneed further consideration are thosethat have corners both inside and out-side the meta-object. These cubes areon the object surface and will be partof the final render.


15

F I G U R E 2 . Creating a boundary threshold in a

2D energy field.

A s many of you who have met

me and heard me rant on

the topic know, I believe

algorithmic software

patents are totally wrong. I feel they

completely halt continued development

down interesting research pathways by

shrouding a topic with legal pitfalls.

Graphics researchers create progress by

building on the work done by others

before them. I like to imagine the state of

the industry if Bresenham had patented

his method for drawing a line on a graph-

ic display and then charged a licensing

fee for every line drawn.

The topic of volume rendering is an

interesting case in point. As an obvious

next step in the visualization of volume

data, it was reported by researchers in

several publications. However, General

Electric apparently owns a patent on the

technique via the Lorenson and Cline

implementation (U.S. patent

#4,710,876). As an actual apparatus to

display medical imaging data, I can

understand it. However, the patenting of

a “method for displaying three-dimen-

sional surface images” seems pretty

broad to me.

I have been told by someone via e-mail

that GE aggressively enforces this patent.

However, it is not clear to me how this

would apply to the rendering of an isosur-

face in a game. Does this mean that any

modeling program using these tech-

niques must pay a license to GE? If I cre-

ate a game using a derivative of marching

cubes and it is a big hit, am I going to

receive a stealth patent letter in the mail

demanding a percentage? How derivative

does it need to be? The prior art on this

topic seems limitless, but what can I use

as a reference and still be safe?

With the record number of software

patents being filed, this is going to

become an increasingly difficult issue for

game developers in the future. I am

actively researching the issue and hope

to report on the results in a later column.

Anyone with information on the topic,

please let me know. In the meantime,

always document your research from

public journals as best you can. Igno-

rance is not bliss in this situation.

The Marching Cubes Patent Question

void FindIntersection( tVector *a, tVector *b,

float aVal, float bVal,

float thresh, tVector *result)

{

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

tVector diff;

float ratio;

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

VectorSubtract( a, b, &diff);

ratio = (thresh - aVal) / (bVal - aVal);

VectorMultiply( &diff, ratio);

VectorSubtract(a,&diff,result);

if (aVal > bVal)

}

L I S T I N G 2 . Finding the intersection point.

A cube has eight vertices. Thatmeans that there are 256 possible com-binations of how a surface can intersectwith the cube. If you consider symme-try, the number of possibilities reducesto 14. Much of the literature on surfacegeneration using the marching cubesroutine deals with optimizing for those14 special cases.

However, there is an easier way Ihave seen termed “marching pyramid.”If you consider a cube of eight verticesas being composed of five tetrahedronswith four vertices each, the problem isgreatly simplified. There are now onlythree very simple cases to deal with.The cases are the following:

1. One vertex is inside the surfaceand the rest outside.

2. One vertex outside the surfaceand the rest inside.

3. Two vertices outside and twoinside.

That is all I need to consider. In cases1 and 2, a single triangle is generated.In case 3, two triangles are generated.You can see the three cases representedin Figures 3a–c.

Once the vertices of the pyramid areclassified, the actual vertex positionsof the triangles created are obtainedby linear interpolation of the cornervalues along each edge. You can seethe code for this in Listing 2. As thereare five tetrahedrons making up eachcube, the number of triangles generat-ed with the marching pyramid tech-nique is greater than what would becreated from simple marching cubes.However, the classification and cre-ation step is much simpler and theresultant surface is a more accurateapproximation of the surface. On cur-

rent 3D graphics hardware, the extratriangles shouldn’t affect performancetoo much.

Goopy Games

Ihope it is now clear that these meta-goop techniques can be used to cre-

ate interesting organic objects suitablefor real-time display. However, thereare several aspects that actually makethem ideal for use in games. For one,they are procedurally created. Complexstructures can be generated from sim-ple data structures consisting of thelocation and attributes of each particlein the system. There is no need to storea complete mesh.

In addition, the meta-object can betessellated to different levels depend-ing on the initial grid size of the voxelspace. This gives the game a dynamiclevel-of-detail component that isneeded in these days of varying hard-ware performance.

You can attempt generation of theobjects in real time through efficientoptimization of the surface approxima-tion routine. You could also simplydecide to create the objects at load timeand display them as traditional polygo-nal objects during the actual game, orevaluate the mesh only when the stateof the goop elements changes. Thiskind of flexibility makes for easy inte-gration into a variety of applications.

I didn’t even discuss how the sur-faces could be rendered. One obviouschoice would be to apply environ-ment-mapping techniques to createthe chrome creature from Terminator 2.Likewise, you could apply bump-map-

ping techniques to bring a water crea-ture to life. I think an interestingapplication would be to combinemeta-surface techniques to a particlesystem like the one I described lastsummer (“Spray in Your Face,”Graphic Content, July 1998).

For more fun, get my demo applica-tion off the Game Developer web site(http://www.gdmag.com). This willallow you to play with the creation ofmeta-goop and start spreading someslop around your games. ■

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


16

• Greene, Ned. “Voxel Space Automata:

Modeling with Stochastic Growth Pro-

cesses in Voxel Space (Proceedings of

Siggraph 89).” Computer Graphics,

Vol. 23, No. 4 (Aug. 1989): pp. 175–184.

• Lorensen, William, and Harvey Cline.

“Marching Cubes: A High Resolution

3D Surface Construction Algorithm

(Proceedings of Siggraph 87).” Com-

puter Graphics Vol. 21, No. 4 (Aug.

1987): pp. 163–169.

• Watt, Alan, and Mark Watt. Advanced

Animation and Rendering Techniques.

Reading, Mass: Addison-Wesley, 1993.

• Wyvill, Geoff, Craig McPheeters, and

Brian Wyvill. “Data Structure for Soft

Objects.” The Visual Computer Vol. 2,

No. 4 (Aug. 1986): pp. 227–234.

Web Resources• http://www.students.cs.ruu.nl/

people/jedik/Methods/

Surface_fitting/Marching_cubes.htm

• http://www.swin.edu.au/astronomy/

pbourke/modelling

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

F I G U R E 3 C . Two vertices outside

and two inside create two tringles.

F I G U R E 3 B . One vertex outside and

the rest inside also make one triangle.

F I G U R E 3 A . One vertex inside and

the rest outside create one triangle.

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

debate when it comes to character ani-mation: keyframing vs. motion capture.

Analogous to the classic Luddite/Promethean struggle that occurs still inthe scientific community, animatorstend to divide themselves into twocamps. On one side you have the puristswho believe mo-cap is the evil productof technology run by marketing blow-hards. On the other you have the strate-gist artist who is constantly looking forthe better, faster way to get the jobdone. Because in the end if your artworkis featured in a computer game and nota gallery in New York City, it boils downsimply to getting the job done.

Mo-cap can and will help get the job

done faster and better. Like any othertool available to the computer artist/ani-mator today, it can be used in variousways to various degrees. What I’m goingto do is demonstrate a situation inwhich motion capture and keyframingcan be married — no, have to be marriedtogether — to form a solution for oneinstance of character animation.

I’ve Got My Eye on You

M eet Orbb. He’s cool. He’s a charac-ter we created for QUAKE 3: ARENA

(with textures by Kenneth Scott) solelyfor the weirdness of making him run

around on his hands (Figure 1). Becauseof the animation system of the game,affording or even showing off any typeof complex finger animations is impos-sible. However, using a little bit of prob-lem solving Orbb becomes a great exper-iment in evenly combining motioncapture and keyframed animation.

I’ll explain. Figure 2 shows a moreorthographic view of our ocular, podi-atrically-challenged little friend. In theQ3A game engine, each character mustbe divided into three distinct parts:head, torso and legs. The parts are tiedtogether using a simple triangle tag sys-tem (match tab a to tab b). The headand torso basically move around when

you move your mousearound (free look) with thehead motions slightly lead-ing those of the torso. Thelegs are purely locomotiveand couldn’t care less whatthe upper body does. Ofcourse, death animations areall-body inclusive.

So in Orbb’s case his handshave essentially become hislegs, his body casing becamehis torso and his eyeballbecame his head. Setting upand attaching him to a bipedin Character Studio turns outlooking something like whatwe have in Figure 3.

Notice that I didn’t givehim arms and that the headand torso aren’t linked to an


19

Mo-Cap and Keyframing,

Sittin’ in a Tree

A s an artist, you’ve heard at one time or another some pretty common

arguments: photo reference vs. “from memory,” tracing vs. hand-

drawing, or scanned images vs. hand-painted ones done in Photoshop.

However, for animators working on computer games today, there’s a new

Still a form of computer game artist concentrate (just add imported beer) nearly 35 years in the making, Paul Steed (simply labeled“Steed” for easier marketability) will hopefully be applied to a new project by the time you read this. As usual, product informationcan be attained by dropping a line to [email protected].

F I G U R E 2 . An orthographic view of Orbb’s pecu-

liar anatomy.

F I G U R E 1 . Q3A’s Orbb marches to

the beat of a different drummer.

underlying skeleton. The reason for thisis that I intend to apply mo-cap data inthe form of death animations and loco-motive animations mainly to the legs(arms), but I’m going to keyframe thefingers (toes), body and head anima-tions. I won’t even concern myself withwhat the unused skeletal parts of thebiped do at this point since, givenOrbb’s unique anatomy, they don’tmatter (and I can’t delete them).

So, taking a motion-captured runcycle I plug it into the character’s skele-ton (Figure 4). Something doesn’t quitelook right here. If indeed those are sup-

posed to be arms, the elbows aren’tquite bending right, now are they? Andthose toes sure don’t look like prehen-sile digits. So my dilemma is how tomake the legs act like legs while bend-ing like arms. I wonder if I can turn theleg around in the up axis? First I’lldetach the mesh from the skeleton,then select the upper thigh and rotateit so the knee faces the opposite direc-tion (Figure 5).

Cool. Now we can apply the samemo-cap run data to the now-reversedlegs and see what it looks like (Figure6). This looks better. Next we reattachthe mesh to the skeleton and keyframethose fingers...er, toes, doing some-thing cool like pushing off, flicking outas they push off, and so on. Doing thiskeyframe work on the hands results inposes like the ones shown in Figure 7.

In adding keyframes to the fingers Itry to exaggerate the motions a little.Just as a stage actor wears tons of make-up in order to be visible from the backrow, amplifying animations is just asimportant in real-time games. Charac-ters running around in a game likeQ3A usually don’t appear very large asyou’re trying to stuff rockets downtheir throat from afar.

So after applying the mo-cap data tothe arms and keyframing the handsand fingers, Orbb runs like he’s sup-posed to (Figure 8). I basically get toutilize all my animation files such asdeaths, jumps, backpedals, walks, shuf-fles, or whatever, for Orbb’s animationset as it pertains to his legs and centerof gravity. I have to make some grossadjustments to make sure his weightdistribution appears correct, but overall

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


20

F I G U R E 8 . Mo-cap and keyframe data combined to produce our finished run cycle.

F I G U R E 7. Keyframing offers us the precision to devise some cool hand poses.

F I G U R E 6 . Adding the mo-cap data to the reversed legs gives better results.

F I G U R E 5 . Rotating the legs will

make them act more like arms.

F I G U R E 4 . Orbb’s run cycle still needs work after plugging in the mo-cap data.

F I G U R E 3 . Orbb has been attached

to a regular biped skeleton.

they work out pretty well. Once thelocomotive animations are in, Ikeyframe the head and body casing toreact accordingly.

This is just one of many possible situ-ations that can support both motioncapture and keyframing. However youlook at it, mo-cap is just as useful askeyframing if you have a basic under-standing of character animation andexperience with keyframes. Rather thanturning your nose up at an animationaid such as mo-cap, it behooves you atleast to explore the potential benefit ofthe technology. After all, it’s just...

...A Tool Like Any Other

A long time ago when I first startedweight-training, I voiced my frus-

tration at being so weak. This old baldguy from the monastery on base whowas spotting me said, “Always remem-ber, Grasshopper, the weights are atool, not a measurement.” The sameapplies to the methods and tools weuse to create character animation withthe computer. The character animatortoday no more becomes a talentlesshack because he uses mo-cap than amaster illustrator shows his inadequa-cies because he uses photographic ref-erence for his painting.

I did my first animations back inhigh school when I’d have little stickpeople dancing along the edges of mytextbooks running, fighting, somer-saulting or just plain being lewd. ThenI got into comic books and begantelling stories with splash pages andsequential story art (panels) à la Kirby,Buscema, Byrne, Golden and Miller.Comic art or comic strips are the mostbasic example of keyframes. While notas literal as flipping a page and watch-ing a little stick man come to life, eachpanel in a superhero comic is a staticrepresentation of a continuing dialogand dynamic flow for which your brain(instead of the computer) provides the“tween” frames.

Learning to draw and portray char-acters in this fashion is perfect basictraining for character animation, sinceit forces you to see things in yourmind clearly enough to put themdown on paper. This translation ofthought to media and, more impor-tantly, the ability to recognize a suc-cessful translation is the key to better

character animation because it givesyou “the eye.”

Simply put, having the eye meansyou can look at something and see itto be either one of two ways: right orwrong. If it’s right then you can moveon to the next task. If it’s wrong, youkeep working on it until you make itright. So many times someone showsme something or e-mails me someanimation sequence and asks myopinion. When it’s so bad that I don’tknow where to start with a meaning-ful critique I simply ask, “Does it lookright to you?”

QUAKE 3: ARENA marks the first timeI’ve personally dealt with mo-cap out-side of the annual obligatory dog-and-pony shows at Siggraph and other tradeevents. I decided to try the mo-caproute because it’s dead easy inCharacter Studio and for the simple rea-son our frame rate went from 10 FPS inQUAKE 2 to 15–25 FPS (depending onthe animation). Turning to mo-capmakes sense as frame rates increase,since keyframing the subtle and nearlyimperceptible nuances of humanoidcharacter animation, if not difficult, isat least time-consuming. The differencebetween a six-frame run cycle and a 13-frame run cycle is obvious to say theleast. Another reason is that my fellowanimator Kevin Cloud decided to con-centrate on other art aspects and leaveme to do all the models and animations(nice of him, wasn’t it?), so findingways to save time became a priority.

However, to say that I find myselfforgetting how to keyframe becauseI’ve implemented mo-cap into theworkflow is just plain ludicrous. Mo-cap is a start and, if anything, a roughtiming guide to assist your keyframing.I have yet to implement any motion-captured animation without at leastsome keyframed adjustment. This isnot a problem for me.

The Mo-Cap Experience

T he first session I did was with GregPyros and his crew at Pyros Pic-

tures. An amazing martial artist andactor, T.J. Storm, and a fellow actress,Bobbi, were the talent for my first runat making animations for the charactersin Q3A. I learned a lot from the session,but since it was my first time I came upa little short in preplanning and accu-

rately predicting the implementation ofthe data in my animations. I also didn’tknow Character Studio very well at thetime and failed to exploit its strengthsand allow for its shortcomings. Know-ing your pipeline and knowing all yoursoftware is crucial to successful mo-capimplementations.

When I did my next session I went toHouse of Moves. The crew at HOM defi-nitely know their stuff and they weregreat to work with. I was quicklyallowed to review the motions capturedin crude wireframe playback to see if itwas what I wanted. HOM also gave mevideotape that matched the capturedmoves for both review and reference.There were differences dealing withHouse of Moves, but the most over-whelming difference was that I suitedup to do most of the motions myself.

I consider myself to be in reasonablygood shape so I wasn’t afraid of thephysicality of the shoot. Since I’m aham at heart I knew I could act wellenough to get reasonably expressivemotions based on what I’d seen T.J. doat the earlier shoot, and more impor-tantly, to get what I wanted from thecharacters I had already created. How-ever, I fully realize that I’m in a uniqueposition to have more freedom thanmost artists at most companies. It’sgreat being the modeler, animator,mo-cap director and mo-cap actor. Iget to make sure I get exactly what Iwant and need to get the animationsright. I enjoyed the HOM shoot somuch that when I did my third sessionjust recently I decided to be the “tal-ent” once again.

This time however, I decided to tryyet another company a whole lot closerto home. Located in the idyllic, rollinghills and fauna of Wimberly, Tex., nearAustin, Kei and the crew at LocomotionStudios provided a comfortable, relaxedand professional atmosphere (exceptthey didn’t have any beer stocked).

The animations I went for this timewere more scripted than the animationsI did at the other two studios, so it wasmore important for me to give a betterperformance. Instead being piecedtogether and used by the charactersduring real-time game play, these ani-mations would be plugged into thecharacters mostly as-is to be used forrendered cutscenes. This is a greatexample of mo-cap saving you time ona project since the amount of work it



22

would take to make the subtle, expres-sive, realistic nuances I wanted in theanimations would have taken far longerthan I have to do them. Even in aworst-case scenario where the anima-tion is too wooden, keyframe augmen-tation can still save the day utilizingaccurate timing if nothing else.

In addition to offering immediateplayback of the captured animation tosee if it was what I wanted, Locomotiontook the process one step further byfilming the captures in MPEG format,giving me a digital movie of the perfor-mance. This proved extremely conve-nient, more so than videotape.

Extremely accommodating like theother studios, they were tolerantwhen I got wacky. For example, onething I did for a particular characterwith a three-jointed leg was to walkbackwards in order to give it a creepyquality when it walked forward. Tosupport this, the guys at Locomotionquickly and easily played back the ani-mation in reverse, which allowed meto adjust my performance until I got itright. Oh, and do you want to knowthe best thing about the session at

Locomotion? Soft reflector balls. Trustme, when you’re covered with thehard ones, your potential for lots ofpain while doing mo-cap is high.

Just Where Do I Go for Mo-Cap?

A s I’ve said, time-saving is anotherattractive quality of motion cap-

ture, but one that gets argued by artistsbecause of the heavy cleanup required.That’s what mo-cap service housessuch as Pyros Pictures, House of Movesand Locomotion are for. You can letthem do the clean up instead. By thetime you’ve made the space, spent themoney and trained the artists to sup-port your own motion capture facility,the overall cost will be hard to beat bysimply going to an expert. Having dealtwith three of these companies that pro-vide such a service in the past year hasgiven me a fast and comprehensiveunderstanding of the motion captureprocess. Understanding this processfrom start to finish is a necessity if youplan on using mo-cap.

Therefore, consider the following as

you tread down the motion-capturestudio path. It could mean the differ-ence between success or failure:PREPLAN. By preplanning I mean story-board, either literally or in your mind,each move you plan on getting. Ensurethere are one or two people who trackand manage the process from start tofinish (you, the artist, being one ofthem). Also, come up with good filenames for your motions. I usually stickto a six-character naming conventionbecause it leaves room for different ver-sions (takes) later on. Calculate theamount of time in seconds you esti-mate each motion will last and then atotal for the shoot. Use that number offinished seconds as a starting pointwhen you negotiate a price.GET A BID. Once your list is formed, startshopping around. Just be sure youhave a very clear idea of what youwant before presenting it to a mo-capstudio. Don’t be afraid to start a bid-ding war. These guys know howimportant patronage and word ofmouth are in our industry.GET GOOD TALENT. Although I really enjoydoing my own capture sessions, next


23

time I’ll go back to paying some-one else to hit the ground andwrithe around in real...er, mockpain. I’ve found the key to get-ting a good performance is tofind actors who are almostmime-like in their expressionsand motions. Also remind youractor to go full speed and notslow down during performance.This may not be somethingreadily apparent, but overactingor being overly conscious ofdevices tracking your everymovement can be very obviousin the finished data. I’ve had tocut up to ten percent of thekeyframes in any given mo-capfile due to the actor being toomeasured in his or her move-ments, or make substantialtweaks because hands were usedto break a fall (or to remove other glar-ing forms of anticipation). If you havethe inclination and the ability, I highlyrecommend doing your own motions atleast once. It makes you appreciate whatyou ask the talent to do in all those hardreflector balls.GET THE MOTION YOU WANT. Not much else Ican say here. You’re the client. You’replopping down the cash (usually 30percent or so up front when you showup at the studio). You decide when thecaptured motion is right. Insist on avideo or MPEG of the performance toreview and just have around. If any-thing, it’s something to show your bossand co-workers.CHOOSE YOUR IN AND OUT TIMES. Basically,the in and out times are the points atwhich you want the motions you seeon video to start and stop recording.This is obviously just so the mo-capstudio can calculate your total numberof seconds captured, giving you exactlywhat you want when it happens. Butnever underestimate that little hitch ormovement right at the beginning orend of a motion. While it’s prudent notto pay for useless seconds of idle move-ment, you might be able to take a partof one motion and use it in combina-tion with keyframes somewhere else.IMPLEMENT THE CLEANED DATA. Once thedata is delivered, plug it into your char-acter and see how it works. I did cap-tures for a character and decided I didn’tlike the implementation and just cut itfrom the list. Occasionally, some thingsreally do just look better on paper.

PAY THE GUY. Guess this is the bottomline, isn’t it? Rates vary, but if youshop around, like I’ve already suggest-ed, you’ll get the fairest price. Theprice of motion capture seems to keepdropping every time I get it done. Thistrend will no doubt continue as tech-nology advances.

Speaking of cost, it is something toconsider. For a small developer, usinga mo-cap studio may be cost-prohibi-tive, but I’d encourage you to check itout anyway. All the people I’veworked with have been extremelyaccommodating and flexible whentrying to get my business. If you pre-plan appropriately and know exactlywhat kind of motions you want, theend cost will reflect your degree oforganization.

Another key to making a mo-cap ses-sion successful is to involve the anima-tor who will be using the data. Sure,those clipboard-carrying, coffee-cup-toting producer types have their usesand can baby-sit the fiscally irresponsi-ble artist if they like, but at least one ofthe artists who will be working withthe fruit of the session needs to be pre-sent during the shoot.

Can’t We All Just Get Along?

Not too long ago, I read a couplenegative commentaries on

motion capture in a telephone-book-sized tome dedicated solely to charac-ter animation. This was the first time I

ever heard mo-cap referred toas “Satan’s Rotoscope.” What aload of crap.

I hear statements like thisand I think of that e-word —ego. Teams of people areresponsible for games today,not individuals. Not to explorethe possibilities and benefits ofa new technology because youwant the pleasure of proclaim-ing you did it all from scratch ispart of the inanity that resultsin very late products beingshipped. Sure, given all thetime in the world, any anima-tor worth his salt can createconvincing and supremely real-istic character animation. Well,we all know how much time wehave to do our animations,don’t we?

But, what the hey. Let’s just say for asecond that mo-cap is evil. The bane ofthe real artiste. If that’s the case, thenwhy not just toss that computer alto-gether and go back to traditional celart animation and just scan the art in?Oh, but that would mean you’d haveto use a scanner. Since that evil con-traption digitally captures images thatcould be used in game art, such as tex-ture maps, we should probably get ridof that bit of demonic technology aswell. While you’re at it, what aboutdigital cameras, model digitizers,heck...even photographic reference ofany sort? Maybe all example of mod-ern techniques or technologies thatassist the artist in his ability to meethis deadlines with work that (gasp) issometimes better than he could haveachieved on his own should be con-signed as products of the nether realm.

The purists would secretly be not toounhappy about this because then theycould weed out the real artists fromthose pretentious wannabe keyboardjocks. Then they could beat their chestsin pride and reaffirm their prodigioustraining and stature.

Technophobia has no place intoday’s world of computer game devel-opment. Motion capture is here to stayand will antiquate keyframing about asquickly as electronic documents haveturned our work environment into a“paperless” office. In the right hands,mo-cap is the perfect way to aid andenhance the keyframe animator, notreplace him. ■



24

Steed knows the importance of wearing many hats dur-

ing the motion-capture process, including this one cov-

ered with reflector balls at Texas’s Locomotion Studios.

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

Even Nintendo’s Game Boy has shownphenomenal growth in 1999 and isattracting new titles and developers tothe color version, while the next-generation, 32-bit Game Boy “Advance”is slated for release late next year. Allthese comparisons of platform tech-nologies aside, the biggest obstacle tosuccess in the PC gaming market is thestructure of the PC business, which isbuilt around the sales of PC hardware tobusinesses and education outlets.Games may be ubiquitous, but the PCindustry still sees the game industry as amarginal interest, and sometimes solelyas a means to sell the latest CPU.Examining the market of console gameusers and the channels for console prod-ucts is a sobering lesson in how far thePC industry has to go to become con-sumer-savvy.

The PC game business has alwaysbeen hampered by a lack of shelf spaceand sufficient sales outlets. This situa-tion is unlikely to be resolved while themarket remains driven by the upgradecycles of Microsoft and Intel. In themeantime, the console gaming marketis benefiting from penetration intoboth traditional retailing channels andexisting PC sales channels.

Channels Young and Old

W hile online sales of PC productsis considered to be a hot area of

growth, the vast majority of sales stillcome from third-party retailers and dis-tributors who rely on their expertisewith applications to serve a desiredmarket. It’s rare to find a reseller or sys-tem integrator that is focused ongames. In contrast, console products arepredominantly retail-based and requireno third-party support or intervention.For PCs, there are more than 100,000

companies in the U.S. alone that act asmiddlemen for computer manufactur-ers, and who supply systems, upgradesand services to users. In such a large,competitive market, specializing inhardware sales to game players wouldmake little sense, and trying to competein the arena of PC gaming software isunlikely to enliven any reseller’s bot-tom line.

By contrast, a fully configured net-work of systems for a small business orcorporate customer has potential forlucrative service and support contracts,or may be solely beneficial in selling areseller’s software expertise. So, whilethe $125 billion in sales that the PCchannels produce is an impressivenumber, it’s spread across a vast mix ofdealers and resellers. These consist ofvalue-added resellers (VARs), retailers,distributors, systems integrators (SIs),mom-and-pop stores, and everythingfrom a single-person consultancy to bigservice companies such as EDS. Stackedup against these hardware-driven dis-tribution channels is a console businessdriven by cute game characters andmass-market promotions.

Simply put, PC channels are relative-ly young compared to the retail chan-nels that console games have penetrat-ed. PC channels are as old as the PC,while retail channels date back tobefore the electronic age. This pointsout the gaping chasm of consumersavvy between traditional PC saleschannels, and the retailers that thriveon N64, PSX, and Game Boy products.Furthermore, the next generation ofconsole products promises to constrictthe PC gaming market by providing

powerful platforms with multimediaand online capabilities. Next-genera-tion consoles may not be PCs, but theydon’t aim to sit on someone’s officeLAN, either.

The Console Player’s Choice

A t the third annual ElectronicGaming Summit this past August,

Ziff-Davis announced the results of theVideo Gaming in America researchreport. This report found that purchaseimpact is influenced more by brandpower of a character or game than bythe knowledge of the publisher ordeveloper. Surprisingly, the buyinghabits of game players, according to thereport’s findings shown in Chart 1,point out their preference for discountstores where impulse buying and pric-ing play a key role. Console games seemto have better branding and get intothe places where the most buyingoccurs. This is despite the fact that atplaces like Wal-Mart, PC games have tobe priced below $20 to qualify for sig-nificant sales. If that weren’t badenough, the reputation of consoles ashigh-technology products, which isreflected in the sales of console gamesthrough computer superstores.

The other advantage that the consolemarket has is rentals. “Core” game play-ers (defined in the report as those con-sumers who purchase two or moregames per month) are averaging morethan three rentals per month, while“casual” players (defined as those whopurchase fewer than two games permonth and play fewer than four times


27

A Tale of Two Channels

P C gaming appears to be the technological peak of game development.

However, the advent of Sega’s Dreamcast, Sony’s marketing of Playstation

2 technology, and the intriguing prospects of Nintendo’s Dolphin system

have helped to promote greater anticipation for the console.

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

per week) average about 1.4rentals per month. The realkicker is purchase rates afterrental are 84 percent and 65percent respectively for coreand casual players. Videorental outlets can devote any-where from 10 to 20 percentof their shelf space to games,but generate in excess ofthose figures in percentage ofrevenues from rentals. Thereis really no mechanism inplace, or likely to be put inplace, to create the samerental opportunity for PCs.The PC always has the benefitof the limited demo softwarepackage bundled with gamemagazines and available fordownload, but these optionspale in comparison to beingable to take a game home toplay in full for three days.

Another interesting find-ing in the report is the influences onplayers’ purchasing choices across coreplayers, casual players, and “average”players (defined as consumers who pur-chase fewer than two games per monthbut play four or more times per week),shown in Chart 2. Friends, television,and in-store game demos played a keyrole here. In-store demos of PC gamesare unlikely to happen anytime soon,unless you have a publisher with a very

significant marketing budget to spend,or PCs end up costing $100, and youcan load 10 games within 60 seconds.

The PC Branding Problem

PC games, with some exceptions,tend to be more sophisticated sim-

ulations and immersive environments.As a result, PC games lack some of the

“cute” character brands of consolegames. At a more specialist level, the PChas programmers like John Carmackand designers like Sid Meier, but theconsole industry has Shigeru Miyamotoand David Perry.

To reconcile these two worlds, PCgame channels have to get closer tothe console market in terms of mar-keting sophistication and audienceappeal. PC gaming will not ultimately

die, but it will become cor-nered, and that will affectthe flow of new talent intothe industry. That in turnwould affect innovations intechnology and titles. Itlooks like the console mar-ket has finally grown up,and now it’s time for the PCmarket to do the same. Butit won’t happen until thegaming industry figures outhow to break the infrastruc-ture of PC sales channels.

Recently, the Good Guyschain of electronics storesannounced it was ceasing PCsales, CompUSA said it wouldclose some of its stores, andOfficeMax has felt the drainof lower PC prices and prof-its. Meanwhile, displays ofconsole games and hardwarein CompUSA stores continueto grow. ■

H A R D T A R G E T S


28

0%

20%

40%

60%

80%

Frie

nd

s

TV

In-S

tore

G

am

e D

em

os

Vid

eo

ga

me

M

ag

azi

ne

s

In-S

tore

Dis

pla

ys

G

en

era

l

M

ag

azi

ne

s

Ga

me

Pa

cka

gin

g

Sto

re

Sa

les

pe

op

le’s

A

dv

ice

Inte

rne

t

Pu

bli

sh

er

/R

eta

il

Sa

mp

le D

isk

s

Ne

ws

pa

pe

r

Ra

dio

Ou

tdo

or

Bil

lbo

ard

s

"Core"

Players

"Average"

Players

"Casual"

Players

C H A R T 2 . Consumers’ sources for videogame purchasing information (source: Ziff-Davis).

Dis

cou

nt

Sto

res

Toy

Sto

res

Ele

ctro

nic

s

Sto

res

Vid

eo

S

tore

s

Co

mp

ute

r

Sto

res

De

pa

rtm

en

t

Sto

res

Wa

reh

ou

se

Sto

res

Sp

eci

alt

y

Sto

res

Inte

rne

t

Ma

il O

rde

r

Bo

ok

sto

res

Oth

er

1998 1999

0%

20%

40%

60%

80%

100%

N/A

C H A R T 1 . Game players are shopping across all outlets (source: Ziff-Davis).

ame console programming is largely a secret

art. The technology and APIs are kept hidden

by nondisclosure agreements, and you won’t

find development kits for game consoles at

your local software store. As a result, pro-

gramming for game consoles is something

you just don’t hear much about.

While specific techniques for program-

ming Nintendo’s current game console are well-known within that particular devel-

oper community, they are virtually unknown among PC developers, or developers

looking to do cross-platform titles. This article will give you some insight into the

inner workings of the Nintendo 64 (N64). Much of what I’ll discuss in this article

hasn’t even been released to authorized N64 developers. Nintendo has chosen to


30

P R O G R A M M I N GN 6 4

Mark A. DeLoura ([email protected]) is the software engineering lead for the Product Support Group at Nintendo. He’sbeen working on the Nintendo 64 since the first hardware dev kits showed up, and he damn near cried the first time he booted upSUPER MARIO 64. Now he’s working on high-tech wizardry for Nintendo’s next-generation console, Dolphin.

Putting Curved Surfaces toWork on the Nintendo 64

b y M a r k A . D e L o u r a

pull back the covers to helpdevelopers squeeze the lastounce of performance out of themachine. We hope that this arti-cle will help N64 developers dojust that, and encourage otherdevelopers to explore N64 pro-gramming.

After a quick discussion of theN64 architecture, we’ll digdown deep and design somecustom Reality Signal Processor(RSP) microcode, which tessel-lates a Bézier surface as shownin Figure 1. The RSP is a verypowerful custom chip in theN64, and until now the detailsof programming this chip havebeen kept secret. In a sense, weat Nintendo have decided to letthe cat out of the bag. You’ll geta feel for the incredible power of thischip and see why N64 is capable ofgreat 3D graphics with features thatstill aren’t available in consumer 3Dcards.

Nintendo 64 Architecture

The Nintendo 64 is designed aroundtwo main processing components

(Figure 2). These two elements are aMIPS R4300i CPU, and the Reality Co-Processor (RCP), which is a custom chip.The simplicity of this architecturemakes N64 programming very straight-forward. In addition to these processors,the N64 contains 4MB of RambusDRAM (RDRAM), four controller ports,and a cartridge port. The memory isexpandable and a 4MB Expansion Pak iscurrently available.

The N64’s custom RCP runs at62.5MHz. It is pri-marily composedof two parts: theReality SignalProcessor (RSP)and the RealityDisplay Processor(RDP). The RSPprocesses displaylists which are sentfrom the CPU. Itperforms allmatrix and vertexcomputations andoutputs trianglecommands to theRDP. The RDP

takes this information, loads the tex-ture cache from RDRAM, and rendersfully MIP-mapped, anti-aliased, Z-buffered triangles to the frame buffer.This design leaves the CPU free to per-form physics calculations, advancedartificial intelligence, sound process-ing, and other game functions.

RSP Architecture

The RSP is modeled on a general-purpose 32-bit RISC processor. It

includes 4KB of memory for code(IMEM) and 4KB of memory for data(DMEM). Programs which execute onthe RSP are known as microcode.Nintendo provides a standard suite ofmicrocode to all N64 developers,including 3D transformation and light-ing code, line-drawing code, sprite rou-tines, and audio processing. Due to

special features of the RSP, it isvery well-suited for computa-tionally heavy tasks such as 3Dgraphics calculation and audiomixing.

In addition to 32 32-bitscalar registers, the RSPincludes 32 128-bit vector reg-isters. These vector registerscan be addressed in a variety ofways, but they are ideally usedas eight shorts (also called vec-tor slices). Each slice has a 48-bit accumulator associatedwith it that can be used tostore intermediate results.Using the vector registers andaccumulators, a vector opera-tion can be performed whichmultiplies two vectors andadds the result to the current

accumulators, giving 16 calculations inone cycle.

The RSP can actually execute a vectoroperation and a scalar operation eachcycle. This means that it’s possible todo 17 calculations per cycle. With care-fully tuned microcode, it is possible toreach a maximum of just over one bil-lion operations per second.

The Microcode

This high-speed programmablearchitecture was very forward-

thinking at the time the Nintendo 64was designed. It has enabled Nintendoto provide a set of standard microcodelibraries which make 3D programmingeasier for the novice. At the same time,elite programmers are able to code upspecial routines which are optimizedfor their own games or enable unique

functionality.During the life spanof the N64, the 3Dperformance hasnearly doubled as aresult of microcodeoptimizations.

MicrocodeExecution

F irst let’s talk alittle about the

structure of microc-ode and how to useit. Microcode is exe-


32

N 6 4 P R O G R A M M I N G

F I G U R E 1 . This Bézier surface has been tessellated by

the microcode we develop in this article, and rendered

by a Nintendo 64.

F I G U R E 3 . An example command

from the standard N64 3D graphics

microcode. This command turns on

texture mapping using a specific tex-

ture tile.

F I G U R E 2 . The Nintendo 64 architec-

ture is simple and elegant.

cuted through the use of an RSPtask. Tasks are command lists(graphics display lists or audiocommands) which indicate aseries of operations for themicrocode to perform. They areexecuted in parallel with theCPU. In order to start an RSPtask, you create the commandlist and pass it to the RSP alongwith pointers to the microcodeand various buffers that themicrocode needs. Then you calla simple function to start RSPexecution and control is imme-diately returned to the main pro-gram while the RSP begins pro-cessing commands.

The RSP can communicatewith the RDP or CPU duringexecution if necessary. Forexample, most versions of the 3Dmicrocode communicate with theRDP, feeding it triangles and otherdata to render to the frame buffer.Other versions of microcode commu-nicate with the CPU when data isready. For example, the Z-Sort microc-ode can be set up to alert the CPUafter a number of objects have beenprocessed so that the CPU can workon these objects in parallel. When theRSP completes the task, it signals theCPU so that the user program cansend the next RSP task or use thisinformation for synchronization.

The Command Loop

T he microcode command loopsequentially goes through com-

mands which have been DMA’d intoDMEM from the command list. Simi-lar to assembly language instructions,the commands have bitfields whichindicate the RSP function desired. Inthe microcode command loop, theopcode and subopcode bitfields aremasked off and used as an offset intothe function jump tables (also storedin DMEM) to determine the IMEMfunction location.

In the standard graphics microco-des, each command is a 64-bit double-word. The opcode and subopcode arecontained in the upper bits, and lowerbits are reserved for data being passedas function parameters as shown inthe example in Figure 3. The data bit-fields are masked off in the main loop

and stored in separate registers beforejumping to the function requested.

The DMA Engine

The RSP includes a set of registerswhich control the DMA engine.

Since there may be multiple requestsfor DMA pending, the microcode mustcheck the DMA Busy register beforesubmitting its request. If a request isbeing processed and there is alreadyanother request pending, the micro-code must waitbefore sub-mitting arequest. Arequest ismade byaltering theDMA Source,DMA Destination,and DMA Lengthregisters. Once thelength is written to theDMA Length register, theDMA engine queues therequest and begins thetransfer if no requestsare pending. Thetransfer executes inparallel with theRSP so controlis immedi-atelyreturnedto themicro-code.

Using Curved Surfaces

W ith this basic under-standing of the N64’s

workings behind us, let’s moveon to the main focus of thisarticle, using curved surfaces.Curved surfaces are not sup-ported in the standard N64microcodes. But if you want torender curved surfaces, it makesa lot of sense to do the heavycomputations required on thevector processor. Now, we’renot actually going to rendercurved surfaces. We’ll take acurved surface representationand tessellate the surface intopolygons which the N64 thenrenders.

For our purposes here, we aregoing to use Bézier surfaces. A Béziersurface is a curved bicubic surface, sim-ilar to Hermite surfaces, B-spline sur-faces, and NURBS. The Bézier is mathe-matically complex enough for us to beable to create interesting surfaces,while not being so difficult to computethat we’re only going to be able to do acouple per frame. If you need to brushup on curved surface technology,check out the list of references at theend of this article.

There are a number of algorithmswe could use to tessellate a Bézier sur-

face. First, let’s quickly look at thestandard equation and

the algorithmwe’ll use in

the micro-code.

Ifyou’re

inter-ested in

the back-ground of

Bézier surfacealgorithms and

want to learn more about why I’vechosen this one, please see the

expanded version of this article (with Bézier surface derivation) onGamasutra.com.


34


F I G U R E 4 . Bézier surfaces are defined in a biparamet-

ric space. Sixteen control points are used to define the

surface completely.

Bézier Surface Equation

A Bézier surface is a parametric sur-face (u,v = [0,1], [0,1]) defined by

its 16 control points pij which form a4×4 grid, as shown in Figure 4. Thecommon form for representing thissurface is:

The functions Bi(u) and Bj(v) are theBernstein polynomials which are alsoused for Bézier curves.

The edges of a Bézier surface are eachBézier curves. Since only the end con-trol points of Bézier curves lie on thecurve, we can extrapolate that the cor-ner points of the surface are the onlycontrol points which lie on the surface.All twelve of the other control pointsinfluence the shape of the surface, butare not on the surface itself. For thisarticle, we’ll create a microcode thattessellates a Bézier surface into an8×8 grid of quadrilaterals.

Tessellation by Evaluation

The most direct way to slice aBézier surface into polygons

is by calculating the above Q(u,v)double summation on a regulargrid. Performing this in a veryoptimized way, each surfacevertex we calculate requires 54additions and 108 multiplies.That’s a lot of work to dowhen we’re planning to createa 9×9 grid of vertices.

Central Differencing

The way we’re going to generatepoints on the Bézier surface in

this article is through the use of centraldifferencing. Central differencing givesus an easy way to find the midpoint ofa Bézier curve without having to keeptrack of control points for each sub-curve. We can split the edge curves attheir midpoints, and then split the sur-face across these midpoints to createfour subsurfaces. This process can berepeated recursively to create an arbi-trarily fine mesh. (For details on thisalgorithm please see the previously-mentioned article on Gamasutra.com,or Brian Sharp’s series of articles on

curved surfaces, June–July 1999.)The central differencing algorithm

has a hefty initialization cost due tothe computation of second partialderivatives (Quu, Qvv, Quuvv) at eachcorner control point. But every curvesubdivision after that will only cost us18 additions and 18 multiplies. Thememory footprint is 24 bytes per subdi-vision, and there are 77 subdivisionsnecessary to create our mesh. This willfit in our 4KB DMEM nicely.

Writing the Tessellation Microcode

Now that we’ve chosen the algo-rithm to tessellate the surface,

let’s get back to work on the microcodeitself. The first things

we need to fig-ure out are the

commandswe needand thecom-mandstruc-ture.We’re

going touse a

64-bitdouble

word for ourcommand size.That will give usplenty of

room to store the data for each com-mand inside the instruction. The com-mands and parameters necessary forour tessellation microcode are:

1. Set RSP segment (segment number,physical address).

2. Load control points (segmentaddress).

3. Perform tessellation.

4. Save surface vertices (segmentaddress).

5. End display list.I’ll describe these commands further ina moment.

Since we only have five commands,we can just use a 3-bit field for theopcode. Fortunately, the standardgraphics microcodes all use a 3-bitopcode field and 6-bit subopcode field,so we’ll use that. But we’ll just wedge allour instructions into the subopcodes forone primary opcode. Then we can reusea lot of the main command loop rou-tines from the standard microcodes,including the display list DMA routinethat loads commands into the DMEMbuffer for us. The low bit of the opcodefield and subopcode field are not used.Since microcode function addressesstored in DMEM take up two bytes(address range 0–4095), our jump tableshould be indexed on even bytes only.Not using these low bits ensures that wehave an even index without performinga shift or multiply for every command.

The parameters for our commands arepretty straight-forward. The most com-plicated command sets a segment regis-ter for address computations. It requiresa segment number and physical address.We’re using a 16-address segment tablein the RSP, so it’ll take four bits to holdthe segment number. The addresses are32 bits, so we’ll use the second half ofthe 64-bit double word for the address.Then we’ll use the upper nine bits for

the opcode and sub-opcode fields

and followit with

four bitsfor the

segmentaddress.

You can seeour command

structure in Figure 5.

Getting Data In and Out

B efore we code up the tessellationalgorithm, let’s figure out how to

get data in and out of DMEM. The “setRSP segment” command fills an entryof our 16-entry segment/offset table,which is stored in DMEM. This tablemakes some programming tasks easier,such as swapping the frame buffer eachframe. The segment table stores 24-bit

Q u v p B u B vij i jji

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

0

3

0

3


36


offsets which are added to any addresssent to the RSP. The segment tableindex is stored in bits 24–27 of theaddresses passed in. The low 24 bits ofthe segment address are added to the24 bits stored in the segment table.Since our physical address range is0–0x007fffff (8MB), 24 bits is enough.

Prior to tessellation we need to loadthe control points into DMEM. Our“load control points” command simplytakes an address as a parameter. Theaddress is passed to the segmentaddress translation routine, which usesthe segment table to convert theaddress to a physical address. The DMAengine is called to bring the 16 controlpoints into DMEM from this physicaladdress.

After tessellation, we need to savethe surface vertices we’ve computed,using the “save surface vertices” com-mand. We’ll pass in an address and thesegment address translation routinewill convert it to a physical address.That physical address is used to pro-gram the DMA engine to copy our 81surface vertices to RDRAM.

The “end display list” command sim-ply flags the RSP to quit. It executes abreak, which signals the CPU, andalerts our main program.

Data Formats

T he first thing our “perform tessella-tion” command does is perform a

simple translation from control pointformat to surface vertex format. So let’stalk about these formats.

The Nintendo 64’s standard vertexformat uses 16-bit coordinate ranges,which are s15 quantities (one sign bitand 15 integer bits). This gives vertex

coordinates an effective rangeof +/– 32KB. It makes sense forus to use this same format forcontrol points, but since we’rejust tessellating, we really onlyneed the point position. Ratherthan wasting the extra spacefor colors and texture coordi-nates when we DMA the con-trol points into DMEM, our for-mat will only represent the x, y,and z position as signed shorts.

The surface vertex format ismore complicated. The centraldifference algorithm describesfour sets of values that each ver-

tex needs to track. These are:1. Q(u,v): Position2. Quu(u,v): Second partial derivative

in u at this vertex.3. Qvv(u,v): Second partial derivative

in v at this vertex.4. Quuvv(u,v): Second partial derivative

in u of the second partial deriva-tive in v at this vertex.

All of these values are vectors of x, y,and z. Since the vector slice size of theRSP is 16 bits, and the control pointcoordinates are 16 bits, we’re going tostick with 16 bits for these coordinate

values as well. We’ll have to tweak ourmath to minimize overflow and under-flow, but it will pay off in performance.

One final note on formats. Each vec-tor register contains eight vector slices.But each of our points contains threevalues (x, y, and z). We’re really justgoing to make things confusing if we tryto stuff two of three coordinates fromone vertex into a vector register, alongwith two other vertices. So let’s insert ajunk (we’ll call it j) field at the end ofeach of these vertices. This will also giveus much better alignment in DMEM.

Now that we have our formatsdefined as in Listing 1, it’s a simple taskto convert from one to the other. Actu-ally, all we need to do is copy the 64bits from each corner control point (x,y, z, and j) into the beginning of eachcorner surface vertex.

Corner Initialization

Now we need to compute the sec-ond partial derivatives described

above for each corner of the surface.Fortunately, the second partial in uand the second partial in v at each


38


F I G U R E 5 . Our command structure is similar to

the structure of standard N64 microcode com-

mands. We use this structure for all of our com-

mands.

struct ControlPoint {

s15 x, y, z, j;

};

struct SurfaceVertex {

s15 qx, qy, qz, qj;

s15 quux, quuy, quuz, quuj;

s15 qvvx, qvvy, qvvz, qvvj;

s15 quuvvx, quuvvy, quuvvz, quuvvj;

};

L I S T I N G 1 . Formats for data storage in DMEM. The j fields are unused, we

include them for data alignment.

# Load the vector registers with point data

vload vectora, P[0,0], P[0,0] # = x y z j, x y z j

vload vectorb, P[1,0], P[0,1]

vload vectorc, P[2,0], P[0,2]

# Do vector computations to simultaneously compute quu and qvv.

vadd vectord, vectora, vectorc # D = A+C

vmul vectore, vectorb, vconst[5] # E = B*(-2)

vadd vinter, vectord, vectore # inter = A-2B+C

vmul v00, vinter, vconst[3] # v00 = 6*(A-2B+C)

vstore2 v00, v00uu, v00vv # Store results to uu and vv fields

L I S T I N G 2 . Pseudocode for computing Quu(0,0) and Qvv(0,0) using vector

processing.

corner control point can be computed with similar equa-tions that use different points. Here are the equations toperform at control point (0, 0):

We need to do this computation in x, y, and z for eachequation. This is a great place to take advantage of vectorprocessing. We’ll do this operation in parallel, computingboth equations for x, y, and z simultaneously. First, we loadboth sets of control point positions into the vectors, asshown in pseudocode in Listing 2. Then just a few vectorcomputations are performed and all coordinates are simul-taneously calculated.

Note that we have the constants –2 and 6 stored in a vec-tor constants (vconst) register, which makes it easy to multi-ply each slice in another vector by eachscalar. Using vector processing we’vereduced two additions and twomultiplies for each of six coordi-nates to just two additions andtwo multiplies total.

We can perform this sameprocess to compute Quuvv.But we’ll have to pair upthe operations. We havefour control points, thecorner points, which weneed in order to calcu-late Quuvv. We can com-pute two separate con-trol pointssimultaneously by jam-ming them into the same vector and doingvector operations. So we’ll perform thisprocess twice in order to compute Quuvv forall four points.

Surface Subdivision

For code simplicity, we’re going to subdividethe surface iteratively, not recursively. We’re going to

subdivide many times, so let’s make a function out of it.What do we need to pass to this function? Well, we’ll needthe data for the endpoints of the curve we’re splitting, and adu value which is the distance in parametric space from themidpoint to the endpoint. This is 0.5 for our first subdivi-sion. For simplicity, we’ll pass in the value (du)2/2 so wedon’t have to compute the square and multiply by one-halfeach time we use the function. We’ll also stuff this value in avector slice so that we can use it in vector computations.We’ll call the vector which contains this value vecdusqhalf.Our function ends up looking like this (there will be one foru-curve splits, and one for v-curves):void tesselSubdivide[U|V](Vertex v0, Vertex v1, Vector vecdusqhalf)

The microcode for the tesselSubdivideU function appears inListing 3. The function tesselSubdivideV will be very similar.

The first thing you’ll notice in this code is that we blocktogether the Quu and Quuvv computations. We also block

together the Q and Qvv computations. That’s because both ofthese are very similar computations. For Quu and Quuvv we’redoing this:

The computations for Q and Qvv depend on the prior com-putations, so we do them second. They look like this:

Most of the opcodes you see in the microcodelisting make intuitive sense. But one that

bears explaining is vmudm. The RSP pro-vides many multiplication opera-

tions. They vary depending on thesign of the operands and whether

the operands are fractions orintegers. The vmudm opera-

tion performs multiplica-tion of signed integersby unsigned fractions.The resulting integerpart of each vector slicecomputation is stored in

the destination vector reg-ister (first operand), and

the 32-bit integer/fractionresults are stored in the

accumulator slices.This microcode currently is

not optimized for dual process-ing, nor for accumulator storage

of intermediate results. Vectorloads and stores are scalar opera-

tions, so we could easily tighten thismicrocode up by executing loads and stores in parallel withvector operations.

Performance Figures

C alculating a regular grid of points on the Bézier surfaceusing the standard double sum equation is a not a very

efficient way to tessellate. Using floating-point arithmetic onthe CPU, this process took 272,500 CPU cycles. While cen-tral differencing has a large performance cost at initializa-tion, the subdivision step is very fast. Implemented on theCPU, it takes 70,400 CPU cycles to tessellate our surface.

When we moved this algorithm to the RSP, we made somesacrifices. We used 16-bit fixed-point arithmetic and took ahit for DMA-ing data to and from the RSP. But our algo-rithm, including RSP load and save time, runs in just 16,600CPU cycles. And the CPU itself is free during this process todo other computations.

Q uQ u Q u

dusqhalf Q u

Q uQ u Q u

dusqhalf Q u

mid uu mid

vv midvv vv

uuvv mid

( ) = ( ) + ( ) − ∗ ( )( )( ) = ( ) + ( ) − ∗ ( )( )

0 1

0 1

2

2

Q uQ u Q u

Q uQ u Q u

uu miduu uu

uuvv miduuvv uuvv

( ) = ( ) + ( )

( ) = ( ) + ( )

0 1

0 1

2

2

Q P P P

Q P P P

uu

vv

0 0 6 2

0 0 6 2

00 10 20

00 01 02

,

,

( ) = − +( )( ) = − +( )


40


N64 Optimizations Keep the Platform Fresh

W e’ve examined how Bézier sur-faces can be implemented on

the N64 using a central difference tes-sellation algorithm in microcode. Thepayback we got for choosing a moreefficient surface tessellation algorithmand pushing it onto the RSP was sub-stantial.

Technically, the N64 is still a power-house. Programming the microcodeand taking advantage of vector pro-cessing gives developers the ability toimplement algorithms that aren’t fea-sible on much bigger and faster CPUs.In addition, learning to program theN64 now will give developers a bigadvantage when it comes to next-gen-eration console development (includ-ing Nintendo’s upcoming system, cur-rently known as Dolphin), many ofwhich use vector processing. If you’reinterested in becoming an N64 devel-oper, or if you are an N64 developerand you want to know about microc-ode development kits, please contactNintendo by sending e-mail to [email protected]. ■


41

#########################################################

# tesselSubdivideU

#

# Subdivide this curve in the U direction

#

# Surface Vertex structure offsets

.symbol VERTEX_POS, 0

.symbol VERTEX_UU, 8

.symbol VERTEX_VV, 16

.symbol VERTEX_UUVV, 24

# Register aliases

.name pnew, $10 # Position of output surface vertex (u)

.name pminus, $11 # Position of input left surface vertex (u-du)

.name pplus, $12 # Position of input right surface vertex (u+du)

.name vecdusqhalf, $v6 # Vector which contains 0.5*du*du in slice 0

.name vecminus, $v7 # Vector for storing left surface vertex info

.name vecplus, $v8 # Vector for storing right surface vertex info

.name vecuus, $v9 # Temp vector for UU and UUVV computation

.name vecuushalf, $v10 # Final results of UU and UUVV computation

.name vecposvvsinter, $v11 # Temp vector for POS and VV computation

.name vecposvvshalf, $v12 # Temp vector for POS and VV computation

.name vecmulleduus, $v13 # Temp vector for POS and VV computation

.name vecposvvs, $v14 # Final results of POS and VV computation

.ent tesselSubdivideU

tesselSubdivideU:

# Do quu and quuvv computations together

ldv vecminus[0], VERTEX_UU(pminus)

ldv vecminus[8], VERTEX_UUVV(pminus)

ldv vecplus[0], VERTEX_UU(pplus)

ldv vecplus[8], VERTEX_UUVV(pplus)

vadd vecuus, vecminus, vecplus # Add endpoints

vmudm vecuushalf, vecuus, vecconst[1] # Mul by one-half

# Do qpos and qvv computations together

ldv vecminus[0], VERTEX_POS(pminus)

ldv vecminus[8], VERTEX_VV(pminus)

ldv vecplus[0], VERTEX_POS(pplus)

ldv vecplus[8], VERTEX_VV(pplus)

vadd vecposvvsinter, vecminus, vecplus # Add endpoints

vmudm vecposvvshalf, vecposvvsinter, vecconst[1] # Mul by one-half

vmudm vecmulleduus, vecuushalf, vecdusqhalf[0] # uus/2 *(du^2)/2

vsub vecposvvs, vecposvvshalf, vecmulleduus # Subtract...

# Store everything

sdv vecuushalf[0], VERTEX_UU(pnew)

sdv vecuushalf[8], VERTEX_UUVV(pnew)

sdv vecposvvs[0], VERTEX_POS(pnew)

jr return

sdv vecposvvs[8], VERTEX_VV(pnew)

.end tesselSubdivideU

L I S T I N G 3 . Microcode for the tesselSubdivideU routine.

BooksWatt, Alan, and Watt, Mark. Advanced

Animation and Rendering Techniques:

Theory and Practice. New York: ACM

Press, 1992.

PeriodicalsClark, J. H. “A Fast Scan-Line Algorithm

for Rendering Parametric Surfaces.”

Computer Graphics Vol. 13 No. 2: pp.

289–299.

Game DeveloperSharp, Brian. “Implementing Curved

Surface Geometry” (June 1999) and

“Optimizing Curved Surface Geometry”

(July 1999).

GamasutraFor a detailed derivation and compari-

son of Bézier surface algorithms, see

the expanded version of this article at

http://www.gamasutra.com.

Bézier Surface Microcode SourceIf you're a Nintendo 64 developer, log

on to Nintendo’s developer web site at

https://www.warioworld.com.

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

But resource management is muchmore than just dealing with size con-straints. You also have to properly allo-cate and free resources, which, ifignored, can quickly turn into hidingplaces for numerous bugs. Fortunately,there are ways to deal with these prob-lems. It just requires planning andimplementing some helpful tools.

First, let’s see what we’re getting our-selves into when we start talking aboutdeveloping for a console. For this article,my focus is on the main memory, sowe’ll ignore video and sound memory.

The current champ of the consolewars is the Sony Playstation, which

means that if you’re thinking aboutdeveloping for consoles, you’re proba-bly considering this system. ThePlaystation’s massive consumer marketis the good news, but the bad news isthat its market is the only big thingabout it — the system itself is very lim-ited when it comes to resources. ThePlaystation is a small system with only2MB of primary memory. TheNintendo 64 isn’t much better at 4MB.The newest kid on the block, the SegaDreamcast, comes to the table with amore impressive 16MB of memory butit will sometimes have Windows CEtaking a slice of that space. (Also, the

recently-released specifications for theSony Playstation 2 reveal that the sys-tem will have 32MB of main memory.But since it’s currently in development,that might change.) In other words,the PC has a huge leg up on consoles asfar as main memory goes and it doesn’tlook as if that will end anytime soon.

Keeping these restrictions in mindwhen developing a game is criticallyimportant, especially if you want to dosimultaneous PC/console development(or worse yet, if you decide partiallythrough your PC development to tryporting it to a console). Many of thenewest PC games require 24 or 32MB


42

M A N A G E M E N TR E S O U R C E

The Big Squeeze:Resource ManagementDuring Your Console Port

b y M i c h a e l S a l a d i n o

eveloping games for consoles often requires tight

resource management. Trying to fit all your

textures, sounds, and polygons onto the

machine is difficult enough, but then

consider that your monsters, explosions,

and bullets must live in this same place

along with your program code. It’s a tight fit.

Michael Saladino is currently the lead programmer on STAR TREK: HIDDEN EVIL at Presto Studios Inc. His previous work has found himat Volition Inc. during the development of DESCENT: FREESPACE and at Mobeus Designs Inc. Contact him at [email protected] orjust drop by his office for a late afternoon cocktail where he can be found exploring improved living through crushed velvet.

DD

of loaded resources, so trying to fitthat into a console is a daunting task.It’s comparable to trying to fit an ele-phant into a Volkswagen. And don’texpect consoles ever to catch up. PCsand consoles both use the same mem-ory components and therefore on-board memory sizes for each areincreasing at the same rate of approxi-mately four times every three years. Aslong as PCs cost many times morethan consoles, they will always havemore memory.

So, you have a game that barely fitsonto a PC, and then the producer startstalking about porting to a console.What do you do? Well, it’s an old storyin game development: A group of pro-grammers just start building a gameand before they know it, they’re at80MB of resources with no idea howthey got there. Then they end upspending many man-months trying toshrink the game to fit on a consumerPC. At that stage, the idea to port thegame to a console has to remain exact-ly that — an idea. You could never getit on a Playstation at that stage.

It’s all too easy to allow this scenarioto occur because most game program-mers use systems with at least 128MBof memory, and many games can gowell into their second half of develop-ment without anyone ever seriouslylooking at their memory footprint.Code, much like a gas, expands in vol-ume to fill its container. Therefore it’sup to the responsible programmer toset a clear goal for the size of the codebase, know where it’s going, and makesure that it stays on course. The basicideas about memory management thatI will explore are ones common to con-soles and PCs. It’s just more importantto consider them while producing on aconsole game because the environmentis so restrictive. Let’s begin by lookingat some useful coding techniques.

Memory Pools

Most data in a computer game con-sists of large numbers of com-

mon data types. Examples of this arethe monsters in your world, bullets fly-ing around them, polygons that makethem up, the execute buffers that ren-der them, and so on. You need tomaintain lists of these data structuresso they can be accessed quickly and

efficiently. A goodway to handle thisdata is with a mem-ory pool manager.A memory poolmanager is a pieceof code that han-dles large collec-tions of dynamical-ly created data of acommon type.With this layer ofcode, we can han-dle the allocation,de-allocation, andusage of these dataelements. We canalso keep track ofimportant statisticsabout the data suchas the greatestnumber of bullets that was ever in exis-tence at one time during an executionof the game. Knowing these statisticscan be very helpful in setting maxi-mums that help compress your game’sfootprint onto a given system. I dividemy memory pools into two separateversions. The first is responsible forhandling data types which cannothave a maximum number of elementsforced onto them. However, they mustshare the common trait that they arealways allocated and de-allocated intwo independent stages. The secondtype of memory pool handles datatypes that have a limited number inexistence at any given time, whichlends itself well to a temporal cachingsystem.

Cyclic Memory Pools

L et’s consider the first style of mem-ory pool. To give you a clear idea

of what type of data elements fall intothe above description of this pool, it’sany data list that is allocated elementby element until it reaches its maxi-mum growth for that cycle and is thencompletely destroyed so the processcan begin again. Many data types ingames actually fall into this category,and most involve frame-specific databecause the frame is a convenientcycle. Examples of this data typeinclude Direct3D execute buffers, poly-gons generated from 3D clipping,spans for scanline hidden surfaceremoval, and AI transversal lists; all of

which happen to be tied to the framecycle. You build the data fresh everyframe, and at the end of the frame youdispose of all that you created. Lookingthrough a game’s code base will mostlikely reveal many more algorithmsthat use this type of data.

One way to manage this data is to usea linked list that grows dynamicallyalong with the data. This is easy but notvery fast. First, you must call malloc (ornew) for every element you create. Forsome data types this could easily bethousands of times per frame. But sincethese data elements need to be trulydynamic, a pre-allocated array will notwork. Therefore, combining these twochoices into a hybrid is what is calledfor. This is the first type of memorypool.

This memory pool allocates largenumbers of elements with a single callto malloc. As new elements are needed,the memory pool system hands outpointers to memory blocks that havealready been allocated as part of a previ-ous chunk. If you run out, the memorypool will allocate another large block ofelements for the next n requests for newelements. This keeps the number of sys-tem-level allocations to a minimum.The trick is maintaining the balancebetween saving time by creating moreelements with each real allocation andlosing memory with allocated space thatgoes unused. Each type of data elementwill probably work best with its ownblock size, which is determined byexamining the data type’s usage duringan average game.


43

Hungry common data types. These monsters’ polygons are

part of a cyclic memory pool.

To reach this balance, you can cus-tomize the memory pool so that itgrows and shrinks intelligently. Forinstance, if the data type tends to allo-cate the same number of elementsevery cycle, then there is no need tode-allocate the space every frame —just empty it and use it again. Thisresults in even fewer system-levelmemory allocations. If the data typetends to spike up every few seconds,you can have the memory pool“prune” itself back to the average num-ber of elements per cycle, thereby usingfar less memory.

Caching Memory Pools

T he secondary form of memorypools manage data elements that

are dynamic and cannot be allocatedand de-allocated in two independentstages. Although this describes nearlyevery type of data list, there is oneother restriction that this pool placeson data types. The data must be able tohandle an arbitrary maximum of ele-ments to be enforced when a new ele-ment is requested. This memory pool isuseful for “eye candy” — data elementssuch as bullets, explosions, and particleeffects. Because console memoryresources are very limited, wastingspace on hundreds of bloody chunks isjust not good. Therefore, a memorypool that keeps usage under controlcan be very helpful. Basically, thismemory pool is a caching system. Butmany programmers only seem to usecaches in reference to textures, whenin fact they can be very usefulwith any number of data types.

Let’s look at an example ofwhat happens in my latest game,STAR TREK: HIDDEN EVIL. When anenemy drone is destroyed by aphaser blast, an explosion spriteis generated, a couple of smokepuffs are released, and a dozenspark particles are emitted. First,you don’t want to allocate anddelete every one of these ele-ments each time a drone isdestroyed. Take a quick look atsome hyperactive console gamesand you can see that hundredsof these eye-candy objects arecreated every second. A goodsolution to this problem is tocreate a set number of each type

of data element, say 100 debris parti-cles, 30 smoke puffs, and so on, andthen allow the memory pool to handout new elements whenever they areneeded without ever going over the setlimit. This means that no system-levelmemory management occurs, whichspeeds up our code. We also knowexactly how much memory each typeof data takes up throughout the game.

What happens when we run out ofelements of a given type? A simple age-based caching system can be used todestroy old instances in favor of newones. While this could conceivablydegrade image quality or even gameplay, it will usually go completelyunnoticed if you carefully balanceresource savings vs. game-play costs. Anold bullet that has been flying for threeseconds and still hasn’t hit anything(such as one flying towards the sky) isprobably not going to be missed if itdisappears unnaturally. Smoke puffsand debris particles are also not goingto be missed if they disappear a littletoo soon, especially since the player ismost likely focusing on the area wherenew particles are being generated.

Memory Pools Integration

T he integration of these pools intoour code base should be simple

enough since they are a very generalclass. For example, I wrote a cyclicmemory pool type recently for han-dling dirty scanline updating in STAR

TREK: HIDDEN EVIL. I had thousands ofdata elements, each of which repre-

sented a region on a scanline thatneeded to be refreshed. I created amemory pool of these data elements torequest from when I needed them.Since I had multiple dirty scanlinescreens working simultaneously, Iended up saving tens of thousands ofnew and delete calls on peak frames. Andby using very large chunks of a thou-sand data elements per pool, I hadexcellent cache locality coherencywhen walking the lists.

The integration of the caching mem-ory pool might not be quite as obvious.All data elements that belong to thesetypes of pools must derive from a com-mon class. This common class containsone item: the field on which to basethe caching algorithm. Earlier in thearticle, I implied that this cachingscheme had to be based on the age ofthe object, but it can really be based onanything. Any heuristic that deter-mines which element in the poolshould be expunged in favor of a newelement will do. Once you have alldata elements deriving from the baseclass, the rest of the integration is thesame as the other memory pool. Juststop allocating and deleting elementsand instead request them from theappropriate memory pool system.

Once most objects in our game arebased on the memory pool classes, wecan expand their usefulness by turningthem into statistic recorders to monitormemory use. Pools can keep track ofhow many of a given data elementhave been allocated, how many havebeen used, measure the peaks, anddetermine the averages. All this infor-

mation can be gathered easily bythe memory pool system andeasily retrieved to help reduceyour game’s memory footprint.This data is also very useful forcustomizing the actions of eachmemory pool used by yourgame. For instance, you mightfind that you are requesting sig-nificantly more bullets per sec-ond than you first guessed andit’s causing them to expire tooearly. Therefore, you raise yourallowance for bullets.

An example of the real-worldusefulness of these statistics canbe seen in our memory reductionwork on BENEATH. Our memoryfootprint was much too large atthe end of the project, so we sent


44

R E S O U R C E M A N A G E M E N T

Ensign Sovak is demonstrating caching memory pools

by destroying an enemy drone. Sparks are great can-

didates for caching pools.

one of our programmersinto the code to determinewhere we could cut. Bybreaking the memory usagedown to the object level, wesaw a tall spike at the dataobject “flare shards.” Flareshards are pieces that fly offwhen a flare objectexplodes in the game. (Aflare is shot from a flaregun, an object that manycreatures use.) We discov-ered that the spike wascaused by the fact that mul-tiple creatures had flareguns, each flare gun had apre-allocated clip of tenflares, and each flare had a pre-allocat-ed clip of twelve flare shards. The resultwas thousands of flare shards just sit-ting in memory waiting to be used.

Our solution was to create a flareshard pool in which we allocated a setnumber of flare shards at the beginningof the game. Then, whenever a newflare shard was needed, it requestedone from a memory pool. If the memo-ry pool was full, the oldest flare shardwas retired early and became the newflare shard. We ended up savingmegabytes of data space. Somethingthat small had actually gone unnoticedby us.

Memory Manager

A s any experienced programmercan attest, memory errors can be

some of the most difficult bugs to trackdown. And when you consider thatconsoles are often weak in terms ofdevelopment tools, having your owncode to help track down memory bugscan be quite a time saver. This is wherea memory manager can be useful (seeFigure 1). Normally, programs use thestandard malloc and free (or their C++equivalents, new and delete) when deal-ing with memory allocation; however,these functions do not help us trackdown memory leaks, prevent us fromoverwriting our memory bounds, orhandle other common memory errors.So, let’s look at a simple layer that wecan wrap around new and delete in orderto help us debug our code.

Let’s examine how this layer willwork. The meat of the code marks eachmemory allocation with a header and

trailer containing very specific datathat allows us to track the blocks. Inthe header we place a pointer to thesource code file-name string that theblock was allocated in and the linenumber it was allocated on. This lets usidentify memory errors by generatinguseful debugging messages that leadthe programmer straight to the prob-lem. We also include a marker in boththe header and trailer that allows us totrack its current state and watch forboundary overwrites.

When an allocation occurs, our cus-tom routine allocates memory using amalloc call with enough additional spaceto hold the header and trailer. The dataportion of the block is cleared out to anuninitialized value. The header andtrailer are initialized correctly with thefile name, line number, and overwritemarkers. This memory block is thenput into a hash table to give us bettersearching performance when we needto find blocks in later stages, such asvalidation or freeing. The memoryblock is then returned with the appro-priate adjustment for the header andthe rest of the program is none thewiser that this has taken place behindthe scenes.

Let’s look at what happens when wefree memory. First, check to see if thememory block has already been freedby looking at its header state. Alsocheck the header and trailer markers tosee if an unrecognized value has beenplaced there, implying that a boundaryoverwrite has occurred. This does notcatch all memory overwrites becauseobviously the overwrite could havewritten our marker, and it wouldappear untouched. However, in all my

years of using memory man-agers such as this, I’ve neverseen that happen. If thismemory block passes theseinitial tests, we make surethat the block is in our hashtable. If we find it, then wehave a legitimate free on alegitimate block. We free thedata block by marking it asfreed in its header state andthen filling the block with a“freed value.” The memoryblock is then removed fromour hash table and we finallycall free() to actually free theblock on a system level.

Using these two functions,we can catch many memory errorswhen they are first introduced and notweeks later when we’re trying to trackdown some very obscure, difficult-to-reproduce bug. We can also use thesefunctions to track our total memoryallocation, peak memory allocation,average memory allocation, and otheruseful code statistics.

Finding memory leaks is another bigadvantage to this code layer. At theend of your program, you can call theFindMemoryLeaks() function to find allmemory leaks. The code to handle thisis quite simple. By the time you callthis function, a free should have beencalled for every malloc you made; there-fore, any memory blocks that still existin the hash table are memory leaks.Just walk the table, printing out everyblock along with its file name and linenumber information. You now have aprinted list of every memory leak inyour game.

With this layer written, how do weintegrate this system into our codebase? We could overload new and delete,or we could replace all our standard Cmemory calls with our own personalfunctions if we didn’t want to use C++.The path I usually take is to usedefines, such as this:#ifdef _DEBUG

#define Allocate(x) \

MemoryManager->Allocate(__FILE__,__LINE__,x)

#define Deallocate(x) \

MemoryManager->Deallocate(x)

#else

#define Allocate(x) malloc(x)

#define Deallocate(x) free(x)

#endif

This method keeps you from havingto type the file and line parameters for


46


F I G U R E 1 . Our memory manager's block structure.

every allocate function call. Alsonotice that the entire memorymanager layer is skipped whennot in a debug build, therebyspeeding up the code base in thefinal release build. (And by thattime, all the memory bugs shouldbe gone, right?)

Resource Wrapping

The memory manager that wejust looked at should save

time when tracking down memo-ry bugs. But what is the code real-ly all about? It is just wrappercode; a custom high-level librarythat encloses a low-level library, suchas the C memory manager, which pro-vides improved functionality. By mak-ing sure that our wrapper is the onlyentry into the system, we can receivecustomized records that the low-levelsystem was never designed to give.

Let’s take this idea of the wrappereven further. There are many otherresources that we can surround withwrappers. Why not wrap the file IO sys-tem? Or write a custom library insteadof using fopen() and fclose()? This layercan be used to abstract packed files(many files merged into one for fasterdisk access) or keep endian switchingstraight between Macs, PCs, and con-soles. You can also use it to track downunclosed files that can cause quite a bitof trouble, as a recent incident at Prestoshowed us.

Windows gives each application amaximum number of file handles,which when used up, can no longer beopened using standard C file accessconventions. If you’re opening fileswithout closing them, you eventuallyuse up these file handles and run out. Arecent bug in our load/save system onSTAR TREK ended up being a section ofcode that was not closing its files, andafter five or six mission loads, wewould run out of handles. We wasted aconsiderable amount of time on a bugthat could have easily been avoidedwith a wrapper library reportingunclosed files. That’s what wrappingsystems are all about — adding morefunctionality to already-writtensystems.

Another benefit of writing wrappercode is that it helps us achieve ouroverall goal: porting between multiple

platforms. By maintaining a customapplication interface to a system, youavoid having to rewrite code through-out a project, and instead update onlyone library. For instance, if you had agame that used Windows-specific timerdevices, you would have to track downall instances of such timer devicesthroughout your code base when port-ing to a console. Instead, write a wrap-per class around the device that’s usedby the entire code base. Then, whenit’s time to port your game to anotherplatform, you only have to touch onefile by rewriting the timer wrapper. Allother code in the game remains thesame because it all uses your customtimer interface.

Specific Porting Issues

L et’s take a moment to think aboutsome specific issues when porting

from a PC to a console. First, whendeveloping for a console (especially anew console for which the develop-ment environments are not mature),you’re often developing with DOS-prompt linkers and no support pro-grams outside a basic C compiler. So when doing a port, take advantageof the PC’s enormous library of devel-opment support before actually mov-ing the code to the new platform. For instance, using NuMega’s Bounds-Checker is good place to start. Forthose who have never used it,BoundsChecker helps programmersfind memory bugs similar to those dis-cussed above, such as double frees,overwriting boundaries, and memoryleaks. This program can help you

remove memory errors beforeyou even move the code baseover to the console.

Another issue to think about isthe difference between theWindows operating system andwhatever operating system existson the console you are portingto. (Or lack of operating system,as the case may be.) Windows issignificantly more complex thananything you’ll find on a con-sole. (With the obvious excep-tion of the Sega Dreamcast,which has Windows CE, buteven that is a very stripped-downversion of what you use everyday on a PC.) As with all

advanced operating systems, Windowscan be quite forgiving of mistakes —sometimes too forgiving. Because ifyou make a mistake that Windows cansurvive, chances are your consolewon’t. For instance, I’ve seen program-mers not clean up after their memoryallocation because they know thatwhen they shut down their program,Windows will clean up their memoryspace. This is a horrible habit to getinto, but from my experience, it seemscommon. Always work off the assump-tion that you do not have a safety net.When you type a new, match it with adelete immediately. When you open afile, make sure that you close it.

Other issues to consider, which I donot have the space to get into here, areproblems associated with otherresources, such as video space. Just asPCs will always have more main mem-ory than consoles, they will alsoalways have more video memory,because PCs owners are willing tospend more. The same problem existsfor sound memory. Consoles don’t yethave hard drives for high-speed dataspooling or massive state saves, andthe CD-ROMs they do have are usuallyconsiderably slower than what is com-mon on PCs. In short, consoles areamazingly limited compared to PCs.But if you know what you’re doing,you can make a game that’s just asincredible as anything on a PC —sometimes even more so. ■


48


Jack confronts his arachnophobia to squash bugs. Of

course, our memory manager can do that for him.

Code for the memory pool system

and memory management wrapper

can be found on the Game Developer

web site, http://www.gdmag.com.


52

his is the story of a young and inexperienced

company that was given the chance to develop

the sequel to one of the top ten games of all time. The

sequel was allotted roughly one year of development with

its full team. To make up for the short development cycle

and correspondingly small budget, the project was sup-

posed to reuse technology. Not technology in the sense of a stand-alone

engine from another game, but individual components that were spun

off from yet another game, THIEF: THE DARK PROJECT. The THIEF technol-

ogy was still under development and months away from completion

when our team started working with it. To cap everything off, the pro-

ject was a collaborative effort between two companies based on a con-

tract that only loosely defined the responsibilities of each organization.

B y J o n a t h a n C h e y

Irrational GamesÕSYSTEM SHOCK 2

P O S T M O R T E M

Jonathan Chey was the project manager and a programmer on SYSTEM SHOCK 2. He is also one of the co-founders of Irrational Games. Prior to founding Irrational Games, he worked at Looking Glass Studios andprior to that he received his Ph.D. in Cognitive Science from Boston University. He is currently working onhis tan back in his hometown of Sydney, Australia. He can be reached at [email protected].

TT

53


Add to these gloomy initial conditionsthe fact that the game from which ourshared technology was derived slipped morethan six months from the initially estimateddate, that several developers quit during theproject, that we didn’t bring the full teamup to strength until six months from thefinal ship date, and that we struggled withfinancial and business problems during theentire project. Having learned this, youmight anticipate the worst. Strangely,SYSTEM SHOCK 2 shipped within two monthsof its targeted date and will, I hope, be rec-ognized as a sequel worthy of its esteemedancestor.

Let’s step back and trace the origins of thecompanies and the project. Looking GlassStudios is familiar to many as the creator of aseries of highly innovative titles includingthe original SYSTEM SHOCK, the ULTIMA

UNDERWORLD series, the FLIGHT UNLIMITED

line and TERRA NOVA, among others. Threeyears ago, Ken Levine, Rob Fermier and Iwere developers at Looking Glass, strugglingwith the aftermath of VOYAGER, an abortedStar Trek: Voyager–licensed project. At the time, Looking Glasswas in financial and creative disarray after a series of titlesthat, though critically acclaimed, had failed to meet salesexpectations, the latest being TERRA NOVA and BRITISH OPEN

CHAMPIONSHIP GOLF. Frustration with the 18 months wastedon VOYAGER and a certain amount of hubris prompted threeof us to strike out on our own to test our game design andmanagement ideas. We wanted to nail down a rigorous andtechnologically feasible design, focus on game play, and forceourselves to make decisions rather than allow ourselves tostagnate in indecision. We wanted to run a project.

So we formed Irrational Games. After some misadventureswith other development contracts, we unexpectedly foundourselves back at work with Looking Glass as a companyrather than as employees. Initially, our brief was to prepare aprototype based on the still-in-development THIEF technologyrecast as a science-fiction game. The scope of the project wasvery wide, but we quickly decided to follow in the footsteps ofthe original SYSTEM SHOCK. Our initial design problem washow to construct such a game without the luxury of the actu-al SYSTEM SHOCK license, since no publisher had yet beensigned.

Our initial prototype was developed by the three of usworking with a series of contract artists. Our focus was onthe core game-play elements: an object-rich world contain-ing lots of interactive items, a story conveyed throughrecorded logs (not interaction with living NPCs), and gameplay realized through simple, reusable elements. This focusenticed Electronic Arts into signing on as our publisher earlyin 1998 — a fantastic break for us. It meant we could nowutilize the real SYSTEM SHOCK name and characters.

Immediately, we went back to our original design, threwaway some of the crazier ideas that had been percolating andbegan integrating more of the rich SYSTEM SHOCK universeinto the title. That was the point at which the real develop-ment began.

It’s the Engine, Stupid

Nothing impacted the development of SYSTEM SHOCK asmuch as the existing technology we got from Looking

Glass. This fact cannot be classified monolithically under theheading of “what went wrong” or “what went right,” how-ever, because it went both wrong and right. The technologywe used was the so-called “Dark Engine,” which was essen-tially technology developed as a result of Looking Glass’sTHIEF: THE DARK PROJECT (for more about its development,

Irrational Games LLCCambridge, Mass.(617) 441-6333

http://www.irrational-games.comLooking Glass Studios Inc.

Cambridge, Mass.(617) 441-6333

http://www.lglass.comRelease date: August 1999Intended platform: Windows 95/98Project budget: $1.7 millionProject length: 18 monthsTeam size: 15 full-time developers, 10–15 part-time developersCritical development hardware: Pentium II machines, 200MHz

to 450MHz with 64MB to 128MB RAM, Nvidia Riva 128,Voodoo, Voodoo 2, TNT cards, Creative Labs’ sound cards,Wacom tablets, Windows 95/98. Also used SGI Indigo work-stations.

Critical development software: Microsoft Visual C++ 5.0, OpusMake, 3D Studio Max, Adobe Photoshop, Alias|WavefrontPower Animator, DeBabelizer Pro, RCS, Filemaker Pro, andAdaptive Optics motion capture software

SYSTEM SHOCK 2

The team at Irrational Games, from left to right: First row: Steve Kimura/Artist,

Jonathan Chey/Project Director, Justin Waks/Multiplayer Programmer,

Mauricio Tejerina/Artist, Rob "Xemu" Fermier/Lead Programmer, Dorian

Hart/Designer, Lulu Lamer/QA Lead. Second row: Ian Vogel/Level Designer,

Scott Blinn/Level Designer, Michael Swiderek/Artist, Rob Caminos/Motion

Editor, Nate Wells/Artist. Third row: Mike Ryan/Level Designer, Ken

Levine/Lead Designer, Mathias Boynton/Level Designer. Not shown: Gareth

Hinds/Lead Artist.

see “Looking Glass’s THIEF: THE DARK

PROJECT,” Postmortem, July 1999). The THIEF technology was developed

with an eye toward reuse, and I willrefer to it in this article as an “engine.”However, it is not an engine in thesame sense as QUAKE’s, UNREAL’s, andLithTech. The Dark Engine was neverdelivered to the SYSTEM SHOCK team asa finished piece of code, nor werewe ever presented with a final setof APIs that the engine was toimplement. Instead, we workedwith the same code base as theTHIEF team for most of the project(excluding a brief window of timewhen we made a copy of thesource code while the THIEF teamprepared to ship the game).Remarkably, it is still possible tocompile a hybrid executable out of thistree that can play both THIEF andSYSTEM SHOCK 2 based on a variable in aconfiguration file.

This intimate sharing of code bothhelped and hurt us. We had directaccess to the ongoing bug-fixes andengine enhancements flowing from theTHIEF team. It exposed us to bugs thatthe THIEF team introduced, but it alsogave us the ability to fix bugs and addnew features to the engine. Because wehad this power, we were sometimesexpected to fix engine problems our-selves rather than turning them over toLooking Glass programmers, whichwasn’t always to our benefit. At timeswe longed for a finished and frozenengine with an unalterable API thatwas rigidly defined and implemented— the perfect black box. But being ableto tamper with the engine allowed usto change it to support SYSTEM

SHOCK–specific features in ways that ageneral engine never could.

What Went Right

1.THE IRRATIONAL DEVELOPMENT MODEL.In our hubris after leaving

Looking Glass, we formulated severalinformal approaches to developmentthat we intended to test out on ourprojects. Most of these approachesproved to be successful and, I think,formed the basis of our ability to com-plete the project to our satisfaction.

First, we designed to our technologyrather than building technology to fitour design. Under this model, we first

analyzed our technological capabilitiesand then decided on a design thatwould work with it. This process isalmost mandatory when reusing anengine. Sometimes it can be difficult tostick with this when a great design ideadoesn’t fit the technology, but weapplied the principal pretty ruthlessly.And many of the times we did deviatewe had problems.

Another feature of our developmentphilosophy is that everyone partici-pates in game design. Why? Because allthree of the Irrational founders wantedto set the design direction of our prod-ucts, programmers were able to resolvedesign issues without having to stick toa design spec, and we strongly empha-sized game design skills when hiring allof our employees and contractors. Inall our interviews, one of our mostpressing questions to ourselves was“Does this person get games?” Failureto “get” them was a definite strikeagainst any prospective employee.Ultimately, the team’s passion for andunderstanding of games was a majorcontributor to the design of the finalproduct.

The final goal of our developmentprocess was to make decisions and hitdeadlines. We focused on moving for-ward, and we didn’t allow ourselves tobe bogged down. We desperately want-ed to ship a game and believed that thediscipline imposed by the rule of for-ward motion would ultimately pay offin terms of the final product quality as

well as delivery date. While there arefeatures in SYSTEM SHOCK 2 that couldhave been better if we had not rushedthem (the character portraits for exam-ple), we still firmly believe that thegame as a whole was made better byour resolve to finish it on time.

2.USE OF SIMPLE, REUSABLE GAME-PLAY

ELEMENTS. The field of compa-nies developing first-person shooterslike id and Valve, among others, isimpressive. From the outset we realizedthat we would have to work smarter,not harder, to make a game that couldstand up in this market. It would be afutile attempt to create scarier mon-sters, bigger guns, or higher-polygonenvironments. Additionally, we real-ized that our design time and budgetwere very tight and that we would nothave time to carefully hand-script com-plicated game-play sequences in theengine. Instead, in an attempt to shiftthe battlefield, we chose to focus onsimple, reusable game-play elements.The success of HALF-LIFE, whichlaunched while we were in the middleof SYSTEM SHOCK 2 confirmed our intu-itions in this respect. We simply didn’thave the time, resources or technologyto develop the scripted cinematicsequences used by HALF-LIFE. We con-soled ourselves with the knowledgethat we were not even trying to do so.

This strategy melded very well withour acquisition of the SYSTEM SHOCK

license, as the original SYSTEM SHOCK

had already been down this road. Wedecided to expand on elements that weliked in SYSTEM SHOCK and then addsimilar new systems. Each such newsystem was evaluated rigorously interms of game-play benefits, underly-ing technology, and design-timerequirements.

For example, take the ship’s securitysystem. Early on we decided that wewanted to continue the surveillancetheme from SYSTEM SHOCK, which wecould leverage throughout the game toprovide lots of game play for very littleimplementation cost. We realized thatsecurity cameras would be trivial toimplement using existing AI systems(they are just AIs pruned of many oftheir normal abilities) and that oncewe had cameras that could spot andtrack the player, we would be able tobuild several game-play elements outof them. Cameras could summon mon-sters to the player, so much of the


54

P O S T M O R T E M

Concept Sketch of the Psi Reaver.

game play consisted of avoiding detec-tion by security cameras and destroy-ing cameras before you were seen.Because cameras scan fixed arcs, theplayer can utilize timing to sneak bycameras, pop out and shoot them atthe right moment, or get underneaththem and bash them with a meleeweapon. Once a player is spotted, mon-sters flood the area until the player isable to shut off the security systemsomehow or the system times out. Thisintroduces the need to deactivate secu-rity systems via security computers thatare scattered throughout the level.

This type of system was technologi-cally simple to implement and requiredminimal design effort. While not com-pletely formulaic, the basic procedureto set up a camera and security systemcould be shown to designers quicklyusing a few simple rules. From this onesystem and a couple of associated sub-systems, we derived a large amount ofgame play without having designerscreate and implement complicatedscripted sequences and story elements.When you throw together many suchsystems (as we did), you end up with alot of game play.

3.COOPERATIVE DEVELOPMENT. SYSTEM

SHOCK 2 was truly a cooperativedevelopment between Irrational andLooking Glass. Looking Glass providedthe engine and a lot of infrastructuresupport (such as quality assurance),while Irrational handled the design,project leadership, and the responsibil-ity for marshaling resources into thefinal product. Both entitiescontributed personnel to thedevelopment team.Inevitably, some frictionarose from this process whilewe sorted out who wasresponsible for what.However, this cooperationwas ultimately successfulbecause both sides were inter-ested in developing a greatproduct, and we were able tocompromise on most issues.(On the most mundane level,Irrational ended up providinglate-night, weekend meals forits development team and forLooking Glass on some daysduring the week.)

Our cooperative arrange-ment was founded on a con-tractual agreement, but we

avoided falling back on this contract inmost cases. We preferred to resolveissues through informal discussions.Conceptually, Irrational was to beresponsible for the development of theproduct and Looking Glass was to pro-vide A/V content and quality assuranceservices.

During the early stages of the pro-ject, a deal was worked out whereby asmall number of Looking Glass person-nel were subcontracted to Irrationalwhen it was determined that

Irrational’s development budget couldnot cover all the SYSTEM SHOCK 2 devel-opment costs, and as compensation forthe late delivery of the THIEF technolo-gy. Unfortunately, these personnelwere not always available on time — asituation which caused us much con-cern. We knew that this “resourcedebt” could never really be paid offuntil THIEF shipped — nothing is so dif-ficult as prying resources away from ateam that is trying to ship a productbefore Christmas. It wasn’t untilDecember 1998 that we first began tosee some of these promised resources.However, these “resources” — real peo-ple — had just finished up THIEF andwere totally fried following the gruel-ing crunch to ship THIEF. The savinggrace and reason that this arrangementwas ultimately successful was thatthese developers were all talented andexperienced and already knew thetechnology. Their addition to the teamgave us a solid boost during the finalmonths in our ship cycle.

The other benefit of the cooperativedevelopment agreement betweenIrrational and Looking Glass was thatour respective engine programmerscould share knowledge. The ability towalk over and quiz engine program-mers about systems proved to be aninvaluable benefit that more than com-pensated for the lack of a rigorouslyspecified and documented engine.Without a formal understanding of theengine, we had to resolve engine issuesin a personal and informal manner.

This process relied on thepersonalities of the respon-sible individuals on theengine team. Thus, theIrrational programmers bal-anced their time not onlyaccording to the complexityof their tasks but alsoaccording to how muchsupport was available fromthe engine side.

Overall, Irrational’s rela-tionship with Looking Glasswas an unusually close oneand ultimately successful asa result of our mutualrespect and willingness towork with each other.Despite our partnershipbeing based on a formalcontractual arrangement, itwas our ability to work flex-


55

Concept sketches of the Cyborg

Midwife.

A psi-attack against a Hybrid in Engineering.

ibly above this legal level thatenabled the development toproceed smoothly.

4.DESIGN LESSONS FROM

SYSTEM SHOCK. Thoughthe SYSTEM SHOCK license waswonderful, there were someproblems. The biggest was sim-ply the challenge of living up tothe original. Fortunately, wehad the freedom to pay homageto SYSTEM SHOCK legitimately byreusing elements from it.Additionally, we had access tosome of the original developers,including our own lead pro-grammer Rob Fermier.

As with most sequels, wefaced the challenge of keepingthe good elements of the originalgame while not blindly copying them.We knew that most players wouldwant a new story set in the sameworld, with the same basic flavor asthe original game, yet we also wantedto reach out to a broader audience. Weresolved these issues by identifying thekey elements that made SYSTEM SHOCK

so good and reinterpreting those ele-ments using current technology. Someelements made it through largelyunchanged (for example, the story-telling logs and e-mails, the über vil-lain Shodan and her close involve-ment with the player throughout thegame, and the complexity of theworld). Other elements were reinter-preted (such as the look of the envi-ronment, player interface, and tech-niques for interacting with the world).A small number of items were simplycut, most notably the cyberspacesequences — we were fairly united inour opinion that these just didn’t workwell in the original.

Notably, as with the original SYSTEM

SHOCK, we opted to omit interactiveNPCs in the game. SYSTEM SHOCK

eschewed living NPCs because thetechnology of the day was simply inad-equate to support believable and enjoy-able interactions with them. It’s beenfour years, and that technology is stillnot available. So we continued the tra-dition of SYSTEM SHOCK and providedplayers with background informationusing personal logs and e-mails gleanedfrom the bodies of dead NPCs.

Perhaps our biggest deviation fromthe original revolved around the play-er interface. It’s commonly accepted

that SYSTEM SHOCK’s interface, whileelegant and powerful once under-stood, presented a significant barrier toentry. Our primary goal was to simpli-fy this interface without dumbing itdown. We devoted more design effortto this task than to any other systemin the game, and it required many iter-ations before we were happy with it.We adopted a bi-modal interface inwhich there are two distinct modes(inventory management andcombat/exploration) between whichthe player can toggle. This was a riskydecision. This bi-modal model wasmandated by our desire to keep thefamiliar and powerful mouse-lookmetaphor common to first-personshooters while retaining cursor-basedinventory management. How weswitched between modes became ourbiggest design challenge. Sometimesthese mode changes are explicitlyrequested through a mode change key,and sometimes they are invoked auto-matically by attempting to pick up anobject in the world. So far this systemseems to be working well, though onlytime and user feedback will tellwhether we really got it right.

5.WORKING WITH A YOUNG TEAM. TheSYSTEM SHOCK team was fright-

eningly young and inexperienced,especially for such a high-profile title.Many of our team members were newto the industry or had only a fewmonths’ experience, including themajority of artists and all the levelbuilders. Of the three principals, onlyRob had previous experience in his roleas lead programmer. Neither Ken, thelead designer, nor I, the project manag-

er, had previously worked inthese roles.

It’s not totally clear howwe pulled off our projectwith our limited experience.Partially, it must have beendue to our ability to bond asa team and share knowledgein our communal work envi-ronment (“the pit”). To a cer-tain extent, inexperience alsobred enthusiasm and com-mitment that might not havebeen present with a morejaded set of developers. Wealso worked hard to transferknowledge from the moreexperienced developers tothe less seasoned individuals.

Rob worked on an extremely compre-hensive set of documentation for thefunctional object tools, as well as a setof exercises (“object school”) to beworked on each week. These kinds ofefforts paid back their investmentmany times over.

This is not to say that our progresswas all sweetness and light. The artteam, for example, floundered for along time as we tried to integrate thejunior artists and imbue a common artlook in the team’s psyche. We had a lotof very mediocre art midway throughour project and the art team was stag-nating. Ultimately, management hadlittle to do with the art team’s success— they were largely able to organizethemselves and create a solid, originallook.

On the management front, our inex-perience was apparent. We blunderedthrough the early stages of develop-ment with scheduling and manage-ment issues. A large problem was ourfailure to assign specific areas ofresponsibility and authority early on.Bad feelings arose as a result, whichcould have been avoided if we hadclearly delineated areas of responsibili-ty from the start.

What Went Wrong

1.POOR LEVEL DESIGN PROCESS. Leveldesign is a clearly defined pro-

fessional activity in the game industry.It’s a profession that mixes artistic andtechnical skills in equal measure, andthe bar is raised on both fronts everyyear. Despite our understanding from


56

P O S T M O R T E M

Cold comfort in Hydroponics.

the very beginning that thelevel building would be aproblematic part of theSYSTEM SHOCK developmentprocess, we didn’t quitegrasp how difficult and timeconsuming it would be, nordid we expect that it wouldeventually block the ship-ment of the game.

In hindsight, our failureto understand the amountof work needed to designlevels is reprehensible giventhat we had seen the sameproblems emerge on THIEF,and that SYSTEM SHOCK 2 lev-els involved substantiallymore complex object place-ment than THIEF. I attribute this errormostly to our denial of the problem —we had a limited budget for leveldesigners and there is a long trainingtime required to get designers familiarwith the complex Dark Editor. So welocked ourselves into working with theresources we had. Since each individ-ual task required from the designer(apart from initial architectural work)was relatively simple, it was easy tobelieve that the sum total of work wasalso relatively small. What we over-looked was the fact that SYSTEM SHOCK

2 involves so many objects, scripts andparameters. As such, the work load onlevel designers was excessively large. Inaddition, we made a classic beginner’smistake and failed to provide adequatetime for tuning in response to play-testing feedback. In SYSTEM SHOCK 2this was particularly importantbecause the ability of the player to re-enter levels means that the difficultyof a level cannot be adjusted in isola-tion from the rest of the game. Oftenwe had to impose global changesacross all levels, which could be veryexpensive even when the change wasrelatively minor.

We took a novel approach to thelevel building process by attempting toapply design levels using a production-line method. Using this metaphor, weattempted to divorce the differentstages of work on the level: rougharchitecture, decorative and functionalobjects, architectural polish, and light-ing. It was not considered necessary forthe same individual to be involved inall stages of this production process.This approach had positive and nega-

tive consequences. The advantageswere that we could track progress onlevels, we could “bootstrap” levels fair-ly quickly, and we could (in theory)swap individuals in and out of differ-ent tasks. The disadvantages are fairlyobvious, and most stem from the factthat the various stages of level designare clearly not independent (for exam-ple, architecture is ideally built with anunderstanding of the functionalobjects that are to be used in the level).Although I think our process was nec-essary in order to get the game out ontime, it probably detracted from thequality of some of the levels. In addi-tion, psychological factors, such as lackof ownership and training issues (stem-ming from unfamiliarity with levels)speak very strongly against transferringpeople from one task or level to anoth-er. Nevertheless, there were severalbenefits of our procedure — mostly theability to employ particularly talentedindividuals to pinch hit on particularlevels, and the psychological benefitsof completing architectural work earlyin the schedule.

Perhaps the rudest shock in our levelbuilding process came from our misun-derstanding of what part of the processwould prove to be most difficult.Architectural work was actually fairlysimple, because we intentionally keptour spaces fairly clean and did notattempt anything too unusual.However, placing and implementingour objects was far more complex andinvolved than we expected. One diffi-culty that we encountered was educat-ing our designers in what was expectedfrom them in terms of game-play

implementation. Most of ourlevel builders had previouslybuilt QUAKE or UNREAL levelsand were not familiar with thestyle of game play that wewere trying to build in SYSTEM

SHOCK 2. Partially this wasbecause we were simplyexploring a style of game playthat we did not entirely under-stand ourselves. But it reflect-ed a failure on our part toproperly educate the design-ers. Building prototypicalspaces, looking at past gamesand conducting more inten-sive discussions about gameplay will all be part of ourfuture projects.

Our other major design hurdle wasthe instability and inscrutability ofDromed, the Dark Engine editor.Dromed is a cantankerous beast andmany man-months were spent strug-gling with its idiosyncrasies. Perhapsour biggest problem stemmed from thelack of support in one crucial area —the part of the engine concerned withtranslating the designer-placed brushesinto the basic world representation.Like many complex 3D engines, theDark Engine suffers from troublingepsilon issues (data errors caused byrounding inaccuracies) and otherglitches that crop up during level com-pilation. Because the programmer whoimplemented the basic renderer andworld representation was not availableduring the majority of the SYSTEM

SHOCK 2 development cycle, we had towork around these problems. It wasoften a frustrating process when thefundamental cause of the problems wasnot even known. Over time we devel-oped a set of heuristics to avoid themajority of the glitches, but we wereforced to lock down much of the levelarchitecture before we wanted to inorder to ensure stability.

2.MOTION CAPTURE DIFFICULTIES. TheDark Engine has a complex

creature animation playback systemand deformable mesh renderer. Weencountered many problems with thispiece of technology along our dataintegration path, and found quirks inthe playback systems as well. Primarily,the system was hampered by the factthat data frequently had to be modifiedby hand, that mysterious bugs wouldappear in motions during playback


57

Xerxes, central computer of the Von Braun.

which had not been present in thesource data, and that few tools wereavailable for debugging and analysis.We were ill-equipped to deal with thesekinds of problems, having devoted fewresources to dealing with the technolo-gy problems.

Our primary animation source wasmotion capture data. We were nervousabout the technology from the startand attempted to minimize our risk byconcentrating primarily on humanoidcreatures with a small number ofinteresting variants such as spidersand floating boss monsters. In retro-spect, this was a very wise decision, aswe had a lot of trouble even with thissimple set of creatures. Motion cap-ture technology and capture serviceswere contracted from a local compa-ny, but unfortunately this companyviewed its motion capture work pri-marily as a side business and did notdisplay much interest in it. In fact,they cancelled this sector of theirbusiness during our project, and wehad to fight hard to complete the ses-sions that we had already scheduledwith them.

Our capture sessions were hamperedby our inexperience with the technolo-

gy and by the fact that we did not planproperly for the sessions. We hadn’tdefined key poses, rehearsed themotions, or ensured that our motionswere compatible with the technology.Optical capture technology, the tech-nology that we used, can be glitchyand has difficulty with motions thathave obscured markers, as in the deathmotions that were necessary for SYSTEM

SHOCK 2. Over the course of three ses-sions, we gradually refined ourmotions, but we spent a lot of timereshooting failed captures from earliersessions.

Even in the best cases, most of ourcaptures exhibit strange artifacts (feetpointing down through the ground,hands improperly aligned, and so on),whose causes are still unknown to us.In future projects we will hand-ani-mate almost all of the data, and we willneed to understand better what aspectof the conversion process introducedthese artifacts into our final game ani-mations, although the irregularitiesnever appeared in our raw data.Motion capture technology, whilehighly efficient compared to hand ani-mation, must be approached carefullyto obtain good results.

3.IMPLEMENTING SCRIPTED SEQUENCES.Motivated by the dramatic

scripted sequences in HALF-LIFE, weattempted to introduce similar ele-ments into SYSTEM SHOCK 2. In doingso, we broke one of our rules: we triedto step outside the bounds of our tech-nology. Although we attempted rela-tively simple sequences and ultimatelygot them working, they were timesinks, and the payback was relativelyslight. For example, we scripted a hal-lucinatory sequence in which the play-er character rides through the interiorof the alien boss-monster, known asthe Many. This so-called “Many ride”was the source of innumerable bugs —the player would be thrown off themoving platform, manage to kill hisprojected self, bump into walls, and soon. We confirmed our intuition thatthe Dark Engine does not support com-plex scripted sequences well becausethe toolset (AI, moving terrain, andanimation) is not optimized for thissort of behavior. The moral is, onceagain, to work with your technology,not against it.

4.INEXPERIENCE WITH MULTIPLAYER

GAME DEVELOPMENT. Early in theproject we were asked to identify themajor risks associated with the project.Our number one candidate by far wasthe multiplayer component. This wasthe only new substantial engine fea-ture that was to be added and it was acomplicated piece of work. We wereparticularly nervous about this tech-nology for a couple of reasons. First, itis usually much harder to make thiskind of pervasive change to an existingpiece of software than it is to build itin from scratch. Second, Looking Glasshad no track record in shipping multi-player technology and we were notconfident that the development wasfully understood.

Irrational did not want to introducemultiplayer support into SYSTEM SHOCK

2 because we considered it a tangentialfeature that did not contribute to ourcore strengths. However, marketingconcerns dictated it, so ultimately weacquiesced. Our lack of enthusiasm forthis feature contributed to its develop-mental problems because we failed tomonitor its progress adequately or raiseconcerns when that progress fellbehind schedule.

Because this was the first multiplay-er product developed by Irrational or


58

P O S T M O R T E M

Looking Glass, we did not properlyestimate the time required for themultiplayer testing. We did notdevote adequate quality assuranceresources to this feature. Too muchtime was spent testing the multiplayerfeatures over the LAN and not enoughover the more demanding modemconnections.

Given the difficulties posed by themultiplayer technologies, the enginedevelopers working on the task madegreat efforts, and their early resultswere promising. However, the earlydeparture of one of the programmers,and the fact that he was not replaced,ultimately doomed any possibility ofshipping the multiplayer technologywith the initial SKU. Reluctantly, weopted for a patch that would be avail-able at the same time as the single-player box reached shelves. Our coop-erative multiplayer game willundoubtedly be fun and will probablybe enjoyed immensely by a relativelysmall number of our customers.However, we wonder whether our fail-ure to deliver a promised feature in thebox will ultimately hurt us more thanthe absence of that feature from thestart would have.

5.RUNNING A COMPANY WHILE BUILDING

A GAME. As the principals of thecompany, Ken, Rob and I didn’t reallyunderstand what it took to run a busi-ness and simultaneously work in thatbusiness. None of the Irrationalfounders started the company to bebusinessmen, and we have alwaysbelieved that the ultimate health of thecompany depended on us all stayinginvolved in the development process,which is, after all, what each of usenjoys and wants to do. Unfortunately,as anyone who has run a businessknows, there is a lot more to startingand maintaining a company than sit-

ting around at board meetings smokingcigars. From the mundane matters ofmaking payroll, organizing taxes andexpense reports to business negotia-tions and contract disputes, there issubstantial overhead involved in run-ning even a small company such asIrrational. In our naïveté, we did notfactor these tasks into our schedulesand the result was that they mostlybecame extra tasks that kept us in theoffice late at night and on weekends.

As a result of our misjudgment, wejust had to work harder. Rather thanenduring a crunch period of a fewmonths, the entire last year of theproject was our crunch time, as westruggled desperately to fulfill our jobsas programmers, designers, and man-agers as well as keep the money flow-ing in (and out) of the company. Ourtasks were complicated further by theneed to reincorporate the companyfrom an S-corporation to an LLC dur-ing the final two months of the pro-ject (a legal maneuver designed toallow me, an Australian national, tobe allocated company stock).

As well as destroying our personallives, our failure to judge the magni-tude of our task meant that we had to

devote less time than we desired toevery aspect of our work. My program-ming time was severely curtailed and Iwas able to spend far less time onSYSTEM SHOCK 2’s AI than I wished.Simultaneously, I was unable to pro-vide the level of direct managementthat I wanted, and I was forced to post-pone company financial work until theend of the project or hurry it through.The results were less than optimal allaround.

Ultimately, SYSTEM SHOCK 2 turnedout better than I ever hoped it would.The final vindication for me was sittingin my office and playing the game inthe final couple of weeks of the project,while waiting for EA to approve ourfinal build. Despite the lack of sleep,the near-complete breakdown of mynervous system and the 18 months oftime I spent working on the project, itwas still fun to play. I like to think thatwe have managed to capture the feel ofthe original game by putting moregame play into what initially looks likea fairly straightforward first-personshooter. It’s been a great first projectfor Irrational Games and we look for-ward to doing even better the nexttime around. ■


59

Hacking the security system.

It’s not owned by Sony or Time Warneror BMG. Hersh doesn’t get the kind ofpromo that major-label artists do —but she has more control over whatgets released. Hersh is probably nevergoing to chart — but she makesenough to live quite well, and reachesan audience of enthusiasts.

Tonight, I’m going down to theAngelika with my sweetie. It’s NewYork’s primary venue for independentfilms. The movies they show arenever going to appear at yourlocal Odeon or Sony theater;they’ll be lucky to reach500 screens in theStates. But there areenough theaterslike the Angelikato support awhole marketfor indepen-dent films —films thatwill never gross asmuch as a Hollywood blockbuster, butreach an audience of enthusiasts andearn enough to let many people livequite well.

At times, the music and movieindustries look dull and played out andrepetitive. You get the same damn for-mulas over and over, the same artists,the same directors. But that never lasts,and for one single reason: there’s avenue for independent work. Indie

labels and indie film companies experi-ment, at lower budgets, with the off-beat and original. And sometimes, theyhit a nerve, build an audience, and ulti-mately rejuvenate the field. It happenscontinually in the music business, andit happened in film this past summer

with The Blair WitchProject.

Right now, the game industry looksdull and played out and repetitive. Weget the same damn formulas over andover again. Yet another shooter. Yetanother RTS game. Yet another racer.

A title as original or offbeat as SIMCITY

or BALANCE OF POWER or M.U.L.E. —hell, or FROGGER — could not get funded

today. Gaming needs a venue for inde-pendent work.

Last year, Miller Freeman did theindustry a service by launching theIndependent Games Festival. It’s a placefor “garage” developers to showcaseproduct, get exposure, and maybe landa publisher. That’s great, but it’s notenough — because they’re dealing withthe same publishers as everyone else:EA, Interplay, GT, and others of theirilk. The majors will fund the tried andtrue, another shooter or RTS or racer.They’ll happily exploit low-budget new-bies who develop something that fitsinto slots they know how to sell — butthey’re not going to experiment withsomething new, something offbeat,something that will probably fail butjust might rejuvenate the field.

The problem? There’s no way to dis-tribute an independent game. Yes, with

a little effort, you canland a meetingwith the buyerfor CompUSA orElectronics Bou-tique or Software

Etc., but they’renot going to buyyour game with-out the high-bud-

get graphic glitz theyexpect from the majors, six

figures in placement bucks, and a com-mitment to a major marketing cam-paign. The typical mall software outletstill has only 40 facings for computergames, and there are at least 1,500entertainment titles published annually.Anything that doesn’t fit the mold isn’tgoing to get exposure.

Indie films work because there’s a sep-arate distribution channel parallel to theone for conventional film. Indie musicworks because there are a million recordstores that cater to a million differenttastes and a million small clubs whereyou can play to build an audience.

We’ve got nothing similar. We’ve


64

b y G r e g C o s t i k y a nS O A P B O X

A Platform for New Ideas:

Why We Need an Indie Label Now

L ast night, I went to see Kristin Hersh play at

the Knitting Factory. You may not have heard

of her, but the club was packed. Hersh releas-

es her music on 4AD, an independent label.

Greg Costikyan is a freelance game designer and writer. He has published 27 online,CD-ROM, board, and role-playing games, three novels, and a slew of short stories. Hewrites about games for a variety of web and print publications including Salon andHappy Puppy, and recently completed an analyst’s report on the future of onlinegames for Goodreports.com. Visit his web site at http://www.costik.com.

continued on page 63.

illustration by Jackie Urbanovic

got to build it.How? As recently as 1991, a typical

computer game cost around $250,000to develop. Graphics and sound haveimproved a lot since then, but comput-er games haven’t gotten any better asgames. You don’t need $1.5 million indevelopment funding to develop a first-rate game; you can do it on a $250,000to $400,000 budget. You just can’t getshelf space for a low-budget game.

But at that level, you don’t need100,000 unit sales. You can makemoney if you can get rid of 20,000copies. And how tough can that be?Hell, 12 years ago, I sold more than

20,000 copies of a wonky little papergame called Paranoia through a wonkylittle distribution chain cobbledtogether out of specialty hobby gamestores and comic shops. I doubt I had500 points of sale in North America.

It can be done.Some people are trying; Firaxis will

be selling SID MEIER’S ANTIETAM! directto consumers — no retail distribution.Michael Berlyn is bravely struggling tokeep the text adventure alive throughdirect sales (see http://www.cascadepublishing.com).

But we need more. We need a com-pany committed to publishing truly

original, offbeat, cool product andbuilding the channel for its distribu-tion — instead of shoveling the sameold crap to the same old stores.

Gaming needs an indie label — forthe sake of its own health, to act asbasic R&D for the entire field, and tofind new gaming styles that canattract a large audience. Becausedevelopment costs continue to spiralupward faster than unit sales and wehave to find a way to break that ironcycle. But most importantly, becauseI’m tired of the same old same old andwant to play something really cooland new. Don’t you? ■

S O A P B O X


63

continued from page 64.

november 1999twvideo01.ubm-us.net/.../gdm_november_1999.pdf · 2013-07-12 · executive vice...

Documents