Embed Size (px)
Citation preview
JULY 2000
G A M E D E V E L O P E R M A G A Z I N E
G A M E P L A N✎
L E T T E R F R O M T H E E D I T O R
I ’ve yet to meet someone who doesn’t have a strong opinionwhen it comes to the copyrightcage match pitting Hasbro againsteGames, Webfoot, MVP Software,
and Xtreme Games. Not surprisingly,many small developers have been vocal intheir support of the defendants.
If you’re rooting for the underdogs inthis case, don’t blame me for saying this,but I think Hasbro will win.
I don’t think that either side is inherentlyevil. Hasbro claims that the defendants“blatantly copied” Hasbro’s CENTIPEDE,TETRIS, MISSILE COMMAND, and ASTEROIDS,among others. The defendants claim theyimproved on the original games to theextent that they’ve developed entirely newgames. This case once again calls into ques-tion the extent to which you must evolve agame concept in order for it to be legit.
Software copyright law leaves judges alot of room for interpretation. A judgelooking at the Hasbro case would proba-bly focus on three questions to determinewhether copyrights have been violated:
1. Did the defendants add something of value to the original games so as totransform them into something new anddifferent?
2. How much of the original work wastaken by the defendants? What parts of thegames in question were copied from theoriginal? It doesn’t have to be a lot, either— copying even a small portion of a gamemay be illegal if the court determines thatit’s taken from the “heart” of the original.
3. What’s the effect on the potentialmarket for the original game? A judgewould consider whether the games in ques-tion deprived Hasbro of income or under-mined a new or potential market for thecopyrighted game.
Given this litmus test of the defendants’games, the judge will probably examinefirst question most deeply. The prosecutionwill have to prove that not enough valuewas added to the games in question so asto make them derivatives of the originals.
Hasbro will also cite the legal precedentset by Atari Inc. v. North American PhilipsConsumer Electronics Corp., 672 F.2d 607(7th Cir. 1982). In this case, Atari took
Philips to court for releasing K.C. MUNCH-KIN, which Atari said was too similar toPAC-MAN. Initially Philips was victoriousin court, but ultimately it lost on anappeal. The Seventh Circuit ruled thatK.C. MUNCHKIN violated Atari’s copyright,stating that the audio-visual screen displaycopyright had been violated, regardless ofthe originality of the source code.
Some who support eGames and the restof the defendants point to the Lotus v.Borland case of 1995, in which Borlandwas allowed to copy the look of the Lotus1-2-3 menu structure in its own spread-sheet, Quattro Pro. The court stated in theruling that a menu command hierarchywas a “method of operation,” which wasexempted from copyright law. I don’t thinkthat Lotus v. Borland will be a strongenough precedent to save the defendants,however. A menu interface just is one smallpart of an application not at the heart ofthe product, and Hasbro is arguing thatthe defendants went beyond that.
Whether or not Hasbro is victorious, thecompany has reopened a can of worms andit’s going to be up to a judge — possiblysomeone with little or no game play experi-ence — to decide where the line is drawnbetween innovative and derivative gamedesign. This case is yet another indicationthat our industry is big business, and howrisky it is becoming to be an independentdeveloper. And maybe that’s what this caseis really about: a big company flexing itsmuscles to frighten away upstarts.
Adios Mel, Welcome Lisa. Our Artist’sView columnist, Mel Guymon, has decidedto move on from the pages of Game Devel-oper, and we wish him all the best. In hisstead, we welcome Lisa Washburn of Vec-tor Graphics, who will be sitting in for acouple of issues as our guest columnist.Check out her column on page 19.
Welcome Back, K.C. Munchkin
CLet us know what you think. Send
e-mail to [email protected], or write to
Game Developer, 600 Harrison St.,
San Francisco, CA 94107
w w w . g d m a g . c o m
D E V E L O P E R
ON THE FRONT LINE OF GAME INNOVATION
600 Harrison Street, San Francisco, CA 94107t: 415.905.2200 f: 415.905.2228 w: www.gdmag.com
PublisherJennifer Pahlka [email protected]
EDITORIAL
Editorial DirectorAlex Dunne [email protected]
Managing EditorKimberley Van Hooser [email protected]
Departments EditorJennifer Olsen [email protected]
News & Products EditorDaniel Huebner [email protected]
Art DirectorLaura Pool [email protected]
Editor-At-LargeChris Hecker [email protected]
Contributing EditorsJeff Lander [email protected] Washburn [email protected]
Advisory BoardHal Barwood LucasArtsNoah Falstein The InspiracyBrian Hook Verant InteractiveSusan Lee-Merrow Lucas LearningMark Miller Group Process ConsultingPaul Steed id SoftwareDan Teven Teven ConsultingRob Wyatt Microsoft
ADVERTISING SALES
National Sales ManagerJennifer Orvik e: [email protected] t: 415.905.2156
Account Executive, Silicon Valley, Western Region & AsiaMike Colligan e: [email protected] t: 415.356.3486
Account Executive, Northern CaliforniaSusan Kirby e: [email protected] t: 415.356.3406
Account Executive, Eastern Region & EuropeAfton Thatcher e: [email protected] t: 415.905.2323
Sales Associate/RecruitmentMorgan Browning e: [email protected] t: 415.905.2788
ADVERTISING PRODUCTION
Senior Vice President/Production Andrew A. Mickus
Advertising Production Coordinator Kevin Chanel
Reprints Stella Valdez t: 916.983.6971
MILLER FREEMAN GAME GROUP MARKETING
Marketing Manager Susan McDonald
Product Marketing Manager Darrielle Sadle
Field Marketing Manager Jennifer McLean
Marketing Coordinator Scott Lyon
CIRCULATION
Vice President/Circulation Jerry M. Okabe
Assistant Circulation Director Kathy Henry
Circulation Manager Stephanie Blake
Circulation Assistant Kausha Jackson-Crain
Newsstand Analyst Pam Santoro
INTERNATIONAL LICENSING INFORMATION
Robert J. Abramson and Associates Inc.t: 914.723.4700 f: 914.723.4722e: [email protected]
CORPORATEPresident & CEO Gary MarshallCOO/Corp. President, Business Tech & Channel John RussellPresident, Business Technology Group Adam MarderPresident, Specialized Technology Group Regina RidleyPresident, Channel Group Pam WatkinsPresident, Electronics Group Steve WeitznerGeneral Counsel Sandra L. GraysonVice President, Creative Technologies Johanna KleppeGeneral Manager, CMP Game Media Group Greg Kerwin
Game Developermagazine is
BPA approved
W W W . C M P G A M E . C O M
w w w . g d m a g . c o m 5
ZF R O N T L I N E T O O L S
W H A T ’ S N E W I N T H E W O R L D O F G A M E D E V E L O P M E N T | d a n i e l h u e b n e r
NVIDIA INTRODUCES GEFORCE 2 GTS
N vidia is working overtime to maintain its lead in thegraphics processor race with the release of the new
GeForce 2 GTS processor. At the heart of Nvidia’s new chip isthe Nvidia Shading Rasterizer, a new technology that enablesadvanced per-pixel shading. The technology has the ability toprocess seven pixel operations in a single pass simultaneously
on each of the four pixel pipelines. The Nvidia Shading Rasterizer alsoallows for per-pixel control of color, shadow, light, and other visualcomponents. The GeForce 2 GTS delivers up to 1.6 gigatexels per sec-ond and supports up to 128MB of double-data-rate frame buffer mem-ory. The chip also includes a new high-definition video processor.
TESTAROSSA’S VROOM
T estarossa has released version 1.1 ofVroom, an application that uses an
advanced biomechanical model to definebehavioral rules of human motion and auto-matically perform complex operations basedon these rules. The system allows multipleusers to work on different assets at the sametime, so that animation can commencebefore a model or skeleton is finished.Vroom supports retargeting animation datafrom one skeleton to another, updatingmotions to a new skeleton hierarchy, nor-malizing the data to a common referencepose, aligning and rotating motions alongone direction, creating motion loops andtransitions, creating mirror motions, andconverting between file formats. Vroom is astand-alone program for Windows NT/2000and IRIX with prices starting at $3,250.
VROOM 1.1 | Testarossa |www.toolsinmotion.com
GEFORCE 2 GTS | Nvidia | www.nvidia.com
STEINBERG ADDS CUBASE VST 5 TO THE MIX
S teinberg has updated its Cubase music production series, giving the system a com-plete graphic makeover for version 5.0 and adding new features to enhance usabili-
ty and sound quality. Users of the top-of-the-line Cubase VST/32 can take advan-tage of 32-bit floating-point files forrecording, output, and mixdown, as wellas analog sound with Steinberg’s True Tapeprocess. Also new for this version are theLinear Time Base system for precise MIDItiming, a new FX and plug-in system, andthe InWire Studio for online collaboration.Cubase is available for both PC and Mac-intosh platforms.
CUBASE VST 5.0 | Steinberg |www.steinberg.net
RADEON 256 | ATI Technologies |www.ati.com
NEW OPENML STANDARD
A collective of industry leaders is lend-ing its expertise to the creation of a
standard API for graphics, video, andaudio media devices. The standard, calledOpenML, offers a standard technique forinput and output of audio and visual datain an effort to increase application porta-
bility acrossoperating sys-tems and CPUarchitectures.The API also
offers extensions to OpenGL to handlecompositing of multiple graphics andvideo streams. The Khronos Group, whosemembers come from companies including3dfx, Discreet, ATI, SGI, and IBM, is lead-ing the development.
OPENML | The Khronos Group |www.khronos.org
ATI LAUNCHES RADEON
N o longer content with cleaning up inthe laptop and Macintosh markets,
ATI is shooting for the top with its mostpowerful graphics processor ever. DubbedRadeon 256, the chip is built on a trio ofnew technologies: the Charisma Enginefor geometry processing, Pixel Tapestryfor rendering, and Video Immersion fordigital video. Radeon 256 also boasts sup-port for animation features such asadvanced vertex skinning and keyframeinterpolation. The chip delivers 1.5 giga-texels per second, and includes supportfor twin Radeon 256 chips on a singlecard using ATI’s MAXX multi-ASIC tech-nology. Radeon supports up to 128MB ofdouble-data-rate memory at 200MHz anduses Hyper Z technology to boost effec-tive memory bandwidth by 20 percent,enabling the Radeon 256 to access 8GBper second of effective memory band-width. The Radeon 256 is scheduled tobegin appearing on boards sometime thissummer.
6 j u l y 2 0 0 0 | g a m e d e v e l o p e r
I N D U S T R Y W A T C HJ
Take-Two Finds G.o.D. Gathering ofDevelopers is promising to retain its devel-oper-focused business operations despitebecoming a wholly owned subsidiary ofTake-Two Interactive. Under the terms ofthe deal, G.o.D. will operate autonomouslyand continue to handle its properties andgames in North America. The arrangementgives Gathering better access to Take-Two’sextensive European and North Americandistribution network while Take-Two gainsGathering’s top-end PC and console gamecatalog. The two companies have beenworking together since Gathering’s found-ing in 1998, when Take-Two provided partof the company’s initial funding. That rela-tionship expanded in 1999 when Take-Twotook a minority stake in G.o.D. Take-Twohas signed a five-year contract with Gather-ing CEO Mike Wilson and a three-yeardeal with president Harry Miller to keepthem on in their current positions, andGathering’s management will stay in placeto continue the development of the compa-ny’s catalog. Financial terms of the acquisi-tion were not disclosed.
Activision Cans Expert. Though thecompany is expecting strong revenue andearnings growth in its 2000 fiscal year,Activision is taking some aggressive restruc-turing steps. As part of its reorganization,Activision is folding budget games sub-sidiary Expert Software into its other valueline, Head Games. The consolidationincludes the cancellation of all of Expert’songoing projects as well as the terminationof its entire workforce and the closure ofExpert’s Miami headquarters. Activision isalso looking to discontinue non-core prod-uct lines in order to focus its product rangeon titles with online or next-generation con-sole potential. Activision expects approxi-mately $66 million in pretax charges relatedto the restructuring. The company is takingdefensive measures to ward off any unwant-ed takeover bids as it undergoes this reor-ganization by enacting a stockholder rightsmeasure. The plan grants shareholders addi-tional stock or compensation at a rateroughly double their current holdings, butwith the new rights kicking in only if some-one makes a move to acquire 15 percent ormore of the company. Those already hold-ing stakes of better than 15 percent do nottrigger the rights plan.
Sega Promotions. Sega of America haspromoted several key executives as it movesinto a critical stage of its Dreamcast strate-gy. Chief among the changes is PeterMoore’s promotion to the position of presi-dent and COO. Moore had previouslyserved Sega as vice president of marketing.In his new role, Moore is responsible fordirecting Sega’s console and online gamingbusiness in North America. Sega also pro-moted Shinobu Toyoda, one-time presidentof Sega’s PC games division, to the positionof executive vice president of content strate-gy in charge of Sega’s game lineup. ChrisGilbert moved to the role of executive vicepresident of sales, marketing, and opera-tions, while Neal Robison has been promot-ed to vice president of third-party licensing.
Nintendo Under Investigation. TheEuropean Union Commission is lookinginto possible Nintendo price fixing. TheEU’s Competition Commission believesNintendo and its European distributionpartners, Linea GIG SpA, Itochu Corp.,Concentra LDA, Bergsala AB, Nortec SA,CD-Contact Data GmbH, and JohnMenzies PLC, acted as a cartel to divide upthe European market and stifle competition.The commission believes that the group’sactions wiped out parallel trade between EUnations and resulted in product price differ-ences of as much as 100 percent from onecountry to another. The commission canimpose fines as high as 10 percent of thecompany’s annual global turnover. Sega,meanwhile, is the focus of a probe by theUnited States International Trade Commis-sion into whether memory chips used in theSega Dreamcast console violate patents heldby Rambus. Rambus asked the trade com-
mission to investigate in March when itfiled an infringement suit naming Sega andHitatchi, asking that the trade commissionblock imports of the contested chips.
Chipmakers Can’t Slow Down. Thegraphics acceleration landscape continuesto change, as 3Dlabs issued up to 3.69 mil-lion common shares to acquire Intergraph’sIntense 3D accelerator division. 3Dlabs willpay up to $25 million in additional stockor cash if Intense 3D meets certain per-formance marks, and the company willcontinue to provide graphics acceleratorsfor Intergraph’s product range. 3Dlabs con-siders the Intense 3D product line to becomplementary with its own offerings andhas no plans to discontinue products orreduce the workforce at Intense 3D’sHuntsville, Ala., headquarters.
Meanwhile, long-time laptop graphicschipmaker Neomagic is following S3’s leadby eliminating its PC chip business tofocus on the emerging market in Internetappliances. The company is setting itssights on developing technologies forMPEG-4 video, broadband wireless com-munications, and Internet system integra-tion. Organizational changes there includethe elimination of two departments andaddition layoffs resulting in a 35 percentreduction in Neomagic’s workforce. q
NATIONAL CONFERENCE ONARTIF IC IAL INTELLIGENCE
LOCATION TBDAustin, Tex.July 30–August 3, 2000Cost: $605 (member and student
discounts available)www.aaai.org
LINUX WORLDSAN JOSE CONVENTION CENTER
San Jose, Calif.August 14–17, 2000Cost: $25–$795 (early-bird rates
available)www.linuxworldexpo.com
U P C O M I N G E V E N T S
CCAALLEENNDDAARR
T H E B U Z Z A B O U T T H E G A M E B I Z | d a n i e l h u e b n e r
Take-Two’s acquisition of G.o.D. will add theupcoming three-game BLAIR WITCH series toTake-Two’s bottom line.
W hen I was 15 and learn-ing the piano, I wantedto play the Peanutstheme “Linus and
Lucy” with both hands, but I just didn’thave the chops. That song was the veryfirst thing I recorded when I bought myfirst sequencer. I added the left and righthand melodies one track at a time to cre-ate the Peanuts song in all its glory. I feltlike I had actually played it with my owntwo hands. The feeling was unforgettable— I could now play anything I couldimagine. Then the first version of StudioVision arrived where you could actuallyrecord four tracks of audio right into thesequencer. My first attempt at using thisinnovative software was experimental buteveryone that was in the studio knew thepossibilities. Just seeing that audio wave-
form on the same screen as those MIDItracks boded great things to come.
Since then there have been many mile-stones in sequencer technology, eachexpanding what musicians and nonmusi-cians alike can accomplish with patienceand know-how. Cakewalk’s Pro Audiohas become one of the most popularsequencers on the market, and version 9packs a lot of punch.
The Basics
P ro Audio 9 follows a long line ofsuccessful and popular versions of
this PC MIDI and audio sequencer. It is
versatile and feature-packed to the hilt,and easily recognizes most of today’scommon audio hardware and soundcards, with special support for Yamaha’sDSP factory and Sonorus’s STUDI/Ocards. Up to 128 virtual tracks can berecorded at 16, 18, 20, 22 and 24 bits,with sampling rates up to 96kHz. Andthanks to Pro Audio 9’s new Wave Pipetechnology you can use up to 128 real-time audio effects, like a vintage amp sim,four-band parametric EQ, and tons ofdelay-based effects.
Installing the software is simple enough,although getting it to work with my MIDIhardware was problematic. It took a cou-ple of hours of configuring, reinstallingdrivers, uninstalling drivers, querying techsupport at Opcode (I use a Studio 64XTC for my MIDI interface) and Cake-walk, and searching online resourcesbefore the software and hardware finallyjelled, at which point it was easy to get upand running. This is really no fault ofCakewalk’s, but they could have includedmore in-depth help for a larger variety ofsetups. Anyone using a serious rig withfour or more MIDI devices and an inter-face other than the sound card might notfind the help they need.
Walking the Walk
T he program interface is classic Win-dows, with an army of toolbars, key
commands, and right-click pop-up dialogmenus that can control virtually everythingin Pro Audio 9. There are a number ofviews available for recording, editing andmixing. The main Track view is dividedinto the Track pane, where initial settingslike Mute, Solo, Record-Enable and TrackNumber are incorporated, and the Clippane, which shows the song in a horizon-tal timeline and includes MIDI and audiooverviews. The Console view is your virtu-al mixing board, with faders, patch pointsfor effects, and just about anything elseyou would expect a real mixing board toinclude. The Piano Roll view, resembling a2D piano, is an easy view in which to editnote placement, velocity, and controller
9
A U T H O R ’ S B I O | Gene Porfido spends most of his waking hours buried under a pile ofcomputers and musical instruments. When he manages to dig free, he can be found on hisHarley searching San Francisco for a real East Coast–style pizza joint.
XXT H E S K I N N Y O N N E W T O O L S
P R O D U C T R E V I E W
CakewalkPro Audio 9
b y g e n e p o r f i d o
The basic Pro Audio 9 window look: toolbars across the top, the main global track display, and a styl-ish 3D mixing console on the bottom.
w w w . g d m a g . c o m
XP R O D U C T R E V I E W
10 j u l y 2 0 0 0 | g a m e d e v e l o p e r
information. The Staff view shows yourcomposition in musical notation, and is agreat tool for printing and handing outsheet music to fellow musicians during agig. There’s also the Audio view, whichdisplays audio tracks in their waveform toallow most audio editing and arranging.The List view lets you get down to verydetailed and specific editing of mostparameters. Each of these views providesvertical and horizontal zoom tools forquick adjustment. You can also save theviews as layouts that reappear exactly asyou set them up.
Pro Audio 9 also provides windows thatperform special functions including tempoand time-signature changes, markers,SYSX to control SYSX (system exclusive)messages, Studio Ware (virtual templatesof your MIDI gear), a large time readoutcalled Big Time, a video import, and alyric view. All of these different views andwindows contribute to the power of thesoftware and make it highly customizableto fit individual tastes.
Cutting the Cake
R ecording MIDI and audio areextremely easy in Pro Audio 9. On
each track you can select input/outputsource, instrument, port, patch, and justabout anything that’s configurable on amicro level. Setting up tempo, punchin/out recording, loops, multiple channels,channel mutes, and solos are all straight-
forward. You can record in real time or inStep (pattern) mode, whichever suits yourstyle. You can use clips (prerecorded snip-pets of MIDI and/oraudio) by drag-and-drop or cut-and-paste,and you can link all ofyour clips so that anychange made to oneclip will happen to allof them.
Arranging and editingyour tracks after record-ing is also intuitive andagain the options aremany. Markers can beadded anywhere in thesong, named according-ly, and accessed via keycommands or toolbaricons with ease. MIDI effects such as arpeg-giator, echo, filtering, and transposing areaccessible via pop-up menus. Time Stretchand Shrink, which allow you to fit a sectionor sequence to a specified time or length,are great post tools for that one track thathangs a half-second past fade. Tell ProAudio 9 you need to fit it within a certaintime frame and it will do the rest. Audiotracks can also be changed by as much as400 percent or as little as 25.
Quantizing is powerful and precise inPro Audio 9. The resolution can be set toany note value and can be offset anywhereacross a grid (adding or deleting, for exam-ple, five ticks in one measure) to shift the
track in any direction.You can even setparameters likeStrength, Swing, andWindow, which alleffect which notesget quantized andby how much.Groove quantizinglets you apply animported or con-structed groove toany part of yoursong. Want to be ontop of the beat, or atick behind withevery third kickdrum? Set up agroove, apply it tothe track, and start
grooving. There’s also an option called FitImprovisation that will create a tempo mapwithout changing the feel or performance,
for those times when you have akiller idea and want to layit down without setting upa tempo or time signature.
Drum sequencing andediting are greatlyenhanced through theSession Drummer MIDIplug-in. Much like a regu-lar drum machine, pat-terns and parts can beselected and edited withease. Because it acceptsstandard MIDI files, dif-ferent styles and patternscan be created and used inany song. Also new for Pro
Audio 9 is the Style Enhancer, anotherMIDI plug-in that adds feels to existingtracks. There are many styles and each isavailable for multiple instruments, whichcan greatly enhance a track with a feelyou might not be familiar with.
Out of the Oven
R ecording and editing was easy, andthe program was stable as long as I
didn’t have any other programs running. Ihave a 400MHz Pentium II with 96MB ofRAM, so bumping up to at least 128MBwould help. There are a ton of extras,like the pile of MIDI songs covering everymusical style imaginable. The plug-ins arealso good, especially the Session Drum-mer and Style Enhancer, and can helpinspire you when your creativity is run-ning low. They are also great tools forseeing how a song is written, or howusing controllers for pitch bend or other“feel” things are done. SYSX control iswell implemented, allowing you to loadpatches on all your gear every time youopen a sequence. Once you learn how toset up your synths through SYSX com-mands, you can save a lot of time byavoiding having to load all of your pre-sets by hand.
With MIDI/audio integration, you canautomate nearly everything. Stop andstart anywhere in the track, and there’syour mixer, built right in, with good qual-ity effects and incredible control.
One possible working setup, showing the mass of toolbars across the top,the mixing console and piano roll view, and notation across the bottom.
XXXXX
XXXX
XXX
=XX
X
excellent
very good
average
fair
don’t bother
Punching in and out of a guitar or vocaltrack is painless and automatable, andmistakes such as hand noise or hum canbe edited and fixed in seconds. Pro Audio9 has lots of interesting plug-ins, too, likethe vintage amp sim, reverb, and theusual flangers and choruses. While it hasits share of editing tools, there’s supportfor an external editor (Sound Forge XP isincluded) to make professional editing asnap. There’s even a way to turn audioinformation into MIDI note informationon monophonic tracks, which can then betreated like any other MIDI track. Thebottom line is, Pro Audio 9 integratesaudio with MIDI quite well and includessome great tools to manipulate it with.
My main complaints are the windowclutter and dull Windows interface.There’s a lot of stuff going on and it’svery busy, but they might have achievedthe same level of control with a morestreamlined interface. While the appear-ance is color-customizable, you’re stillstuck with a mundane interface. Looking
pretty doesn’t get the job done any better,but it can definitely inspire greatness.How many times have you been turnedon to a piece of gear because it lookedcool or had some crazy colored lights? Itwould have been nice if the Consoleview’s appearance had been reflectedthroughout the whole program. But inlight of the program’s functionality, theaesthetics are trivial: If it works, don’tbreak it. And Pro Audio 9 works.
Other than these few minor UI com-plaints and technical-support shortcom-ings, Pro Audio 9 is everything it aims tobe and certainly deserves its popularity.While there’s not enough here to makeme abandon my Mac, Pro Audio 9 wouldbe my first choice for a top-notch PCsequencer. For the professional who needsto tailor his or her tracks with fine detail,this is a software package that can handleany project with great flexibility, strongperformance, and the support of a num-ber-one seller, so you can have your cakeand eat it too. q
STATSCAKEWALK
Cambridge, Mass.(888) CAKEWALK or (617) 441-7870www.cakewalk.com
PRICE: $429SYSTEM REQUIREMENTS: 200MHz Pentium II,
64MB RAM for Windows 95/98; 300MHzPentium II, 128MB RAM for Windows NT.
PROS1. Easy setup for audio and MIDI with your
PC’s sound card.2. Excellent collection of MIDI files, song
styles, and tutorials; good plug-ins forMIDI and audio.
3. Extensive online support through news-groups and users’ groups.
CONS1. Boring interface; extremely cluttered
toolbars.2. Lack of assistance in setting up external
MIDI interfaces and complicated MIDIstudios.
3. Poor e-mail support.
PRO AUDIO 9 XXXX
w w w . g d m a g . c o m 13
A s a kid who grew up on1970s television, I was fasci-nated by the amazingadvances in science shownto me every night. I watched
the government establish a moon base onSpace 1999 and Leonard Nimoy telling mealiens may have built Stonehenge on InSearch Of.... I also knew that if you wereimportant, good looking, and in a terribleaccident, the government could rebuild youand make you better than you were, like inThe Six Million Dollar Man. A lot of kidsmy age were fascinated with the idea ofbionics. I am sure the boys at least pon-dered Lindsay Wagner and the implicationsof a bionic woman.
Here we are in the year 2000. Alas,1999 came and went without a moonbase. We still have no real idea how any-one could have built Stonehenge. However,it is starting to look like bionics maybecome a reality. The idea of stimulatingnerve cells with electrical impulses has gen-erated a lot of possibilities for treatingphysical disabilities. For example, cochlearimplants have become a promising treat-ment for some types of deafness. Morerecently, Christopher Reeve’s high-profilestruggle with paralysis has opened manyeyes to the possibilities of electronic stimu-lation of muscle tissue for locomotion.
Bionic Animation
W hen it comes to animation, we arestill in the fairy tale days. Our
characters are like Pinocchio. We controlthem by pulling on the limbs and bonesdirectly, much as a puppeteer controls hismarionette. Creating realistic-looking ani-mation this way is very much an art.However, if we were to move a characterby simulating the actual physical mecha-nisms that make a real person move, wewould get realistic animation automati-cally. At least that’s the theory. In prac-tice, controlling a character through aphysiological simulation would be a
major challenge. However, that doesn’tmean we can’t experiment with new tech-niques for locomotion.
Recently, I decided that I wanted to ani-mate a dolphin. My typical approachwould be to create a polygonal model andembed a simple skeletal system within theobject which would be used to animate it.I could then create a set of animations tocause the dolphin to look like it was swim-ming and turning. However, this type ofanimation would not allow the dolphin toreact to situations such as obstacles andchanges in water flow. So I thought itwould be interesting to attack the problemas a physical simulation.
Last month (“In This Corner... TheCrusher!” June 1999), I used a mass-and-spring system to manipulate a free-formdeformation lattice. Now, a dolphin is notexactly a soft-body object, since it has aninternal rigid skeleton. However, dolphins
do move in a very fluid and soft manner.Demetri Terzopoulos has written about theuse of a spring system to create artificialfishes (see For More Information section),so it seemed like a promising approach.
Building an ArtificialDolphin
I start with my dolphin mesh as you cansee in Figure 1a. From this model, I cre-
ated a low-level physical representation ofthe dolphin shown in Figure 1b. This con-trol mesh represents the basic surfacesthat I will need for the physical simula-tion. The key pieces are the tail fluke,which will provide the basic propulsion,as well as the dorsal and pectoral fins,which will keep the model from turningover while locomoting.
In order to create the physical simula-tion, I need to take this control mesh and
The Six Million Dollar DolphinVirtual Bionic Characters
A U T H O R ’ S B I O | When not out hanging with the dolphins at the beach near his home,Jeff can be found at Darwin 3D thinking about the waves. Knock him off his board with a let-ter to [email protected].
j e f f l a n d e r G R A P H I C C O N T E N T
turn it into a mass-and-spring system. Thisis quite easy as I simply convert the ver-tices in the control mesh into mass points,and the edges that connect them becomethe base springs. In order for the object tomaintain stability, I need to add crossbeamsupports much as I did in the FFD simula-tion last month. Once this is accomplished,I end up with a mass-and-spring systemthat looks like Figure 2.
If I drop that into my physical simula-tion with the gravity turned off, it will
float through the simulation space. It willbounce off any objects or surfaces it col-lides with, generally acting like a blobbymarine mammal that doesn’t move much.In order to make the object move, I needto add some muscles.
Adding the Bionics
T o get things moving, I want to createsome virtual muscles. It seems that
they should be positioned in place of someof the existing structural springs in theobject, so let me take a minute to reviewthe mathematics of these springs. Thesprings in the simulation are a combina-tion of a linear spring force and a dampingforce as defined by Hook’s spring law.This formula relates a spring force, f,between two particles, a and b.
The stiffness of the spring is defined bythe spring and damping coefficients, ks andkd. The value l is known as the rest lengthof the spring. This defines the desired dis-tance between the two particles as set inthe initial mesh. This rest length is the keyto creating a virtual muscle. If I were todynamically decrease the rest length of aspring, it would begin to contract, causinga force that brings the two particlestogether.
I can define a maximum contractionamount for each muscle. For example, Imay want a muscle to contract to 50 per-cent of its rest length. The maximum con-traction becomes 0.5 times the rest length.I can then use a percentage in the range of0 to 1 as an activation value to make themuscle go from rest to the 50 percentlength target.
Figure 3 shows the control mesh withsome springs activated as muscles,marked in dark orange. The first frameshows the start of the simulation, thenthe muscles start contracting to create thesecond frame.
Controlling the firing of the muscles isa job for some form of primitive AI sys-tem. A dolphin swims by contractingmuscles that cause the animal to arch itsback in an alternating up-and-downmotion. I can simulate this by first con-tracting the muscles along the top andthen the muscles along the bottom. Thisis most easily accomplished with a sinewave that is scaled into the range of 0 to1. I then offset the phase of the two setsof muscles by 180 degrees. That way,while the top muscles are contracting, thebottom muscles are relaxing. I can con-trol the speed of contraction by increas-ing the wave frequency.
Moving Through theWater
T he use of this primitive brain to causemuscles in the simulated dolphin to
contract achieves the effect of making thedolphin bend back and forth. However, itdoes not really move anywhere in the sim-ulated environment. That’s because there
f k l r kl l
lll
f f
l a b
l v v
a s d
b a
a b
= − −( ) + −
= −
= −
= −
˙
˙
j u l y 2 0 0 0 | g a m e d e v e l o p e r14
G R A P H I C C O N T E N T
FIGURE 2 (top). The dolphin’s mass-and-springsystem.FIGURE 3 (bottom). The muscles in action.
FIGURE 1A (left). The dolphin mesh we start out with.FIGURE 1B (right). The control mesh we’ll use in our simulation.
are no forces actually causing any propul-sion. The key to making the dolphin swimthrough the water is hydrodynamics. Ineed the movement of the dolphin’s tailfluke to displace virtual water and causeforward motion.
You can see how this happens in Figure4. Vector n is the normal to the surface ofthe control mesh. Since the positions andvelocities for all nodes in the control arecalculated in the simulation, I can examinedirectly the velocity vectors of each nodein the system, for example va and vb. Foreach triangle in the control mesh, let meuse the formula
where A is the area of the control trianglebeing tested. As you can see, if the veloci-ty of a particle in the control mesh ismoving in the direction of the surfacenormal, I will get the maximum force onthat node. The force is divided by three,since three nodes make up a control tri-angle. If the velocity vector is eitherpointing in the opposite direction from ortangential to the sur-face, no displace-ment force is creat-ed. This is exactlythe behavior that Iwant.
However, I need todetermine the surfacearea of the controlmesh triangles quick-ly. Since the object isa soft body, the posi-tions of the controlmesh vertices changeduring the simula-tion. I will also needto calculate the sur-face normals foreach triangle.
A very common3D graphics opera-tion is calculating thenormal to a triangleby using the crossproduct of the twovectors that make upthe triangle. How-ever, another keybenefit of the cross
product is that the magnitude of the crossproduct of two vectors is equal to the areaof the parallelogram that the vectorsdescribe, as you can see in Figure 5.
So the area of the triangle is equal tohalf the magnitude of the cross product.That means I can rapidly calculate the nor-mal of a triangle as well as get the area ofthe triangle by using the cross product.
I can use this information to calculatethe normals and the area at each controltriangle and apply the hydrodynamicforce to each control vertex. The dolphinnow swims forward and the aerodynamicdesign of the control mesh automaticallyserves to keep the dolphin upright. Infact, I can even use this aerodynamiccapability to control the direction the dol-phin swims.
Controlling the Animal
Dolphins move by subtly changing thedirection their tail is moving as well
as changing the direction of their headand the attitude of their pectoral fins. Ican control my virtual dolphin the same
fA n v n
= −•( )
min ,03
w w w . g d m a g . c o m 15
a
bc
A = | ac x bc |
FIGURE 4 (top). The dolphin in motion.FIGURE 5 (bottom). Area of a parallelogram.
va
n vb
16
G R A P H I C C O N T E N T
way. Direction-control muscles can beactivated on the neck and pectoral fins toguide the steering of the dolphin much inthe way that one might maneuver aradio-controlled glider. These same con-trols can also be used to adjust the pitchof the pectoral fins, causing the dolphinto swim lower or higher in the water col-umn. I have found that these musclesneed only contract very slightly to affectthe animal’s direction.
In his paper, Demetri Terzopoulosdescribes using a learning system to opti-mize the motor-control parameters toachieve goals like maximum speed efficien-cy. I did not experiment with any learningalgorithms for the dolphin, choosinginstead to tune the parameters by hand. Ithink a learning system would greatlyimprove the performance and it’s some-thing I would like to investigate further inthe future.
These low-level steering controls couldbe combined into high-level behaviors toachieve things such as schooling andthreat-avoidance among multiple synthet-ic dolphins. It’s clear that many of thesetechniques can be applied directly to real-time game simulations.
Final Display
Once the dolphin is moving with themuscle system, I want to render it. I
could just render the control mesh direct-ly, though it is not very interesting visual-ly. However, the control mesh can be used
to determine the position of thebones in the animal. I positionbones at key locations along theanimal’s spine and use the posi-tion of the control mesh to deter-mine the orientation of thebones. These bones are weightedto the display mesh based onproximity and the mesh is ren-dered using the same matrixdeformation system that I used inthe FFD demonstration lastmonth. This gives me a visuallydetailed render model that is ani-mated using the simple controlmesh.
Other Creatures
I also spent some time designing othercreatures. Instead of a swimming animal,
I created a four-legged walker, which youcan see in Figure 6. This creature makes useof a friction model to move itself forward.However, the control sequence for the mus-cles on this creature is much more compli-cated than for the dolphin. I had a veryhard time producing any gaits besides asimple walk. This is a case that would bene-fit greatly from an automatic learning sys-tem for the animation sequencer.
It’s relatively easy to create a creature ina modeling package and bring it into thesimulation. Attach a few springs and mus-cles, and away it goes — usually collaps-ing into a heap of vertices on the floor.However, achieving a stable object is pret-ty easy. The tricky bit is coming up with alocomotion algorithm that works as wellin practice as it did when you thought itup. I would like to try a slithering gaitbased on directional friction as GavinMiller described in his research on snakesand worms (see For Further Info). Itseems like that would look very interest-ing in a real-time game and I’m confidentthe performance would be much betterthan the 30 seconds per frame that Millerneeded when he did his work in 1988.
Other Methods
R ather than using the soft-body mus-cle-based technique for animating the
characters, I could have driven the skele-ton of the dolphin directly. In place of
using springs as muscles, I could have usedtorques to dynamically change the orienta-tion of each joint in the character. Thatwould have probably simulated how anactual dolphin moves more accurately, butthat would have required me to use a fair-ly complex articulated body solver todetermine the dynamics of the system. Ifyou are interested in pursuing that direc-tion for dynamic animation, I suggest youcheck out Jessica Hodgins’ and ChrisHecker’s presentations from this year’sGame Developers Conference. That mate-rial will get you going with a hopper atleast, if not an articulated dolphin.
For now, play around with the musclesimulator and see what you can create.This application can be greatly improvedby creating a more robust controller UI.The control parameters could also beoptimized through the use of a learningtechnique as I mentioned above. Getstarted by grabbing the source and appli-cation off the Game Developer web site,www.gdmag.com. q
j u l y 2 0 0 0 | g a m e d e v e l o p e r
B Terzopolous, Demetri, Xiaoyuan Tu, and
Radek Grzeszczuk. “Artificial Fishes:
Autonomous Locomotion, Perception,
Behavior, and Learning in a Simulated
Physical World.” Artificial Life Vol. 1, No. 4
(December 1994): pp. 327–351.
B Miller, Gavin S. P. “The Motion Dynamics of
Snakes and Worms,” Computer Graphics
Vol. 22, No. 4 (August 1988): pp. 169–173.
B Hecker, Chris. “Simulating a Locomoting
Character.” Game Developers Conference
2000. Go to www.d6.com/users/checker/
index.html for more information.
B Hodgins, Jessica. “Controlling a Locomoting
Character.” Game Developer’s Conference
2000. Go to www.gvu.gatech.edu/
~jessica.hodgins/ for more information.
SODACONSTRUCTORwww.sodaplay.com/constructor/index.htm
This is a cool application on the web that quite
a few of you have written me about. It allows
you to create a simple 2D mass-and-spring
object and animate it using muscles in a nice
Java interface.
F O R M O R E I N F O R M AT I O N
FIGURE 6. The walker. This creature relies on friction to propel itself.
M orphing between 3Dobjects is not all thatnew to computer graph-ics. If you have seeneven one big-budget,
blockbuster Hollywood movie in the lastfive years you have seen 3D morphing inaction. However, the technique holdsexciting new possibilities for those of usworking with real-time 3D graphics. Asgaming technology closes the gap betweenprerendered movies and real-time 3D, wewill see morphing used for special effectsand magical transformations more often.As artists continue to experiment morewith mor-phing, newproblemsand tech-niques aresure tocome up.This articlewill exploreone suchproblem,morphingbetweenobjects thathave different numbers of vertices, andthe techniques that came out of workingaround it.
In games today, the most prevalent useof morphing is for bringing characters tolife through facial animation and lip-synch. This is done by creating morphtargets of the character smiling, frowning,mouthing different phonemes, and so on,and morphing between them. This is arelatively easy process for an artist to setup, at least from the point of view of get-ting the morphing to happen. However,animating it and making it believable is awhole other art form, and the subject ofanother article. In its most basic form, theprocedure for setting up a charactermodel for morphing lip-synch is as fol-lows. First, make as many clones of the
object as there are morph targets. Next,carefully adjust the key vertices on eachnew model to form different phonemesand expressions. Finally, animate themodel, morphing between the targets.Animation is usually set up with the helpof a morphing utility that allows you toassign each morph target to a separatechannel and animate a blend between sev-eral targets. 3D Studio Max 3 ships witha modifier called Morpher that works inthis way.
The above example, with the samenumber of vertices in an identical order, isthe simplest scenario for creating a
morph. Byusing aclone ofyour objectfor eachmorph tar-get you areensuringthat themorph willwork, butwhat if youwant to usemorphing
for something other than lip-synch? Whatif you need to morph between two ormore separate objects that were createdindependently of each other and have dif-ferent vertex and polygon counts?
Enter the party girl and the beast (Fig-ure 1). Is it possible to take a 1,770-poly-gon, 921-vertex model of the party girland morph it into a 1,068-polygon, 536-vertex gorilla head? I explored severalpossible ways to accomplish this with 3DStudio Max (other 3D packages will mostlikely have similar tools). But before weget ahead of ourselves, let’s start withsome basics about morphing.
Morphing Basics
In simplest terms, morphing is theprocess of taking one shape and trans-
forming it into a different one. In theworld of 3D object creation, there are twobasic requirements for setting up polygon-based models for morphing. The first isthat all the objects that are going to beused for the morph must have the samenumber of vertices in each piece of geome-try. The second is that the vertices in eachmodel must be arranged in the same order,which I will refer to as surface order.
Why is this? Behind the magic of morph-ing is a software algorithm that takes thephysical features of one object (Object A)and gradually transforms them into the fea-tures of another object (Object B). Obvi-ously, a computer doesn’t understandwhich of Object A’s features correspond towhich of Object B’s, so we have to specifythat explicitly. Giving an object’s vertices aspecific number that has a correspondingnumber in the object that it is morphinginto accomplishes this. The computer thenknows to move Object A’s vertex 20 to ver-tex 20 on Object B. If A’s vertex 20 is inthe upper-right corner of the model and B’svertex 20 is in the lower-left corner, thenObject A will appear to flip upside down asit changes into Object B. If there are morevertices in Object A than in Object B, youwill not be given the option of morphing atall. This is why the lip-synch exampleabove works so well. By taking clones ofthe original model and simply moving ver-tices around, being careful not to add ordelete any, you are ensuring that the mod-els will all have the same vertex count andsurface order. Your character will spring tolife and the morphing will work right away.
This brings us to our current dilemma ofmorphing between the human and the
Beauty and the Beast Morphing Mayhem
w w w . g d m a g . c o m 19
A U T H O R ’ S B I O | Lisa Washburn has successfully morphed back into her real job, run-ning her RT3D art production company Vector Graphics (www.vectorg.com). Send commentsand questions to [email protected].
FIGURE 1. Morphing a woman’s head into a gorilla’s presents a formi-dable challenge because of their different vertex and polygon counts.
l i s a w a s h b u r n A R T I S T ’ S V I E W
gorilla head. As the models stand now, wedo not have the option of morphing them.Before we begin looking at how we canmake these two objects morph, let’s take acloser look at the models.
The gorilla head model — let’s call himBobo — consists of four separate pieces ofgeometry. There is a separate sphere foreach eye, a piece for the lower jaw, andthen the bulk of the head. For the sake ofsimplicity, I’m only going to morph thebulk of the head, which as I mentionedbefore has 536 vertices and 1,068 faces.The human female head, which we willname Vivian, is all one piece of geometrywith 921 vertices and 1,770 faces.
So what are our options? To be able tomorph, we must first rebuild the models sothat they have the same vertex count. If youare starting as I am with models that havealready been textured and mapped, this isn’tthe best news, as you will have to re-createthe mapping. If you are using Max and youhaven’t collapsed the object’s modifierstack, simply make a clone of the originalmodel, hide it, and use it later to acquirethe mapping information. There are fourdifferent procedures that we’ll try in orderto rebuild the models so they share thesame number of vertices in the same order.
Cloning
T he first and most obvious procedure isto clone one of the objects and
rearrange the vertices until they match theother object’s. As long as you don’t divideany edges or weld up any vertices, you areguaranteed a model that will morph. Thisworks very well for objects that are similarin shape, size and vertex count, like the lip-synch example mentioned above. However,for radically different models, particularlythose with very high polygon counts, thiscan be an extremely tedious, time-consum-ing, and messy operation. To apply this tomy example I cloned Vivian, who has thehigher vertex count. After scaling the modelup to be a bit bigger than Bobo’s head, Ibegan using Max’s 3D Snap tool to snapvertices into place. After I got four or fiveinto place, I began to realize that I wouldhave to do this 921 times! Then, I wouldhave to turn edges and deal with where toput the extra vertices. Even if I used Bobo’shead as the clone, I would still have to
move 536 vertices by hand. This is clearlynot an elegant solution. What if I had 100models that I needed to morph? What if themodels were 30,000 vertices each? Theremust be an easier way.
Shrink Wrap
T he next option came out of a brain-storming session with some colleagues
on possible ways of automating the cloningoption above. How could we maintain thevertex count and surface order that resultsfrom cloning the object, yet not have to go
through the tedious effort of moving eachvertex manually? Shrink-wrapping poppedinto the conversation. What if you had anobject, for example a sphere, that you couldshrink wrap onto other objects? If you tookclones of the same sphere and wrappedthem around different objects, theoreticallyyou would be able to make perfect copies ofyour original objects with the same vertexcount, and therefore be able to morphthem. Several 3D packages already have asimilar tool. In Max it’s called Conform andworks by projecting the vertices of oneobject onto the surface of another. You aregiven a couple of choices on what directionyou want the vertices to be projected. Maxalso has a Conform Space Warp, but theConform compound object is more applica-ble to what we are trying to do.
There are two different ways to approacha procedure like the Conform tool. One isto create an object independent of the mod-els that you are interested in morphing,making a clone for each model, and thenconforming each independent object to adifferent original model. The main advan-tage to this technique is that you can con-trol the number of vertices in the finalobject. If neither of your original modelshas the vertex and polygon count that youneed for the final objects, then this tech-nique can get you the numbers that youneed. To test this out on my two heads, Icreated a sphere of 482 vertices and 960faces and then cloned it. I then selectedBobo’s head, aligned and centered the pivotpoint, and did the same to Vivian’s head. Ithen aligned a sphere to each of the originalobjects and scaled them to be a bit largerthan the models that they would be con-forming to. I generated the conform objectsusing the Along Vertex Normals option andwas struck by two things. The first is thatthe Conform tool has a bug that occasional-ly combines the original model into the con-form object. The other is that the resultingmodel was blobby and missing the detailsthat I had so carefully modeled into myfaces, as you can see in Figure 2. I was ableto get around the bug by clicking the HideWrap-To Object under Update and settingthe Standoff Distance under the WrapperParameters to 50 and then back to 1. Theblobbiness problem was not so easy to getaround, however. Theorizing that the prob-lem might have been caused by the sphere
j u l y 2 0 0 0 | g a m e d e v e l o p e r20
FIGURE 2. Sphere conform results for Vivian(top) and Bobo (bottom), showing the originalmodel, the low-resolution results, and the high-resolution results.
A R T I S T ’ S V I E W
having fewer vertices than the object that itwas conforming to, I replaced the 482-ver-tex sphere with a 3,282-vertex one. Thisworked well for Bobo’s head with the Con-form object, even getting the modeled nos-trils. The result for Vivian’s head, though,wasn’t much of an improvement over thelower-resolution sphere. The detail in hermouth and nose are completely gone.Another issue to take into account is thatVivian had originally been modeled withvertices placed in key facial muscle loca-tions for lip synch and facial animation.This setup is completely missing from theuniform mess of the Conform compoundobject. Ultimately this technique did morph,and might be useful for objects that don’thave a lot of detail. Still, the resulting mod-els were not close enough to the originalsfor my purposes.
Another way to use the Conform tool isto make a clone of one of the original mod-els and wrap it onto the other model. I triedthis first by making a clone of Bobo’s head,aligning it to cover Vivian’s head complete-ly, and clicking the conform button. Theresulting model was very strange, as youcan see in Figure 3. Some of the details of
the original model, such as the vertices thatmake up the nostrils of Bobo’s nose, werestill preserved in the new model, simplyhaving been flattened out and pushed intothe shape of Vivian’s nose. Working in theopposite direction, Vivian into Bobo, pro-duced the same strange results. Althoughthe conform or shrink-wrap concept haspotential, its execution needs to be morespecific. There needs to be a more intelli-gent way of figuring out where the verticesshould go when they wrap to the secondobject.
Cross Section
A nother rebuilding option that cameout of our brainstorming session was
the use of cross sections. What if we had ablack box that would take each model, sliceit into a specific number of cross sections,normalize the number and order of the ver-tices on each cross section, and regeneratethe model? This would allow us to create anumber of models that have a set numberof vertices in a set order. I set about figuringout how to do this in Max.
Cutting the model into cross sections wasa piece of cake with Max’s Section
Object. Basically the SectionObject is a rectangular plane thatyou move and rotate to whereyou want to generate a cross-sec-tional spline. You then hit theCreate Shape button under theModify panel and you get a 2Doutline of your model at the pointthrough which the Section Objectwas slicing. This is illustrated inFigure 4. The next question ishow to take the cross sectionshapes and normalize the vertexcount and order. This took a lotof searching through Max plug-insites on the web, but I finallyfound a plug-in called Hsplinefrom Habware (www.habware.at/duck3.htm). This shareware plug-in allows you to normalize thesegments of the spline either bythe number of segments or by seg-ment length. By selecting all thesplines and applying Hspline, yougenerate a set of shapes that allhave the same number of verticesand all the vertices will be evenly
spaced apart, which you can see in Figure 5.By creating the same number of SectionObjects for each model that you want tomorph, and with each Section Object hav-ing the same number of vertices, you will becreating models that will be able to morph.
The next issue is generating a model fromthe new splines. Searching through Maxagain I came up with the Cross Sectionmodifier. This modifier generates a splineskeleton or cage by connecting the verticesof different shapes in the same object. It isalso dependent on vertex number and order,
j u l y 2 0 0 0 | g a m e d e v e l o p e r22
FIGURE 3. Conforming a clone. This technique produced someodd-looking results, but still has promise for the future.
FIGURE 4 (top). The Section Object.FIGURE 5 (bottom). Normalized spline with ver-tex numbers.
A R T I S T ’ S V I E W
so the Hspline plug-in was a real lifesaverfor this part of the procedure as well. Hav-ing the same number of vertices on eachspline makes the Cross Section modifierwork much more smoothly.
One tip for using the Hspline to facilitatethe Cross Section modifier is to go througheach spline and check for three things. First,verify that there is indeed the number ofvertices on each spline that you dialed in, assometimes Hspline puts an extra vertex ontop of the first vertex. Second, make surethat the order of the vertices goes in thesame direction for each spline. If the orderof vertices is clockwise on one spline andcounterclockwise on the next, the CrossSection modifier will create a twisted splinecage. To access the vertex numbers in Max,select the spline, go to Sub-Object > Dis-play, and click the box that says Show Ver-tex Numbers. To reverse the order of thevertices, go to Sub-Object > Spline and hitthe Reverse button. The third thing to lookfor is whether the number-one vertex is inapproximately the same location for eachspline. Cross Section uses the vertex num-bers to connect vertices, so if the first vertexon each spline is in a different place you’llagain end up with a twisted spline cage.
Before you apply the Cross Section modi-fier, you have to attach the splines withineach object. This is very important, as theorder in which you attach the splines toeach other determines the surface order ofthe vertices in the object. For example, ifyou attach the splines from bottom to topin Object A, and top to bottom in theObject B, when you go to morph A into Bthe model will turn upside down. If youattach both models top to bottom, then themodel will remain right side up. A quick
warning here is that if you attach thesplines in a haphazard order, for exampleyou attach the first to the third, then to thesecond, then to the fifth, and so on, theCross Section modifier will generate a cagethat follows that order, generally resultingin a twisted mess.
After you apply the Cross Section modifi-er, which gives you the spline skeleton, thenext step is to apply a Surface modifier. TheSurface modifier generates a patch skinbased on the vertices in the spline skeleton.Taken together, the Cross Section and Sur-face modifiers are referred to as SurfaceTools in Max. The nice thing about the sur-face modifier is that it generates a patchobject that gives you the option of dialingup or down the steps in the Patch Topology.This increases or decreases the complexityand ultimately the face count of the model.
I tried this procedure with two simpleshapes and it worked beautifully, so theconcept is correct. Does it work for modelsas detailed as Vivian and Bobo? In a word,no. Basically, I had the same problem withthe rebuilt model with this procedure as Ihad with the Conform tool — the resultingmodel is not close enough to the original,as you can see in Figure 6. Also, this proce-dure requires a lot of tweaking and manip-ulation of the splines to get the Cross Sec-tion tool to create a spline cage that is notseverely twisted and therefore unusable.This brings us to the fourth option.
Plug-ins
S urprisingly, I found no commerciallyavailable Max plug-ins to accomplish
this task. I did find one shareware plug-in,but it was very difficult to set up and did-
n’t work in the end. I posted to severalmailing lists asking if anyone knew of anyand didn’t get a single response. Obviouslythere is a need waiting to be filled (hint tothose of you more industrious readers outthere). If I were writing a wish list for thisplug-in, I would want something that cap-tures, as close as possible, the originallocation and placement of the vertices onthe original model, as well as allows mor-phing of mapping coordinates. A tall orderperhaps, but it never hurts to ask.
Where We Stand
S o can a wild-eyed party girl from thewrong side of the tracks mutate into
a snarling beast? In a nutshell, not quiteyet. Morphing between two independent-ly created, highly detailed character mod-els with different vertex counts is not aneasy task. It’s possible if your models aresimple shapes and you don’t have a lot ofspecific detail that you need to preserve.Many models that you might want tomorph do fall into this category, forexample a sack of gold into a sword, orone type of car into another. Even morph-ing Bobo’s head into a less detailed char-acter would have worked with the shrinkwrap technique.
However, rebuilding models that arehighly detailed and need to have vertices inspecific places (for example if you need tocreate the effect of facial muscles for lip-synch, like with Vivian) is still difficult toautomate. We need a tool that automatesand streamlines this procedure. Imagine thestory line possibilities of being able tomorph easily between characters in a game,characters and other objects (such as cars,dinosaurs, or dust clouds), or into a char-acter from a different game altogether.Think about the production time youwould save if you could take a commercial-ly modeled object and morph it with oneyou created. The possibilities are endless,and hopefully just around the corner. q
j u l y 2 0 0 0 | g a m e d e v e l o p e r24
FIGURE 6. Left: Original model modeled in wireframe. Center: Cross-sectional splines of the head.Right: Initial results of Cross Section modifier.
Special thanks to Michael Hultner of Anatomix
(www.anatomix.com) and Kent Suzuki of Right
Brain Electronics (www.rightbrainelectronics.com)
for helpful discussions during the preparation of
this article.
A C K N O W L E D G E M E N T S
A R T I S T ’ S V I E W
Go with
j u l y 2 0 0 0 | g a m e d e v e l o p e r26
A U T H O R ’ S B I O | When he’s
not sitting around radiating potential, Brian’s probably
busy furthering the secret OpenGL agenda. Either
that, or he’s likely doing the same thing he does
every night, Pinky — trying to take over the
world. Send preemptive bribes and/or
tribute to [email protected].
the f low :
I M P L I C I T S U R F A C E S b r i a n s h a r p
w w w . g d m a g . c o m 27
Improving Fluid Rendering Using
Implicit Surfaces
Illustration by Spencer Lindsay. Created with RealFlow In 3D Studio Max
Maybe it’s just me, but itseems like games havealways had something of alove-hate relationship withfluid. We’ve been using
water, lava, and the like for a very long time. Formany years, games such as ULTIMA UNDERWORLD
had 3D-rendered water and lava — rendered asflat, textured planes. At the time, that was animpressive part of a very impressive engine.Today, that engine is objectively obsolete, havinglaid the initial groundwork for today’s flashiestpolygon-pushers.
j u l y 2 0 0 0 | g a m e d e v e l o p e r28
In spite of other advances in game tech-nology, however, the flat-plane approachto water has remained fairly unchanged.Perhaps today the water plane is drawntransparently using an innovative blendmode. Perhaps it’s broken into more poly-gons and jiggled up and down a bit. Butthe underlying technology (or lack thereof)has been the same since the advent of real-time 3D game engines.
It’s a bit of a pet peeve of mine, becausemore advanced fluid rendering opens upthe door to some very cool game-playdynamics. How great would it be if in a3D real-time strategy game you couldflood an enemy base by diverting a riverthrough their valley? Or if your opponent’sbase were hydroelectrically powered andyou built a dam upstream to cut off theriver flow, shutting down his power? Theseare the kinds of advanced interactions thata jiggly plane just can’t offer.
So this month and next, I’ll take a stabat describing one technique for advancedfluid rendering for games. Note that I’mnot the only person who wants betterwater: Jeff Lander has written a fewcolumns on fluid flow, including overviewsof the Navier-Stokes equation and varioussimplifications thereof (“A Clean Start:Washing Away the Millennium,” GraphicContent, December 1999, and “Researchon the Rhine: Reflections on Water Simu-lation,” Graphic Content, January 2000).Rather than build off of that work,though, I’m using a different technique, asurface representation known as implicitsurfaces.
Implicit What?
A n implicit surface can be succinctlydescribed as an isosurface of a real-
valued 3D function. If that doesn’t make itcrystal clear, perhaps an example will help.Imagine a hot coal sitting on the ground,radiating heat outwards. In this case, tem-perature is our real-valued 3D function: atevery point in a 3D space (the room thecoal is in), the temperature is a real num-ber — what your programming languageof choice might call a float.
If you pick a specific temperature value— say, 90 degrees Fahrenheit — and paintevery molecule at that temperature brightred, you’ll end up with a surface that lookssomething like a spherical shell around thecoal. The higher the temperature you pick,the closer that surface will be to the coal.That’s an implicit surface, and the temper-ature you choose is the isovalue. Figure 1shows a number of the isosurfaces in 2D.
The name “implicit surface” is then fair-ly straightforward. It’s a surface becauseit’s a surface, of course, and it’s implicitbecause we don’t have an explicit parame-terization for it; the 3D function and theisovalue imply where the surface is.
And These Are Good For What?
G ranted, it’s not immediately obviouswhat you’d use these isosurfaces for.
After all, how many useful real-valued 3Dfunctions are just sitting around waitingfor you to slap an isovalue on them? It’sworthwhile, then, to take a look at whatisosurfaces are used for in graphics.
One use of implicit surface rendering is
in medical visualization. Data from anMRI scan, for example, provides a sam-pled 3D function of intensity values oversome tissue. The various intensity valueshighlight types of tissues. For example, onemight best highlight bone, whereas anothermight depict cartilage particularly well.Clearly, I’m glossing over quite a bit here.Figure 2 shows a human cortex renderedwith implicit surfaces from MRI data. Formore information on that specific applica-tion, see the For More Information sectionat the end of this article for Paul Bourke’sweb site address. Another use of implicitsurfaces is often referred to as “blobbymodeling.” This is the form of implicit sur-face modeling that’s common to many 3D
FIGURE 1 (top left). A hot coal radiates heat.
Three different isosurfaces are labeled by tem-
perature. FIGURE 2 (bottom left). A human cor-
tex rendered using implicit surfaces (image
courtesy of Paul Bourke). FIGURE 3 (top right).
A character modeled using metaballs/blobby
modeling in Organica (image courtesy of
Impulse Inc.). FIGURE 4 (bottom right). Fluid
flow rendered using implicit surfaces by Real-
Flow (image courtesy of Next Limit / RealFlow).
I M P L I C I T S U R F A C E S
modeling packages, and it also goes bymonikers such as “metaballs” or “blobs.”The basic idea is to define the implicitfunction with primitives such as points,lines, boxes, and other geometric shapes.These primitives radiate potential similarto the coal radiating heat. That way, whenyou place two primitives near each other,their potential fields sum and the surfaceflows smoothly between them. This out-come tends to produce organic or cartoonyresults, and indeed it is good for modelingthings such as organic or balloon charac-ters and clay figures. Figure 3 shows anexample of a character modeled inOrganica (see the For More Informationbox to find details on Organica).
The final use of implicit surfaces is fluid
modeling, which is, not coincidentally, thefocus of this article. The idea is to modelfluid flow through molecular interaction.Using a reduced number of molecules, youtreat each molecule as a point primitive inthe implicit function, just as you wouldpoint primitives in blobby modeling. Thatway, the molecules generate an implicitfunction. If you pick an isovalue that pro-duces a surface of the desired volume andmove the points around using some physi-cal model of molecular interaction, thenvoilà! The technique also scales quite well— turning up the number of moleculesand tightening the isovalue in on the sur-face will produce a higher-quality approxi-mation of the surface. There’s an excellentnon-real-time tool available called Real-Flow, shown in Figure 4. Clearly, sincethis fluid rendering is non-real-time, thenumber of molecules can be cranked upquite a bit.
Hopefully that’s enough to convince youthat implicit surfaces are useful enough tomerit a closer look. Now that you have ageneral overview, let’s dig into the specificsof our implicit surface model.
The Implicit Function
D etails, details... I’ve mentioned howall these points “radiate potential”
and how the potential “sums” to producesmooth surfaces, but I haven’t describedexactly how it’s going to happen. So, I’lldescribe the process step by step to try tokeep everything straight.
To start with, one thing that may causeconfusion is the concept of “potential”
radiating from these molecules. Just whatis potential? Well, it’s really a unitlessvalue and doesn’t represent a meaningfulquantity such as pounds or liters, so per-haps an analogy might help. Think of themolecules as radiating some matter — say,dust — outwards. The dust is very concen-trated near the molecule, but as we moveaway from the molecule, the dust thins outand is much less dense. In this scenario,the potential at a certain distance from themolecule is just the density of the dust.Figure 5a shows a 2D version of this.From there, it makes sense that when weput two molecules near each other, theirdensity fields add up, producing a thickerdust cloud between them, as illustrated inFigure 5b.
However, I haven’t specified at exactlywhat speed the dust thins as it moves awayfrom the point. How to decide? Well, wecan use any function we want; it’s just aquestion of whether it fits our needs. Ouronly real need is for it to look good, whichentails a number of things. We want thefall-off to be at least C0 continuous, ofcourse — that is, it shouldn’t have anyabrupt changes in value — or else the sur-face might not be smooth or it might evenhave open holes.
Since liquids are noncompressible, theideal fall-off function would preserve vol-ume. This means that if we have two mol-ecules, the surface produced when they’refar away from each other should have thesame volume as the surface producedwhen they’re near each other. Unfortunate-ly, this is really hard to do in practice. Infact, there’s no single fall-off function thatwill do this for us. Therefore, you shouldpick a function that keeps the surface vol-ume from changing too abruptly.
There’s actually a fair amount ofresearch that’s been done in this area and anumber of suggested fall-off functionsfrom various authors, but I’ve chosen toeschew the well-traveled path and justmake up a function that looks O.K. Givensome distance d away from the molecule,the value is equal to:
potential dd
( ) = −
max ,01
12
0.0 0.5 1.
pote
ntia
l val
ue
distance from molecule
w w w . g d m a g . c o m 29
FIGURE 5A (top left). A single molecule radiates
potential outwards. FIGURE 5B (top right). Two
molecules radiate potential; the potential fields
sum where they overlap. FIGURE 6 (above). The
potential function, (1/d2) – 1. Past a distance of
1.0 the value is clamped to 0.
A graph of this function is shown inFigure 6. This function has a number ofdesirable characteristics. The first is thatwhile it does require a division, it uses thedistance squared, which you can get froma vector without a square root. (You’ll beevaluating this function so many times atrun time that these kind of low-leveldetails really are significant.)
Another benefit of this function is thatthe potential clamps to 0 at a fixed dis-tance of 1.0 from the molecule. Thismeans that the molecule only influencesthe area within a distance of 1.0 and afterthat it doesn’t have any effect. In nextmonth’s article, I’ll explain exactly howhandy this is, as it allows us to partitionthe molecules spatially, greatly simplifyingthe job of evaluating the implicit function.
To generalize the function for a singlemolecule to a multi-molecule surface, wehave to change the arguments a little. Letp be the point in space for which we wantto evaluate the implicit function. Then letci be the location of the ith molecule(where the total number of molecules is n).Then, the value of the function at p is:
In case you read code more easily thanmath, the equivalent pseudocode for thatfunction is shown in Listing 1.
That’s it for the implicit function. Theonly remaining part of the implicit sur-face representation I haven’t discussed yetis the isovalue, and for good reason:there’s not really much to it. Just pick avalue, and if the resulting surface doesn’tlook good enough, pick some other value.Higher isovalues will tighten the surfacein on the molecules, making the surfaceseem to have a lower surface tension.Lower isovalues will expand the surfaceaway from the molecules and make itlook like it has a higher surface tension.Of course, the higher the isovalue, themore molecules it takes to produce a sur-face of a given volume, so the trick is infinding a good compromise somewhere inbetween.
Rendering
S o far, I’ve covered enough informationthat if someone handed you a bunch
of molecules, you could evaluate theimplicit function defined by those mole-cules at various points in space. That’swonderful, but it doesn’t help much withthe real task at hand, which is renderingisosurfaces of that implicit function.
There are ways to raytrace implicit sur-faces directly; packages such as POV-Ray(www.povray.org) yield pixel-perfect ren-derings of the surfaces. Unfortunately forus, though, consumer-level 3D hardwareisn’t quite up to the level of real-time ray-tracing, or even automatically scan-con-verting implicit surfaces. Therefore, weneed a way to convert our implicit surfaceinto primitives that the hardware canunderstand, namely triangles.
There are a few different algorithms fordoing this. One starts with a rough shell
that contains the surfaceand subdivides the shelluntil it conforms to thesurface within someparticular error thresh-old. My experience withsubdivision surfacessuggests that the subdi-vision process would beprone to lots of memo-ry-thrashing and diffi-cult to optimize.Furthermore, maintain-ing all the connectivityinformation to subdi-vide a mesh is a lot ofconfusing, bug-prone
bookkeeping work. I wasn’t too eager totry that again, so I went with the othercommon method of implicit surface tessel-lation, marching cubes.
Deriving the Vertices:Marching Cubes
T he idea behind marching cubes is fairlystraightforward. After finding a
bounding box for the entire surface, breakthat box into a bunch of smaller boxes tocreate what we’ll call “cubelets.” Marchthrough the cubelets (hence the name“marching” cubes), and for each one poly-gonize the portion of the surface inside thatcubelet. The result is a polygonal approxi-mation of the entire implicit surface.
That’s just an overview, and clearly it’snot much of an algorithm if it doesn’t alsospecify how to polygonize the surfaceinside each cubelet. To do that, you canevaluate the implicit function at each ver-
potential pc pii
n
( ) =−
−
=∑max ,0
11
20
j u l y 2 0 0 0 | g a m e d e v e l o p e r30
FIGURE 7. Example cubelet configurations and resulting polygonizations. Green vertices areinside the surface, red are outside.
LISTING 1. Pseudocode to calculate the potential value at a pointgiven a number of molecules.
potential(Point p){
float totalValue = 0
foreach molecule{
float distance = distanceFrom(molecule center, p)float contribution = (1 / distance^2) - 1if contribution > 0
totalValue += contribution}
return totalValue}
I M P L I C I T S U R F A C E S
tex, which gives you a floating-point value for each vertex.Given those point values andthe isovalue of the surface we’retrying to find, you can classifyeach vertex as either on/insidethe surface or outside the sur-face (treating on and inside asthe same thing). This is done bychecking the function value atthe vertex against our isovalue— if the vertex value is less thanthe isovalue, it’s outside the sur-face; otherwise, it’s inside thesurface. This determines howyou polygonize the cube: the tri-angulation inside the cubeletneeds to separate the interiorvertices from the exterior ver-tices. Figure 7 shows examplepolygonizations for cubes with one, two,and four vertices inside the surface.
Determining the polygonization thatcorresponds to a given configuration ofvertices is somewhat time-consuming.Luckily, there aren’t that many of them.Each vertex of the cube can be either in orout of the surface, which we can representwith a single bit. There are eightvertices in the cube, which brings usto a total of eight bits needed torepresent the surface configurationcompletely. That means that thereare 256 different possible cubeletconfigurations, which can be storedeasily in a lookup table.
From the lookup table, you candetermine along which cube edgesyou need to create vertices, and howto connect those new verticestogether into triangles. What thelookup table doesn’t tell you,though, is where along each edge toput a vertex. Figure 7 simply placesthe vertices halfway along eachedge, but clearly if it were alwaysdone that way it wouldn’t look verygood, especially as the surface ani-mated — vertices would snap all theway from the center of one cubeletto the center of the cubelet next to itas the surface moved through space.
In practice, you linearly interpolate, orlerp, between the corners of an edge inorder to find the new vertex. For an edge,e, you have endpoints v0 and v1. Also, youhave the value of the implicit function ateach of those vertices, so v0 has a corre-sponding floating-point value p0 and v1 hasp1 (p for potential). Then there is the iso-
value t (for threshold). To findthe new vertex, do the following:
ratio = (p1 – t) / (p1 – p0)newVertex =
ratio * p0 + (1 – ratio) * p1
This is the simple linear interpo-lation between the two endpointsand the result is our new vertex.Intuitively, if p1 is lying right onthe surface (so p1 equals t), theratio value is 0, and the new ver-tex is at 0 * p0 + 1 * p1, or p1,just as it should be. If p0 liesdirectly on the surface, the ratiois 1, and the new vertex is at 1 * p0 + 0 * p1, or p0, also as itshould be.
You may be thinking to your-self, “This marching cubes stuffis terrible! The surface isn’t going
to look smooth at all if each cubelet justproduces a couple of triangles!” And that’strue if you don’t use enough cubelets. Ifthe surface does some involved twists andturns inside a single cubelet, they’ll be lostdue to undersampling. It definitely takes alarge number of cubelets to produce agood-looking surface, which is one of the
reasons it’s so important that thecubelet polygonization be very fast.Pseudocode for the whole processof polygonizing a cubelet is shownin Listing 2.
Deriving theNormals
T he marching cubes pass hascreated vertices and faces for
the mesh but if you want to lightor environment-map them, you’llneed normals as well. One possibleway to do that is to actually differ-entiate the implicit function andfind the gradient vector at each ver-tex; the gradient of the function isthe surface normal at a vertex. Un-fortunately, there are a few prob-lems with that.
First, our implicit function isn’tactually differentiable. Recall thatI said you need to clamp the fall-
polygonizeCubelet(vertices[8]){
unsigned char config = 0for n = 0 to 7{
if vertex[n] is outside the surfaceset bit n of config to 1
(otherwise leave it as 0)}
for each edge in edgesNeedingVertices[config]linearly interpolate to find the vertex on that edge
for each triplet of triangle indices in triIndices[config]create a new triangle from those indices using thenew linearly interpolated edge vertices
}
LISTING 3. Pseudocode to calculate both the potential value
and color at a point given a number of molecules.
potential(Point p){
float totalValue = 0Color finalColor = Black
foreach molecule{
float distance = distanceFrom(molecule center, p)float contribution = (1 / distance^2) - 1if contribution > 0{
totalValue += contributionfinalColor += contribution * molecule color
} }
// Normalize the colorfinalColor /= totalValue
return totalValue and finalColor}
w w w . g d m a g . c o m 31
LISTING 2. Pseudocode to polygonize an implicit surface inside a
single cubelet.
off function to 0 in order to limit eachmolecule’s range. That clamp to 0 is afirst-order discontinuity: the function waspointing downwards a bit, and weclamped it to a point directly out along thehorizontal axis. This means that the firstderivative of the implicit function isn’tcontinuous, and you may end up withsome odd artifacts if you try to treat it asthough it were.
Furthermore, even if the function weredifferentiable, the task of actually findingthe gradients is very slow, as it wouldrequire that we walk through the mole-cules again for each normal. Instead, I’vehad good results just making a post-passover the triangles and averaging the facetnormals to generate vertex normals.
This system certainly isn’t perfect. First,the polygonization can often produce tri-angles of very different sizes, placing somelarge triangles next to thin slivers. Second,because we’re only interpolating the ver-tices linearly along cubelet edges, the ver-tices aren’t necessarily exactly on the sur-face — they are just pretty close. This isbecause linear interpolation is only 100percent correct when the function you’reinterpolating is itself linear, which ourimplicit function isn’t. The result is thatthe face normals might have slight errorscompared to those that have face verticeslying on the surface itself.
Averaging the face normals can there-fore introduce some artifacts, and indeedthe final surface usually shows a very faintrippling throughout the normals, presum-ably from these problems. It’s not verynoticeable, though. I’ve tried variousweighting schemes, weighting the face nor-mals so that larger faces contribute moreto the vertex normals, or alternately sothat smaller faces contribute more, but inthe end, weighting all faces equally pro-duced the best visual results.
Deriving the Colors
T here are two parts to vertex colors.You get vertex colors from per-vertex
lighting, which is straightforward sinceyou have the vertices and normals around.
However, there’s also the question ofunderlying surface color — for blood, forinstance, we’d want the surface to be red.So far, I’ve managed to get by with a singlecolor for the entire surface. It would bepossible, though, to give each molecule acolor. During tessellation, whenever evalu-ating the implicit function, I’d track thecontribution of each molecule to theimplicit value and sum up each of theircolors scaled by their contribution. At theend, I’d normalize the color, which pro-duces the final color. When lerping newvertices, the colors would be lerped alongwith the position.
This could be useful for a variety ofeffects. For instance, in an area of riverrapids, you could start molecules as clearand dark blue, and move them slowlytowards opaque and white every time theycollide with something, all the while fadingthem back to clear blue over time. Thatway, very turbulent areas would look likefrothy, white rapids, whereas the calmerwater would be clear and tranquil.
Of course, this comes at a cost. Whereasfinding the normals takes O(V+F) time
where V is the number of vertices and F isthe number of faces, this process couldpotentially take O(VM) time where V is thenumber of vertices and M is the number ofmolecules. This happens if all the moleculesare clustered together; since every moleculecontributes to every vertex, finding thecolor involves doing work for every mole-cule on a per-vertex basis. Listing 3 is amodified version of Listing 1, which alsocalculates interpolated molecule colors.
Deriving the TextureCoordinates
A t first thought, it seems silly to thinkthat any current game engine would
ever render nontextured objects. Thesedays, everything’s textured, usually multi-ple times. But it’s not immediately obvioushow to apply a texture to an implicit sur-face. The vertices are generated completelydynamically, and furthermore, the surfacetopology may change entirely from oneframe to the next.
Of course, this makes sense intuitively— we’re modeling fluid. How would you
j u l y 2 0 0 0 | g a m e d e v e l o p e r34
FIGURE 8. An example implicit surface. A: The molecule points. B: The polygonized surface in wire-
frame. C: The lit, smooth-shaded surface, with vertex normals drawn. D: The lit, smooth-shaded,
environment-mapped surface.
I M P L I C I T S U R F A C E S
apply a texture to a fluid? You certainlycan’t shrink-wrap a texture onto a river inthe same way you usually think of apply-ing textures in modeling packages. Theclosest technique to standard, artist-speci-fied texture coordinates is found in Peder-sen’s “Decorating Implicit Surfaces” (seeFor More Information). He succeeds tosome extent, but the work is distinctly non-real-time and not particularly compatiblewith moving surfaces.
That’s not to say that we can’t textureimplicit surfaces at all. We just can’t applytextures to them in an editor and load themin with the game. We can, however, envi-ronment-map the surfaces, which uses theirnormal vectors to generate texture coordi-nates; I’ve had very good results usingspherical environment maps to simulatestatic reflections. Other possibilities are pro-jective shadows and lighting — a river flow-ing under a tree could have a shadow mapprojected down onto it, which is to say thatit generates texture coordinates based onthe vertex positions. There are other possi-bilities, too — refraction, bump mapping,and many more. Certainly, between all thepossible dynamic texturing effects, slather-
ing the obligatory three or four textures (atleast) should be no problem at all.
Taking a Breather
W e’ve made a fair amount of head-way in this article. At this point,
you should know how to define an implicitsurface using a bunch of points and thefall-off function given earlier. You shouldalso be able to polygonize the surface witha brute-force marching cubes algorithm,brute force meaning that you sample everysingle cubelet in the surface’s bounding boxregardless of whether it contains the sur-face or not. You should be able to find themesh vertices, and for each vertex find anormal and a color, and furthermore youshould be able to generate an assortment oftexture coordinates using OpenGL texture-coordinate generation or some other simi-lar technique. You can also move the pointsaround but we haven’t covered the physicssystem yet, so the resulting animationmight not look much like fluid.
Along with the physics system, otherthings I haven’t dealt with include optimiza-tion: the brute-force marching cubes algo-rithm is painfully slow, as the vast majorityof the cubelets it samples are empty andtherefore end up wasting your time andeffort. For now, a teaser for next month’sarticle: Figure 8 shows a number of render-ings of an example implicit surface.
Next month we’ve got a lot more groundto cover. We’ll start off with a quick reviewof algorithm analysis theory. Armed withthat, we’ll go on to look at optimizationsand enhancements you can make to the tes-sellation system to coax it to run at anacceptable speed. We’ll discuss the physicssystem so that you can move the moleculesaround in a believable and aestheticallypleasing way. From there it’s on to a dis-cussion of the demo, from a developmentwalkthrough to a brief code guide forsome of the stickier parts.
When we finally finish, we’ll have afully featured demo complete with source,binaries, and stunning programmer art-work. Until then, get a head start bybrowsing through the publications in the
References section, searching the web formore information, or even better, codingup a renderer of your own. q
F O R M O R E I N F O R M AT I O N
WEB SITESAuthor’s web sitewww.maniacal.org
Paul Bourkewww.swin.edu.au/astronomy/pbourke
ACM Digital Library www.acm.org/dl
Organicawww.coolfun.com/html/organica.html
POV-Ray www.povray.org
RealFlowwww.realflow.com
PAPERS(All available at the ACM Digital Library web site)
Bloomenthal, Jules, and Keith Ferguson. “Poly-
gonization of Non-manifold Implicit Sur-
faces.” Proceedings of Siggraph ‘95.
pp. 309–316.
Desbrun, Mathieu, and Marie-Paule Gascuel.
“Animating Soft Substances with Implicit
Surfaces.” Proceedings of Siggraph '95.
pp. 287–290.
Froumentin, Max, and Eric Varlet. “Dynamic
Implicit Surface Tessellation.” Proceedings
of the ACM Symposium on Virtual Reality
Software and Technology 1997. pp. 79–86.
Pedersen, Hans Køhling. “Decorating Implicit
Surfaces.” Proceedings of Siggraph '95.
pp. 291–300.
BOOKSCormen, T., C. Leiserson, and R. Rivest. Intro-
duction to Algorithms. Cambridge, Mass.:
M.I.T. Press, 1998.
Bloomenthal, Jules, and others. Introduction
to Implicit Surfaces. San Francisco, Calif.:
Morgan-Kaufmann, 1997.
w w w . g d m a g . c o m 35
Some additional examples of implicit surfaces in
action.
S TAY T U N E D F O R PA R T 2 I N N E X T M O N T H ’ SI S S U E .
L ast month we discussed someof the performance issues fac-ing AGE OF EMPIRES II: THE
AGE OF KINGS (AOK). Idescribed some of the tools
that we used at Ensemble to collect thatdata, including Intel’s VTune, NuMega’sTrueTime, and our own profiling code. Inthis concluding article, I’ll describe how toimprove performance by effectively usingperformance tools and instrumentation.We’ll also look at general types of prob-lems we encountered as we optimized AOKwhich can affect any game. Then we’llwrap things up by taking a look at the lastbastion of getting a game to run on theminimum platform when all else fails: scal-able features.
The Seven DeadlyPerformance Sins
A ll the performance problems AOKencountered fell into one or more of
seven general categories. These problemsranged from executing dead code to ineffi-cient code and they can affect any game.Let’s take a look at these categories.1. Executing dead or superfluous code.Over the course of a long developmentcycle, a lot of code-based functionality iscreated, changed, and/or discarded. Some-times discarded or superceded functionali-ty is not removed from the game and con-tinues to be executed. While it’s a waste ofeffort to optimize code that should beremoved in the first place, it can be diffi-
cult to determine whether a few lines ofcode, a function, or an entire subsystem isgoing unused.
One feature we had envisioned for AOKwas renewable resources, so naturalresources such as trees would increase overtime if they weren’t depleted. After play-testing the game, we found that this featurewould often cause a game to last indefinite-ly, so we eliminated it. Later, when profil-ing game performance, we discovered thatnot all of the code had been removed —the code that controlled tree regrowthappeared at the top of our profiler’s func-tion list, and we quickly removed it.
Unfortunately, superfluous code is notalways so easily found, and often it’s onlywhen the code gets executed enough thatyou spot it on a profiling list. Such was thecase with another problem also related tothe trees in our game.
In our derived unit hierarchy of classes(described in last month’s article), we easilyadded new units to the game by derivingnew classes in the hierarchy. This hierarchyalso is powerful in that functionality can beadded or changed in a single place in thecode to affect many different game units.One such change inadvertently added line-of-sight checking for trees, which is unnec-essary since trees are not player-controlled.This was not an obvious performance prob-lem and it was found only through loggingdata and stepping through code while tryingto make the line-of-sight code faster.2. Executing code too much. Trees, wallsegments, and houses were often indicators
of general performance issues in AOK,given the large amount of them on maps— some AOK maps contain more than15,000 trees. In order to process theseunits quickly, we created shortcuts in vari-ous derived functions within the unit hier-archy to avoid unnecessary unit process-ing. This became very complicated in somecircumstances, since the computer playeruses walls and houses as part of their lineof sight. If it weren’t for the differencesbetween the way computer and humanplayers used these units, the wall andhouse special processing would have beensimpler. But the player’s ability to use thebuildings to scan for enemies made our AIprocessing simpler and more effective.
Pathing was another system that wespent a lot of time optimizing so that itwouldn’t execute for too long. To do this,we capped the number of times the path-finding system could be executed to a fixednumber of iterations per unit per gameupdate. When trying to optimize a pathingsystem by capping its execution, you haveto balance the desire to limit CPU usagewith the desire to not make players thinkthe units exhibit dumb behavior wheninstructed to move or attack. This forced usto tweak the game a great deal to achievethe right balance between playability andspeed, but that’s often the trade-off you facewhen optimizing a game.
We tried a variety of caps to optimizethe pathfinding system, and it was deter-mined that at five or more pathingattempts, units attempting to retarget were
Profiling, Data Analysis, Scalability,and Magic Numbers, Part II
Using Scalable Features and Conquering The Seven Deadly Performance Sins
j u l y 2 0 0 0 | g a m e d e v e l o p e r36
P R O F I L I N G & A N A L Y S I S h e r b m a r s e l a s
A U T H O R ’ S B I O | Herb Marselas currently works at Ensemble Studios. He helped out on AGE OF EMPIRES II: THE AGE OF KINGS. Shhhh!Please don't tell anyone he's working on a secret 3D-engine project called [deleted]. Previously, he worked at the Intel Platform ArchitectureLab where he created the IPEAK Graphics Performance Toolkit. You can reach him at [email protected].
the most responsive to the player. Fiveattempts were too many for the minimumplatform, and we decided that two pathingattempts were too few based on the resultsof play-testing. We ultimately decided tocap the number of pathing attempts atthree, once again based on our desire tobalance playability with usability.
We also placed execution caps on othersystems to improve performance. Theseincluded the number of pathing attemptsmade by a player’s units, the amount oftime the computer player could spendthinking during each game update, and thenumber of targets a unit could look forwhen retargeting.3. Using inappropriate algorithms. Whilethe pathing system in AGE OF EMPIRES wasa good general purpose system, it brokedown in some specific circumstances (asdiscussed last month). Also, there werenew performance issues raised by AOK,including a larger number of units andlarger maps to path across.
We could have continued to attempt tooptimize the single-pathing system, but itwas obvious from the work performed on
AOE that enough requirements hadchanged so that the algorithm could nolonger stand on its own. What had been agood algorithm for AOE had become aninappropriate algorithm for AOK due tonew and changing pathing requirements.
The AOE pathing system was used topath units from one general area to anoth-er over short distances in AOK. Newpathing systems were added to path unitsquickly across the game map and to pathunits accurately within short distances.Also, as part of the new pathing system, anew unit obstruction manager (see Pottin-ger in the For More Information section)was added for detecting unit collisionsduring pathing.4. Encountering exceptional data. Built forefficiency from the start, the unit obstruc-tion manager surprised us when it was iden-tified by our performance profilers as one ofthe top problems. After reviewing the codeto look for obvious (or not obvious) prob-lems, we added instrumentation code thatcatalogued how units and their locationswere stored within the quadtree.
With this logging code in place, we
quickly saw that the majority of unitsplaced in the quadtree ended up being notin the leaf nodes, but higher up in thequadtree branches. We also discovered thatunits touching the edge of a tile were inter-preted as spanning two tiles, which causedperformance problems. By bumping unitsback onto the proper tiles, we immediatelysaw a 300 percent performance boost inobstruction manager performance.
This code, as is most code, was writtenbased on assumptions about the data. Pro-grammers assume that the data processedby a function is of a certain type and willfall within certain limits or into certainsets. When data fell outside these expecta-tions, our algorithm — which would oth-erwise have performed well — was identi-fied as a performance problem.
Some sections of the game were instru-mented from the very outset of develop-ment to help diagnose data processingproblems that arose frequently in thosesections of code. The unit AI, for instance,contained conditional #define statements tolog approximately 50 different sets of per-formance information. These performance
w w w . g d m a g . c o m 37
TOP. Briton Dark Age, Castle Age, and Post-Imperial Age towns. Western European building set.BOTTOM. Viking Dark Age, Castle Age, and Post-Imperial Age towns. Eastern European building set.
monitors could be used alone or in variouscombinations to help resolve performanceissues related to data processing.5. Inefficient memory usage. Poor per-formance can be caused by data structuresthat are not cache-line aligned, randomaccess to main memory, using too muchmemory, allocating memory, and datadependencies. In AOK, memory problemscould be especially severe since multiplayergames can last six hours or more, duringwhich time tens of thousands of units canbe created and destroyed.
Many data structures in performance-critical areas were compacted to fit in mul-tiples or fractions of cache lines to improvememory access. There were also otherareas that could have been improved by re-arranging data in structures of arrays, orstreams (see For More Information sec-tion), but this would have made the codeeven more complicated.
To analyze and improve the memoryusage of AOK, we used a number of differ-ent tools. The first tool that was a tremen-dous help was the set of Windows NT per-formance counters, which we used toexamine memory statistics quickly. TheNT performance counters provided a widearray of data about an application, includ-ing processor, process, memory, and net-work statistics. In the case of AOK, themost important memory statistic wasPrivate Bytes, the amount of nonsharedmemory allocated for the AOK process.
By sampling the memory footprint atspecific intervals, we created a generalpicture of the game memory footprint(Figures 1a and 1b). Since the game’smemory requirements are effectively thesame across Windows NT and Windows98, the NT performance counters helpedus examine how memory was used duringa four-player game on the minimum spec-ified player’s system. This was key tohelping us determine if AOK would fitwithin the minimum target memory sizeof 32MB.
Given the minimum system gamerequirements (Figure 2), we estimated thata game should typically last about 45 to60 minutes. In the four-player game exam-ple shown in Figure 1a, about 21MB ofmemory was allocated by the game uponstart up. Thirty minutes into the game,memory usage rises to around 23MB.
In contrast, look at the memory footprintof the eight-player game shown in Figure1b. The addition of more players to thegame requires more memory for their dataat startup, as well as more memory to sup-port the larger game map. The amount ofmemory consumed continues to grow dur-ing the game as more units and buildingsare created until a plateau is reached. Afterreaching that plateau (not shown), thememory footprint starts tapering backdown. The receding memory footprintoccurs as players and units are defeated.
While these high-level memory statisticsfrom the NT performance counters arequick and useful, often it’s necessary todrill down to see which specific functionsare allocating memory. To get that infor-mation, we created a simple memoryinstrumentation system to track memoryallocations (see Listing 1, pages 42–43).The memory allocation code tracked allo-cations and de-allocations by memoryaddress, number of bytes requested, andfile name and line number of the actualfunction call. It also provided a runningcount of the number of allocations and de-allocations, and the bytes of memory allo-cated in each game update loop.
The sheer number of memory allocationschemes used in AOK complicated ourmemory analysis. AOK uses the C++ new
and delete operators; C library malloc, free,and calloc functions; and Win32GlobalAlloc, GlobalFree, LocalAlloc, andLocalFree functions. In the future, we willbe actively restricting ourselves to a subsetof these functions.
To reduce memory fragmentation andeliminate overhead caused by allocatingand de-allocating memory, memory pool-ing was used in many subsystems. Whilethis significantly increased performance, itdid create problems when trying to fixbugs where code referred to recycled data.
In an attempt to improve performancefurther, we utilized MicroQuill’s SmartHeapto manage memory in release builds. (Wewere unable to use it in debug builds due toincompatibilities with interactive debug-ging.) In the final analysis, the performancebenefit of SmartHeap over the standardheap manager wasn’t clear to us, due to theefforts we made to reduce and pool memo-ry allocations.
After profiling performance and memo-ry usage, it turned out that the most per-formance-limiting factor in AOK could bethe Windows 95/98 virtual memory sys-tem. Unlike Windows NT/2000, Windows95/98 doesn’t require or configure a fixed-size swap file for virtual memory. To makematters worse, the swap file can grow andshrink as a program runs. An expert user
j u l y 2 0 0 0 | g a m e d e v e l o p e r38
FIGURE 1A. Four-player game memory usage over time.FIGURE 1B. Eight-player game memory usage over time.
4 Player Starting
8 Player Starting
8 Player 30 minutes
8 Player 60 minutes
4 Player30 minutes
40
35
30
25
20
15
10
5
0
����
Mem
ory
(MB
)
Figure 1A Figure 1B
P R O F I L I N G & A N A L Y S I S
can create a swap file of fixed size, but it’snot something the vast majority of userscan do or should have to worry about.
AOK relies on the virtual memory sys-tem to handle the growing footprint ofgame data over time within the game. Italso uses multiple read-only memory-mapped files to access game graphics andsounds residing in large aggregatedresource files. These memory-mapped filesranged in size from 28MB to 70MB. Sincethe amount of virtual memory availablecan vary so widely on a user’s Windows95/98 system, this ended up being thenumber one AOK performance issuebeyond our control. It should be notedthat this virtual memory problem didn’teffect every minimally configured system.Virtual memory problems in Windows95/98 seemed to occur just on certain sys-tems, even when identically configured sys-tems performed with little or no problem.6. Inefficient code. Rewriting inefficientcode is likely the most well known perform-ance optimization, but it was typically thelast resort to fix our performance problems.In many cases, the performance problemwas resolved by identifying and fixing oneof the previously mentioned deadly sins.
The easiest place to attempt to improveinefficient code is with the compiler opti-mization settings. Due to the size of AOK,we chose to compile release builds with thedefault “maximize speed” setting for allmodules. This may cause some code bloat(since speed is favored over size), but ingeneral it’s a good choice. We chose not touse “full optimization” since we’ve seenfew programs that could run after using it.
Since shipping AOK we’ve been lookingat the performance benefits of compilingwith “minimize size” and then using #pragma(or module settings) to optimize specifichotspots for speed. This seems to be a bet-ter trade-off than just using the single speedoptimization setting for everything.
In AOK we chose to use the “only_inline” option in Visual C++, instead ofinlining “any suitable” function. This letus choose which functions to inline basedon their appearance in the profile list.Inlining any suitable function would mostcertainly increase the code size and lead toslower performance.
Using an alternate compiler, such asIntel’s C/C++ compiler, to optimize one or
more performance-intensive modules isalso another way to realize some addition-al performance gains. We decided againstthis for AOK, however, because of the riskassociated with changing compilers (oreven compiler versions) near the ship date.7. Other programs. One of the greateststrengths of Microsoft Windows is its abil-ity to preemptively run multiple programsat the same time. However, it can be ahuge drawback when programs that theuser is unaware of take CPU time awayfrom a game or cause the game to lock up.For instance, during the play-testing phaseof AOK’s development, we received reportsof problems that we couldn’t reproduce onour own systems. Sometimes these issueswere caused when the game entered anunstable state, but often other programsrunning in the background on the tester’scomputer caused the reported problems.
Virus scanners and other programsspontaneously running in the backgroundwhile a tester was playing AOK were themost widespread cause of externallyinduced performance problems. Unfortun-ately, there’s no way to easily and ade-quately interrogate a player’s computerand warn them about potential problemsthat other programs can cause.
The most severe issue related to otherprograms involved the Windows CriticalUpdate Notification. Play-testers sometimesreported input lock ups during game playfor no apparent reason. We accidentally dis-covered that when AOK was in full-screenmode, the Critical Update Notificationcould pop up a dialog box behind AOK.This would take the focus off AOK andmake it appear to players as if the game hadstopped accepting input. Changing AOK tohandle situations like this was relativelyeasy once the problem was identified. Otherapplications likely cause similar behavior tooccur, but it’s only by trial and error thatthese problems are identified.
Better Performance ViaScalable Features
W hen we had finally squeezed asmuch performance as we could out
of AOK for the minimum platform, we
w w w . g d m a g . c o m 39
Dark Age village.
FIGURE 2. AOK minimum system game specifications.
• 4 players; any combination of humanand computer players
• 4-player map size• 75-unit population cap• 800×600 resolution• Low-detail terrain graphics quality*
*added as part of scalability effort
were still left with a performance deficit inthe area of terrain drawing. We couldn’tmake the feature optional since playersneed to see the terrain, yet we couldn’tmake it any faster, either. The only alterna-tive was to provide different implementa-tions of terrain drawing or different levelsof terrain detail.
We decided to offer three different ter-rain detail settings: a fast algorithm withlow detail for the minimum platform, amedium detail (but slower) one for mid-range platforms, and a high detail (slowerstill) for high-end platforms. This allowedAOK to run on a lower minimum plat-form, but still give the user on the highend additional visual quality to look for-ward to. This was a tactic used for a num-ber of features in AOK.
Scalable features least likely to confusethe player are those that fit directly intothe context of the game, such as the num-ber of players or the game map size. Intotal, there were six scalable features, fourof which fit the game context. In the game,these are not called “scalable features,”but “game options” (Figure 3). Theseoptions are as follows:Number of players. The simplest scalablefeature within AOK is the number of com-puter-controlled or human opponents orallies that a person chooses play with,which is up to eight players per game. Themore players, the higher the performancerequired by each player’s system. Up to fourhuman or computer-controlled players canplay on a minimum-specified system.Map size. Related to the number of playersis the size of the map. The map size isexpressed in terms of numbers of players(for example, two-player map, four-playermap, and so on). The number of playerssupported by a specific map size was deter-mined by the distance that our gamedesigners felt should be between playerstarting positions. But map size is inde-pendent of the number of players, so youcan have a two-player game on a big eight-player map. This gives players the choiceto accept our recommendations, spacethemselves out further, or squeeze intighter. Based on our choice of four playersfor the minimum platform, the defaultmap size is for four players.Population limit. The unit population capsets the maximum number of units the
player can build during a game. By default,this value is 75, but it can range between25 and 200 units. Again, the user does notsee this as scalability, but as a tweakableoption for creating the perfect game. Wechose to make 75 units the default popula-tion cap because game performance on theminimum platform degrades too much atthe next higher population limit. Different artwork. In addition to thesescalable game options is also an implied,
but generally unrealized, scalability inAOK’s art assets. Each of the 13 civiliza-tions in AOK is assigned to one of four setsof building art. Each building art set repre-sents the area of the world where the civi-lization is from. For example, the Japaneseuse the Asian building art set and theBritons use the Western European buildingart set. There are also Eastern Europeanand Middle Eastern art sets. These art setsnot only have their own styles, each also
j u l y 2 0 0 0 | g a m e d e v e l o p e r40
NUMBER OF PLAYERS: 2 to 8, in any combination of human or computer
SIZE OF MAP: 2 to 8 player sizes and “giant” size
UNIT POPULATION CAP: 25 to 200 units per player
CIVILIZATION SETS: Western European, Eastern European, Middle Eastern, Asian
RESOLUTION: • 800×600
• 1024×768
• 1280×1024
THREE TERRAIN DETAIL MODES: • High detail — multi-pass, anisotropic filtering, RGB color
calculation
• Medium detail — multi-pass, fast lower-quality filtering, RGB
color calculation
• Low detail — single pass, 8-bit color lookup
FIGURE 3. Game play and feature scalability.
Briton Wonder fortified by bombard cannon towers.
P R O F I L I N G & A N A L Y S I S
has different styles of buildings for each of the four evolutionaryages in AOK: Dark Age, Feudal Age, Castle Age, and ImperialAge. In other words, an Asian Dark Age house looks differentfrom an Asian Feudal Age house, or an Asian Castle Age house.
This “upgrade” of buildings within each art set as the agesprogress creates an interesting memory allocation curve. In thebeginning of the game, all the players use the Dark Age versionof their particular art set. As the game progresses, playersadvance through the ages at different rates. Since the advance-ment to the next Age causes the building style to change for theplayer, new art must be loaded and displayed. This increase inmemory allocation continues until all players again reach thesame age.
Assuming all players start in the Dark Age and survive to theImperial Age, the memory allocation exhibits bell curve behavior.The worst case is when there is a player in each of the four Agesat the same time, which sometimes happens in the middle of agame. If all the players in an eight-player game select civilizationsfrom different art sets, they use at least twice as much memory asif they had chosen civilizations from the same art set.Display resolution. This, along with the terrain detail (which isexplained in a moment), is one of two scalability options withinAOK that is outside the scope of the game’s design concept. Thedefault display resolution is 800x600, and can scale up to1280x1024. Again, the lowest resolution was chosen for the mini-mum system.Terrain detail. A terrain detail setting was introduced to reducethe amount of processor time required to draw 2D isometric ter-rain on slower computers by reducing the visual quality. Threelevels of terrain detail are provided. The terrain highest detail set-ting uses multiple rendering passes, anisotropic filtering, and RGBcolor to bring out the best detail. The medium-detail settingreplaces anisotropic filtering with a lower quality but faster filter;the low-detail setting uses flat shading and an eight-bit colorlookup table similar to the terrain in the original AOE. No matterwhich terrain detail setting is used, the final display output onlyuses 256 colors.
The choice of which level of terrain detail to display is madeautomatically by AOK the first time it runs. Since all rendering isperformed on the CPU, this decision is made quickly by using atest that gauges the CPU speed. Players can change the settinglater using an in-game menu.
Unfortunately, scalable features that fall outside of the gamedesign (such as the last two options above) are less likely to beunderstood by players. This lack of understanding can lead play-ers to change settings, resulting in a negative impact on their gameexperience without them realizing what they did, and leave themunable to restore the original settings.
Key Lessons
A fter analyzing and improving the performance of AOK, ourteam learned some essential lessons that we hope to use to
improve the quality and performance of our future products. We hope it will improve your future games, as well. Theselessons are:
j u l y 2 0 0 0 | g a m e d e v e l o p e r42
LISTING 1: A simple memory instrumentation system from AOK.
//================================================================// memory.h header//================================================================extern "C"{void *mymalloc( size_t size, const char *pfilename, const longdwline);void myfree( void *memblock, const char *pfilename, const longdwline);};//================================================================#ifdef _INSTRUMENTMEMORY#define malloc DEBUG_MALLOC#define free DEBUG_FREE#endif
#define DEBUG_MALLOC(size) mymalloc(size, __FILE__, __LINE__)#define DEBUG_FREE(block) myfree(block, __FILE__, __LINE__)//================================================================#ifdef _INSTRUMENTMEMORY void MemoryInit(void);int MemorySave(void);void MemoryUpdate(void);#else#define MemoryInit#define MemorySave#define MemoryUpdate#endif//================================================================// eof: memory.h//================================================================
//================================================================// memory.cpp//================================================================#include <windows.h>#include <stdio.h>#include <io.h>// !!! DO NOT include memory.h header file here !!!//================================================================static FILE *pmemfile, *pupdatefile;static bool binitialized = false;//================================================================static DWORD gdwAllocCount;static DWORD gdwByteCount;static DWORD gdwDeletions;static DWORD gdwFrameCount;//================================================================void MemoryInit(void);//================================================================void MemoryUpdate(void){
if (pupdatefile){
fprintf(pupdatefile, "%lu\t%lu\t%lu\t%lu\n", gdwFrameCount, gdwAllocCount, gdwDeletions,
gdwByteCount);
P R O F I L I N G & A N A L Y S I S
• Obtain objective performance information.• Don’t leave performance issues until the code’s completely
done. Work to improve it throughout the course of the project.• Don’t fall prey to the Seven Deadly Performance Sins.• Create a saved game, scenario, and/or recorded game system
to capture performance workloads.• Make performance statistics easy to collect, see, and use.• If performance statistics aren’t easy to use, they won’t be
used.• Set performance targets. If you don’t know how far you
should go, how do you know when you’ve gotten there?• Use a single memory allocation scheme.• When all else fails, create scalable versions of features. q
w w w . g d m a g . c o m 43
ACKNOWLEDGEMENTS
Creating and optimizing AOK was a team effort. I’d like to thank the AOK
team, and specifically the other AOK programmers for their help in get-
ting the details of some of that effort into this paper. I’d also like to
thank everyone at Ensemble Studios for reviewing this paper.
F O R M O R E I N F O R M AT I O N
Ensemble Studioswww.ensemblestudios.com
Intel VTune and C/C++ Compilerdeveloper.intel.com/vtune
MicroQuill HeapAgent and SmartHeapwww.microquill.com
NuMega TrueTimewww.numega.com
Performance Analysis and Tuning
Baecker, Ron, Chris DiGiano, and Aaron Marcus. “Software Visualization
for Debugging.” Communications of the ACM (Vol. 40, No. 4): April
1997.
Marselas, Herb. “Advanced Direct3D Performance Analysis.” Microsoft
Meltdown Proceedings, 1998.
Marselas, Herb. “Don’t Starve That CPU! Making the Most of Memory
Bandwidth.” Game Developers Conference Proceedings, 1999.
Pottinger, Dave. “Coordinated Unit Movement.” Game Developer
(January and February 1999).
Shanley, Tom. Pentium Pro and Pentium II System Architecture, 2nd ed.
Colorado Springs, Colo.: Mindshare Inc., 1997.
gdwDeletions = 0;gdwAllocCount = 0;gdwByteCount = 0;gdwFrameCount++;
}} // MemoryUpdate//=================================================================extern "C" void *mymalloc( size_t size, const char *pfilename,const long dwline){
RGEMemoryEntry entry;gdwAllocCount++;gdwByteCount += size;void *p = malloc(size);if (!binitialized)
MemoryInit();if (pmemfile)
fprintf(pmemfile, "malloc\t0x%X\t%ld\t%s\t%ld\n", p, size,pfilename, dwline);
return p;} // mymalloc//=================================================================extern "C" void myfree( void *memblock, const char *pfilename,const long dwline){
RGEMemoryEntry entry;gdwDeletions++;if (!binitialized)
MemoryInit();if (pmemfile)
fprintf(pmemfile, "free\t0x%x\t\t%s\t%ld\n", memblock,pfilename, dwline);
free(memblock);} // myfree//=================================================================void MemoryInit(void){
if (binitialized)return;
pmemfile = fopen("c:\\memory-alloc.txt", "wb");pupdatefile = fopen("c:\\memory-update.txt", "wb");if (pmemfile)
fputs("type\tptr\tbytes\tfilename\tline\n", p);if (pupdatefile)
fputs("frame\tallocations\tdeletions\ttotal bytes\n", p);binitialized = true;
} // MemoryInit//=================================================================int MemorySave(void){
fclose(pmemfile);fclose(pupdatefile);pmemfile = 0;pupdatefile = 0;return 0;
} // MemorySave//=================================================================// eof: memory.cpp//=================================================================
W hen Nihilistic Soft-ware was foundedin 1998, there wereonly two things weknew were certain.
The first was that we wanted to form acompany with a small number of veryexperienced game developers. The secondwas that we wanted to make a killer role-playing game.
Nihilistic got started without much fan-fare, just a few phone calls and e-mails.After finishing work on JEDI KNIGHT forLucasArts, the core team members had, forthe most part, gone their separate waysand moved on to different teams or differ-ent companies. About eight months afterJEDI KNIGHT shipped, various people on theoriginal team began to gravitate togetheragain, and eventually formed Nihilistic justa few exits down Highway 101 in MarinCounty, Calif., from our previous home.
Having moved into our new offices andbolted together a dozen desks from Ikea,our first project was to build a 3D RPGbased on White Wolf’s pen-and-paper fran-chise, Vampire: The Masquerade. Beforelinking up with Activision as our publisher,Nihilistic president Ray Gresko alreadyhad a rough design and story prepared foran RPG with similar themes and a dark,gothic feel. After Activision approached usabout using the White Wolf license, weadapted parts of this design to fit theWorld of Darkness universe presented inWhite Wolf’s collection of source books,and this became the initial design forREDEMPTION.
Because of our transition from first- andthird-person action games to RPGs, weapproached our first design in some uniqueways. Many features that are taken for
granted in action games, such as a rich true3D environment, 3D characters, and theability for users to make add-ons or modi-fications, were reflected in our project pro-posal. We also adopted many conventionsof the FPS genre such as free-form 3Denvironments, ubiquitous multiplayer sup-port, and fast real-time pacing. To this weadded the aspects of traditional role-play-ing games that we found most appealing:a mouse-driven point-and-click interface,character development, and a wide varietyof characters, items, and environments forexploration.
Using the White Wolf license also meantthat our users would have high expecta-tions in terms of story, plot, and dialoguefor the game. It’s a role-playing licensebased heavily around dramatic storytelling,intense political struggles, and personalinteraction. Fans of the license would notaccept a game that was mere stat-buildingand gold-collecting.
In keeping with our basic philosophy,we built up a staff of 12 people over thecourse of the project’s 24-month develop-ment cycle. The budget for the game wasfairly modest by today’s standards, about$1.8 million. The budget was intentionallykept low for the benefit of both Nihilisticand our publisher. We wanted our firstproject to be simple and manageable,rather than compounding the complexitiesof starting a company by doing a hugefirst project. Also, we were looking tomaximize the potential benefits if thegame proved successful. For its part,Activision was new to the RPG marketand was testing the waters with RPGs andthe White Wolf license in particular, sothey probably considered the venture fair-ly high risk as well.
Nihilistic Software’s VAMPIRE: THE MASQUERADE — REDEMPTION
j u l y 2 0 0 0 | g a m e d e v e l o p e r44
G A M E D A T APUBLISHER: Activision
FULL TIME DEVELOPERS: 12CONTRACTORS: 8
BUDGET: $1.8 millionLENGTH OF DEVELOPMENT: 24 months
RELEASE DATE: June 2000PLATFORMS: Hardware-accelerated PC
HARDWARE USED: Intel and AMD PCs,Nvidia and 3dfx 3D accelerators
SOFTWARE USED: Alias|Wavefront Maya,Photoshop, QERadiant,
Visual C++TECHNOLOGIES: 3D skinned characters,
continuous level-of-detail,custom-built 3D engine,
MP3 audio compression,lip synching
LINES OF CODE: 300,000 for game,66,000 lines of Java for scripts.
P O S T M O R T E M r o b e r t h u e b n e r
A U T H O R ’ S B I O | Robert Huebner is a co-founder and lead programmer at NihilisticSoftware, an independent game developer located in Marin County, Calif. Prior to working onVAMPIRE: THE MASQUERADE, he contributed to several other game projects including JEDI
KNIGHT: DARK FORCES 2, DESCENT, and STARCRAFT. Robert is on the advisory board for theGame Developers Conference and has presented a number of sessions there, as well as atSiggraph and E3.
w w w . g d m a g . c o m 45
ABOVE. Professional conceptual art, suchas this rendering of Alessandro Giovanniby contractor Patrick Lambert, helped thecharacters evolve as the art design tookshape.
Development started around April1998. When we began, we examined sev-eral engine technologies available, such asthe Unreal engine and the Quake engine,but ultimately decided against licensingour engine technology. The game we envi-sioned, using a mouse-driven, point-and-click interface, had a lot more in commonwith games such as STARCRAFT than eventhe best first-person engines. We decidedto create a new engine focused specificallyon the type of game we wanted to create,and targeted 3D-accelerated hardwarespecifically — bypassing the tremendousamount of work required to supportnonaccelerated PCs in a 3D engine. As anadded benefit, the company would ownthe technology internally, allowing us toreuse the code base freely for future proj-ects or license it to other developers.
What Went Right
1.Letting the artists and design-ers pick their tools. With such a
small team and tight budget, boosting theteam’s efficiency was our primary focus.If bad tools or art paths slowed downprogress in the art or level design depart-ments, we would have no chance of hit-ting our milestones. When we started tomap the development project, the pro-grammers gravitated toward using apackage such as 3D Studio Max for bothart and level design. Ourargument was that doingeverything in a single pack-age would increase porta-bility of assets between lev-els and art, and save thecompany money by licens-ing a single, relatively inex-pensive tool. Thankfully,however, our leads in theseareas strongly objected tothis plan. They argued forallowing each departmentto use the tools thatallowed them to do theirwork most efficiently. Thissingle decision probablyaccounted for more timesaved than any other.
The level designers citedQERadiant as their tool ofchoice, since most of them
had previously done work with id Soft-ware on QUAKE mission packs. id was gen-erous in allowing us to license theQERadiant source code and modify it tomake a tool customized to our 3D RPGenvironments. Because QERadiant was afinished, functional tool even before wewrote our own export module, the leveldesigners were able to create levels for thegame immediately, even before an engineexisted. And since QERadiant stores itsdata in generic files that store brush posi-tions, the levels were easily tweaked andre-exported as the engine began to takeshape. If the level designers had spent thefirst six months of the project waiting forthe programmers to create a level editingtool or learning how to create levels in a3D art tool, we would not have been ableto complete the more than 100 level envi-ronments in 24 months with just threedesigners.
On the art side, lead artist MaartenKraaijvanger lobbied hard for the adop-tion of Alias|Wavefront tools for 3D art.We tried to convince him that a lessexpensive tool would work just as well,but in the end we decided to allow the artdepartment to use what they felt would bethe most efficient tool for the job. SinceMaya was just being released for WindowsNT at that time, the costs of using thattoolset were not as great as we feared, andit allowed the artists the produce an
incredible number of 3D art assets for theproject. During the 24 months of the proj-ect, an art department of four people pro-duced nearly 1,500 textured models, amind-boggling figure using any tool.
2. Small team, one project, oneroom. When we started Nihilistic,
we had a theory that a small number ofhighly experienced developers would beable to produce a title more efficientlythan a larger team with fewer battle scars.In my experience, successfully delivering agame is less about what you do and moreabout what you choose not to do. Mostgames that ship late do so because thedevelopment team went down one or more“blind alleys” — development ideas orstrategies that for whatever reason didn’tpan out, and the work done in that direc-tion is lost. As a small team on a tightbudget, we could not afford to lose valu-able time on these diversions. Experiencedteam members have the wisdom to lookdown a particular path and recognizewhen it’s a likely dead end.
Developers that have shipped commer-cial titles also know when “enough isenough,” so to speak. There is a rampantproblem in this industry of feature creep,when games end up trying to be all thingsto all people, and wind up taking fouryears to complete. Seasoned developersknow that shipping a title is all about
compromise. Any title thatgoes out the door couldalways be “just a little bet-ter” and developers, everthe perfectionists, are neverfully satisfied with the boxon the shelf. Creating a suc-cessful game that ships ontime requires the disciplineto draw that line and moveon to the next challenge.
We also knew that wewanted an office environ-ment where all the teammembers were in a singleroom without any walls,doors, or offices whatsoev-er. This didn’t really seemlike a radical decision —many of us got our startworking for teams thatoperated like this — but it
j u l y 2 0 0 0 | g a m e d e v e l o p e r46
P O S T M O R T E M
Locations included both interior and exterior cityscapes, allowing dramatic situa-tions such as this battle atop a clock tower in medieval Prague.
seems like these sorts of companies arebecoming less and less common in today’sindustry. My first game job was workingat Parallax (now Volition) software. Wewere eight people sitting along one wall ofa narrow office space in Champaign, Ill.Even the original DARK FORCES develop-ment team was sequestered in a one-roomstudio in a building separate from most ofthe other LucasArts teams. This type ofenvironment doesn’t just foster, but ratherforces communication between all parts ofthe team. For instance, a programmer canoverhear a discussion between two artistsabout how to proceed with something andbe able to jump in with an answer thatwill save the project days or months ofwork. This sort of thing happens on adaily basis; artists correct missteps by thetechnology team before they are made, alevel designer can immediately show a bugto a programmer, and so on. Each of theseincidents represents hours or days of proj-ect time saved. In an office environmentwith walls and doors, most of these situa-tions would go unnoticed or unaddressed.
3. Using Java as a scriptingengine. We knew from the start
that allowing the user community to editthe game was an important part of thedesign. After working in the first-personaction-game market, we saw the benefitsof supporting the user community andwanted to carry this idea over into role-playing games, where it is not the norm. Abuilt-in scripting system makes a gameengine much more extendable by fans. InJEDI KNIGHT, we created our own cus-tomized game language called COG. Cre-ating COG took a lot of effort from thedevelopment team; several months of workwent into creating the compiler, testing thegenerated code, and implementing the run-time kernel used to execute the scripts. Theend result was worth it, but it cost a lot interms of time and resources to pull it off(for more about COG, see my article,“Adding Languages to Game Engines,”September 1997).
When starting VAMPIRE, we looked forways to incorporate a scripting enginemore easily than creating our own fromscratch yet again. There were severalscripting systems we examined and tested.At about that time, another game develop-
w w w . g d m a g . c o m 47
TOP. The ambitious design included parties of up to four 3D characters, each with interchangeableweapons and armor.BOTTOM. A set of four interactive 3D head models at the bottom of the screen are skinned and ani-mated in real time to give lifelike status for each party member.
ment company, Rebel Boat Rocker software, was getting a lot ofattention for its use of Java technology. After exchanging a few e-mails with lead programmer Billy Zelsnak, we decided to giveJava a try. Up to this point I knew very little of Java, and hadlargely dismissed it as a language suitable only for making iconsdance on a web page and the like.
After a crash course in Java, we did a few simple tests incorpo-rating it into our game engine. It passed each one with flying col-ors. In a matter of a few weeks, we had solved the major chal-lenges involved in interfacing a standard, freely distributable Javavirtual machine to our 3D RPG engine. From that point on, theonly maintenance required was to add new native functions to thescripting language, which we did whenever we added new enginefunctionality that we wanted exposed to the script writers. Wealso trained several designers in the use of the scripting language,and they started creating the hundreds of small scripts that wouldeventually drive the storyline of the game.
Ever since those initial tests, I kept waiting for the other shoeto drop, so to speak. I expected to come to work one day andfind out that the Java thread was chewing up 100MB of RAM oreating 50 percent of the CPU time, but amazingly, the system wastrouble-free throughout development and never became a signifi-cant resource drain. If for some reason we had hit a dead endwith the Java system late in the project, it would have easilytaken three to four months to get back on track using a differentscripting technology. In the end, the gamble paid off. We savedmonths of programmer time that would have otherwise beendevoted to creating a scripting environment, and the result was asystem significantly more efficient and robust than any we couldhave created ourselves.
4. Storyteller mode. Throughout the project, the designslowly took shape through a series of meetings that
involved the entire staff. Each new design element was presentedto the group and subjected to a (sometimes heated) discussion.This process of open discussion and free exchange of ideas result-ed in a lot of the most interesting design aspects of the game.
It was in one of our earliest design meetings that we came upwith the idea of developing the multiplayer aspect of the gamenot as a typical deathmatch or cooperative system, but rather tocreate a “storyteller” or “dungeon-master” system. The idea wasinspired by the venerable text-based multi-user dungeon (MUD)games that date from a calmer time in the history of the Internet.Many of us at Nihilistic had played MUDs in college, often to thedetriment of our studies. One thing that made MUDs so appeal-ing was the ability for “wizards,” high-ranking users of theMUDs, to manipulate the game environment and create virtualadventures for the players in real time. The Vampire license fromWhite Wolf emphasizes the role of the “storyteller,” or moderator,so we felt the time was right to take this style of play out of thecollege computer lab and into a commercial RPG.
Implementing the storyteller system turned out to be fairly sim-ple from a technology standpoint. Most of the basic functionalityfor a storyteller game is identical to what would be required in atraditional client/server multiplayer game. The added cost wasmostly in the area of design and the user interface. It took a bit ofexperimentation and redesign to arrive at an interface that waspowerful enough to run games as a storyteller without beingoverly confusing to the novice player. The UI work included newinterface panels with lists of objects, actors, and other resources,and a few buttons to manipulate the selected resources. Our over-all design goal for the user interface was to ensure that importantfunctionality was accessible using only the mouse, and all key-board functionality represented only “advanced” controls such ashotkeys and shortcuts. Even though the storyteller system issomething used primarily by advanced players, we wanted to pre-serve this design goal, which meant quite a bit of extra UI workto make a mouse-driven interface powerful enough to drive astoryteller game.
In the end, the storyteller feature ended up being one of thegems of the game design, and resonated with both the press andgamers alike. Activision made good use of the feature in their PRand marketing campaigns, and we hope the expandability andstoryteller aspects of the game will give the game an increasedshelf life.
5.Using experienced contractors. One problem withour strategy of using a small core team is that we couldn’t
possibly cover all the aspects of designing a commercial game withjust 12 people. Instead, we relied heavily on external contractorsfor certain key aspects of the game.
Sound was one area where we made use of external talent. Ourcolleagues from LucasArts referred Nick Peck to us, based on hisexcellent work on Tim Schafer’s GRIM FANDANGO. Nick ended upnot only supplying us with sound effects, but also working onsome of the additional voice recording and ambient loops. Forour music, we teamed up with Kevin Manthei who scored the
j u l y 2 0 0 0 | g a m e d e v e l o p e r48
P O S T M O R T E M
Dark Ages portion of the game, and with Youth Engine, a localduo, for the modern-day tracks.
Even in the conceptual stages, we used external artists to helpus sketch and visualize the game. Peter Chan was the lead con-ceptual artist for JEDI KNIGHT and had subsequently become anindependent contractor. His work in the first months of theproject was key in establishing the look of the game’s environ-ments. We also worked with Patrick Lambert for character con-cepts and he delivered incredibly detailed full-color drawingsthat really brought the characters to life for the modelers andanimators.
Perhaps the most critical external relationship was withOholoko, a small startup spun off from Cyclone Studios. Wehired them to do our cinematic sequences that introduce the storyand provide the endings. While starting the project, we met withseveral firms specializing in computer animation, but pretty muchacross the board their rates were well beyond our budgets for thatpart of the game. It seems that the high demand for computer ani-mation from movies and television has driven the larger firms’prices beyond the reach of typical game budgets. By working witha smaller, less established company, we were able to get morebang for our buck in our cinematics, and the results proved to beof the highest quality.
What Went Wrong
1.Overly ambitious design. In retrospect, we were insome ways our own worst enemy. Many of the team
members had wanted for some time to do a really huge, ambi-tious role-playing game. When we actually started the projectand had a budget and schedule, we probably weren’t realisticabout how long RPGs typically take to develop, especially onethat travels to four different cities across an 800-year timeframe.We were very reluctant to make big cuts in the design, such ascutting one of the two time periods or removing the multiplayeraspect. Because of this, we eventually had to make the decisionto miss our first scheduled release date of March 2000. We alsocut back on our plans to release an interactive demo somemonths before the game and scaled back the scope of the multi-player beta.
Fortunately, by expanding the schedule a few months (fromMarch to June), we were able to preserve almost all the elementsfrom the initial design. But to accomplish this, the art and designdepartments really had to work above and beyond the call of dutyfor an extended period of time.
We did cut back a bit in the area of multiplayer by removingthe ability to play through the entire single-player scenario coop-eratively as a team, and instead replaced that with two smaller,custom-made multiplayer scenarios using levels and art from thesingle-player game. Part of this was because we did not planproperly for multiplayer when making some of the Java scriptsthat drive the single-player game. If the multiplayer game hadbeen functional earlier in the schedule, the single-player gamescripts might have been written from the start to be “multiplayerfriendly” and we could have shipped more multiplayer content inthe box.
2.Prototyping with a proprietary API. When we starteddeveloping the 3D engine for the game, which we named
Nod, the 3D API landscape was quite a bit different from how itis now. We decided to use Glide as an initial prototyping API withthe belief that it would be a more stable platform and avoid thecomplexities of supporting multiple hardware through a moregeneral API until we had solidified the engine a bit. However,once we had a basic, functional engine running under Glide, theprogrammers’ attentions turned toward game play and functional-ity rather than switching the graphics engine to a more generalAPI such as Direct3D or OpenGL.
Because of this “if it ain’t broke” mindset, we expanded oursupport beyond Glide fairly late in development. At the first pub-lic showing of the game at E3 in 1999, we were still basically a
w w w . g d m a g . c o m 49
ABOVE. Characters were created with a budget of between 1,000 and 3,000triangles. Boss characters, such as Ahzra the Tzimisce Elder were gener-ally the most complex.OPPOSITE PAGE. All of the more than 100 3D characters, such as Lucretia,a Setite priestess, were modeled and animated by hand by a team of fourartists using Maya.
Glide-only game, which meant we couldn’tdemonstrate the game in 32-bit modes orsupport some features not present in Glideat the time.
The extensive use of Glide also gave ussome unrealistic performance estimates forother hardware. Since Glide allows low-level access to things like texture-memorymanagement, we spent significant timewriting our own optimized texture manag-er. When we switched to Direct3D, mostof this work had to be discarded. SinceGlide allows more flexible vertex formatsthan Direct3D, some of our underlyingdata structures needed to be changed,which meant re-exporting hundreds of lev-els and models. We were making low-levelarchitectural engine changes at a stagewhen the engine should have been prettymuch locked down. Also, because weswitched late in our development schedule,we probably didn’t spend as much time aswe should have on compatibility testingwith a wide variety of hardware. In retro-spect, we should have switched toDirect3D or OpenGL several months earli-er in the development schedule.
3. Pathfinding difficulties. Oneproblem we identified early in the
development process was the problem ofpathfinding. Navigation of variably-sizedcharacters through a completely free-form3D environment is one of the most diffi-cult problems I’ve had to tackle as a gameprogrammer. Unit navigation is hardenough when you have a flat 2D plane orrestricted 3D environment, but in an envi-ronment where the level designers are freeto make stairs, ramps, or any other 3Dconstruct you can imagine, the problembecomes exponentially more difficult. Mynatural tendency when presented withsuch a sticky problem is, unfortunately, tomake it good enough for the early mile-stone and demo builds, and then just “dealwith it later.” Unfortunately, “later”quickly became “now,” and “now” turnedinto “yesterday.”
We should have tackled this problemmuch earlier, before the levels were nearcompletion. We should have worked withthe level designers to come up with a set ofrestrictions for their levels, or some addi-tional tagging in the editor to specify tothe engine where characters should and
should not move. Instead, the only hintsfrom the level-design tool were “walka-ble” floor flags, but little or no specialmarking of walls, cliffs, and other pathinghazards. Since we waited too long toaddress the problem, better solutions suchas walk boxes or walk zones would havetaken too long to retrofit into the morethan 100 levels already in the can. Instead,we spent weeks making small iterativefixes to the system to hide the mostextreme errors and turn what was an “A”bug into a “B” or “C” level problem.
4. Feature and data timing. Thisis a fairly common problem in
games I’ve worked on, and VAMPIRE wasno different. The technology team typicallylooks at the development schedule andschedules that entire block of time toachieve a certain feature set. Often, howev-er, new engine features get added too latein the schedule to be utilized fully by thedesigners and artists. This happened severaltimes during VAMPIRE. Some of the moreinteresting special effects, for example,were added only a few weeks before thedata was to be locked down for final test-ing. Other features that we added couldn’teven be implemented extensively. For
example, we added a more flexible shaderlanguage so late that only one to two per-cent of the surfaces in the game were ableto take advantage of it. Some features thatwe had originally planned for the engine,like bump mapping and specular lighting,were cut completely from the initial releasebecause there was insufficient time both tocomplete the feature and to create art todrive it. We softened the blow somewhatby moving some of these features to aplanned patch, which would add themlater if the game proved successful.
Unfortunately there are very few pro-gramming tasks that don’t require somesort of artist or designer input to find theirway into the finished product, so unlessprogrammers spend the last six months ofthe project doing nothing but fixing bugs,some of this is inevitable. We can justify itto a degree by looking toward the likelysequel or add-on projects as a way to takeadvantage of some of the engine work thatwas underutilized in the original title.
5. Self-restraint. As the projectwas drawing to a close, we found
that we ended up with a bit “too muchgame,” as someone put it. From the start,we decided to author our data for a high-
j u l y 2 0 0 0 | g a m e d e v e l o p e r50
P O S T M O R T E M
Real-time continuous level of detail allowed models to appear highly detailed in close-ups withoutsacrificing speed in longer shots.
end platform, so we’d have a good-lookinggame at the end of the 24-month schedule,and also because it’s much easier to scaleart down than up. Unfortunately, we neverreally started to rein in our art and designteams when we should have near the mid-dle of the project. Instead, we continued toadd more and more resources to the proj-ect, resulting in a minimum installationfootprint of about 1GB.
We authored all our textures in 32-bitcolor and then scaled them down at loadtime for 16-bit cards. Our models werealso extremely detailed (1,000 to 2,000 tri-angles each, on average) and relied onautomatic level-of-detail algorithms toscale them down for slower machines. Welit our levels with relatively high light-mapresolutions. All of this made the game lookgreat on high-end systems but it meant thegame was fairly taxing on low- to mid-range systems. In the end, the game justbarely fit on two CD-ROMs.
We had originally planned to includeboth 16-bit and 32-bit versions of thegame textures and allow players to choosewhich version to install, but after all theart was completed there was no room onthe CD for more than one version.
Likewise for sounds: we wanted to includemultiple quality levels but space preventedthis. We actually compressed most of thevoice samples with MP3 and had toremove several sounds from the game inorder to fit it on two CDs.
In the end, our game looked gorgeousbut had difficulty running on machineswith less than 128MB of RAM — andeven then, it used a fair amount of spaceon a swap drive. This glut of resources willalso make it more difficult if we choose toport the game to a more limited consoleenvironment.
At Last, Redemption
F or the first project from a new devel-opment startup, I can’t imagine how
things could have gone much better thanthey did, except perhaps if we could haveavoided shipping it the same year asDIABLO 2. As a company, we managed toaccomplish the three most importantthings in this business: not running out ofmoney, not losing any team members, andactually shipping the product. Our pub-lisher remained committed to the projectthroughout its life cycle, and even
increased their support as the project con-tinued to take shape.
The course of development was amaz-ingly smooth, with very few surprises orconflicts along the way. In this industry,you can almost bet that at some point in atwo-year development cycle somethingtraumatic will happen to either the devel-opment team or its publisher, but for usthe waters were remarkably calm. Aboutthe most exciting thing to happen duringdevelopment was when we lost our entireRAID server while attempting to add driv-ers to it, resulting in the loss of a fewmonths’ worth of archived e-mails.
Our good fortune allowed the team tofocus strictly on the game and preventeddistractions from outside the company.Also, keeping our company focused on justone title and resisting the frequent tempta-tion to take on more work and more staffallowed everyone to be on the same teamwith little or no secondary distractions.
Hopefully, by avoiding feature creepand a four-year “death march” kind ofending to this saga, we can avoid a lot ofthe burnout that we have seen and oftenexperienced on other teams. By maintain-ing links with both the fan communitythrough our web board, and with thedeveloper community at large by attend-ing shows like GDC, E3, and Siggraph,our team was able to keep a positive atti-tude and high energy level throughout theschedule. We remain convinced that smalldevelopment teams with a single-titlefocus are the best way to ship qualitytitles consistently, so our plans movingforward are to staff up gradually from 12to perhaps 16 people over the next fewmonths and embark on our next two-yearordeal a little older, a little wiser, and justa tiny bit larger. q
w w w . g d m a g . c o m 51
The game’s story unfolds mainly via in-game cutscenes. The excellent models allowed for the cre-ation of intricate details such as individual fingers, which helped make these scenes feel like pre-rendered cinematics.
j u l y 2 0 0 0 | g a m e d e v e l o p e r56
S O A P B O X d o u g l a s l o w e n s t e i n
Fighting a WarWithout an Army
“I t shall be illegal to sell, loan,or exhibit to a minor any pic-ture photograph, drawing,sculpture, videogame, motionpicture film or similar visual
representation or image, book, pamphlet,magazine, printed matter, or sound record-ing containing explicit sexual or violentmaterial or detailed verbal descriptions ornarrative accounts of explicit sexual orviolent material which predominantlyappeals to prurient interests, is patentlyoffensive to prevailing community stan-dards, and is utterly without redeemingsocial importance for minors.”
Sound like something out of a repressivetotalitarian state? It’s not. It’s an excerptfrom an amendment offered on the floor ofthe U. S. House of Representatives lastspring by House Judiciary Committee chair-man Henry Hyde (R-Ill.). The amendmentwas decisively defeated, but left many of usin the videogame industry rather chilled.
How about this: a bill to prohibit thesale or rental of any videogame ratedMature or Adult Only to people under 17,and to prohibit the admission of peopleunder 17 to businesses in which restrictedgames are shown or displayed. In otherwords, no one under 17 could enter Wal-Mart if a copy of QUAKE were on the shelf.
That’s what a bill proposed in Minnesotawould accomplish. The Interactive DigitalSoftware Association and its allies barelydefeated this bill in committee on a 6-6tie vote.
Back in January, President Clinton usedhis State of the Union address to call onCongress to enact a bill introduced by Sen-ator and former Republican presidentialcandidate John McCain (R-Ariz.) to requireall entertainment industries to develop acommon rating system, or else. The “orelse” is that the federal government wouldcreate such a system and then subjectretailers to criminal sanctions for failing toenforce these government standards.
And presently, the Federal Trade Com-mission is halfway through an investigationinto the marketing practices of all the enter-tainment industries. It has issued extensiveand massive document requests to nearly adozen companies in our industry alone.
These are flush times indeed for theentertainment software business. RecordU.S. sales of $6.1 billion in 1999, newhardware systems launching in the U.S.this year and next, Newsweek cover storieson the Playstation 2, conferences on theindustry’s impact on popular culture atM.I.T., there’s even a new interdisciplinaryGaming Studies program at the Universityof California at Irvine,
the first step toward a “major” in gaming. But it’s a time of great peril as well. The
by-product of our success in establishingthe industry’s economic and culturalimportance is greater visibility than everbefore. In short, we’re no longer flyingbelow the radar — we’re in the line of fire.
Now we’ve arrived at a point where leg-islation is currently pending in no fewerthan six states: New York, New Jersey,Pennsylvania, Minnesota, Tennessee, andWest Virginia. Last year, nine states enter-tained 17 different videogame violence bills.
The IDSA has met these political chal-lenges aggressively and, to date, successful-ly. But I will tell you that it has not beeneasy and one of the most significant handi-caps we face is the utter lack of involve-ment of many of the companies and indi-viduals that make up our industry.
No matter how many times and howthoroughly the IDSA testifies and lobbiesbefore Congress, there is no stronger voicethan that of the constituent. Your voice asgame developers does count and it is timefor your voice to be heard. It doesn’t mat-ter whether you’re in San Jose, Raleigh,Boston, or Austin, what’s going on insidethe Beltway and in far-off state legislatureswill affect your business and your craft
continued on page 55
illustration by Lisa Ringnalda
sooner or later. Many outside the gameindustry are not aware of the complexity ofgame development nor the industry’s rolein driving technology, and this includespoliticians and the media. Educate them.Let them know what you do, why you doit, and why you think it’s important.
From writing a letter to the editor of
your local paper to contacting your mem-bers of Congress, what may seem to be thesmallest personal action will have an effecton Capitol Hill and state legislaturesacross the country, and go a long waytoward establishing our industry as animportant social, cultural, and politicalforce in the 21st century.
You can also help this cause by makingsure that your products are rated by theEntertainment Software Rating Board andthat your advertisements follow the stan-dards set out by the ESRB’s AdvertisingReview Council. These programs ensurethat parents have the information theyneed to make appropriate game purchasingdecisions, and that advertisements aredesigned and published or aired responsi-
bly. Participating in these programs sendsthe message out that your company, likehundreds of others in the industry, is act-ing in the best interests of consumers.
All of you have a stake in the successof this grassroots campaign. Withoutyour involvement, we run the risk of con-tinuing to be seen as a peripheral part ofthe entertainment industry, not theincreasingly dominant player we actuallyare. I know this will take some time andeffort, but it will be well-spent and paylong-term dividends. q
S O A P B O X
A U T H O R ’ S B I O | Mr. Lowenstein hasserved as president of the Interactive DigitalSoftware Association since its creation inJune 1994.
continued from page 56
R E S O U R C E S
Interactive Digital Software Associationwww.idsa.com or e-mail Jeff Woodbury [email protected] for information
International Game Developers Association(formerly the Computer Game Developers Association)www.igda.org
Adaboy 17
AICS 53
Ascension Technology 8
Cinram 54
Conitec 55
Dice.com 52
Havok.com C2
Hewlett-Packard 23
IBooks.com 12
LIPSinc 11
Midway 52
Motek 3
Multigen-Paradigm 4
Newtek 18
Numerical Design Ltd. C3
RAD Game Tools C4
Rainbow Studios 53
Seneca College 54
SN Systems 21
Vancouver Film School 53
Viewpoint Digital 7
A D V E R T I S E R I N D E X
C O M PA N Y N A M E PA G E C O M PA N Y N A M E PA G E C O M PA N Y N A M E PA G E
