NOVEMBER 1998 - twvideo01.ubm-us.nettwvideo01.ubm-us.net/.../GDM_November_1998.pdf · the second...

V

NOVEMBER 1998

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

G ame development is nowalk in the park, especiallywhen it comes to managingthe business aspects. And

possibly the most stressful period for astudio is when it finds itself fallingbehind schedule.

Missing a milestone has several rami-fications. The two most notable sideeffects are a souring of the developer-publisher relationship and the post-ponement of milestone payments. Thelatter is especially serious for developers,and can propel a studio into crisismode. Creditors go unpaid, medium-and long-term planning go out the win-dow, and the team pulls together to sat-isfy immediate goals.

If these consequences weren’t badenough, often it gets worse. Pressurescan lure developers into the "second-title trap.” Faced with a high burn rateand limited funds to complete a title,it’s common for a development studioto pull some people off of the currentproject to put together a design docu-ment for a second title, in the hope thatafter a couple of months and more con-tract negotiations, a publisher willgreen-light it. The second revenuestream would offset the lagging mile-stone money from the first project,buoying the company for a while.

Watch out. Don’t forget that manypublishers insist on the first right ofrefusal for a developer’s second title, sothe developer has to approach his cur-rent publisher first. If the first project isgoing poorly, this publisher probablyknows it, and is therefore bargainingfrom a position of strength. If the pub-lisher gives the second project thethumbs-up, this contract will probablybe much less favorable for the developerthan the previous one.

If the publisher punts on the secondproject, the developer may decide tolook for funding elsewhere. So now thedeveloper, who hasn’t been talking upother publishers in a while, must shopthe second project around the industry.Back in the office, the original gamemay fall further behind because keystaffers are absent. Bills for plane tripsand hotel rooms from the far-flungschmoozing trips pile up in the office.

And here we go down the spiral. Wheee! If you find yourself in this situation,

my condolences. Your managementskills will be put to the test, and harddecisions regarding layoffs, budgets, andvacation plans will be forced upon you.One tidbit of advice: if your publisher isranting at you over a blown deadline,maintain your cool. It’s an emotionaltime, and taking the high road ratherthan getting into a war of words willhelp preserve your relationship.

Of course, there are ways to avoidfalling into this morass at all. Accountfor downtime in your budget. When fig-uring out how much money you needto complete a title, factor in a couple ofmonths’ worth of operational capital toget by after the product is completed.Don’t tap into that money if you runshort. Instead, immediately go back toyour publisher, confess that you’ve goneover budget, and face the music.Running out of money before you deliv-er the title puts you in a better positionthan if you run out after you’ve deliv-ered the completed product to yourpublisher. The undelivered product isyour only leverage during development.

Never factor royalty payments intoyour business plan. Think of royalties asbonuses or stock dividends (windfall). Ifyour budget depends on royalty pay-ments from your games, rest assuredthat you’ll run out of money.

Don’t wait until the last second to puttogether a design document for the sec-ond title. Presenting a publisher with asecond proposal earlier forces the pub-lisher to either fund it or fan it morequickly. If it decides to pass, you canpursue other publishers before the cashfrom the first project dries up. If possi-ble, plan two titles from the start, usingtwo different publishers. Of courseyou’ll want to stagger the delivery dates.

Finally, brush up on your businessmanagement skills. I highly recommendGordon Bell’s High-Tech Ventures: TheGuide for Entrepreneurial Success (AddisonWesley, 1991). Bell’s been around theblock many times, and the case studiesin his book offer priceless lessons. ■

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

2

P L A NG A M E

The Second-Title Trap

www.gdmag.com

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

PublisherCynthia A. Blair [email protected]

EDITORIAL

Editor-in-ChiefAlex Dunne [email protected]

Managing EditorTor D. Berg [email protected]

Departments EditorWesley Hall [email protected]

Art DirectorLaura Pool [email protected]

Editor-At-LargeChris Hecker [email protected]

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

Advisory BoardHal Barwood LucasArtsNoah Falstein The InspiracyBrian Hook id SoftwareSusan Lee-Merrow Lucas LearningMark Miller HarmonixPaul Steed id SoftwareDan Teven Teven ConsultingRob Wyatt DreamWorks Interactive

ADVERTISING SALES

Western Regional Sales ManagerAlicia Langer [email protected] t: 415.905.2156

Eastern Regional Sales ManagerKim Love [email protected] t: 415.905.2175

Sales Associate/RecruitmentAyrien Houchin [email protected] t: 415.905.2788

ADVERTISING PRODUCTION

Vice President Production Andrew A. Mickus

Advertising Production Coordinator Dave Perrotti

Reprints Stella Valdez t: 916.983.6971

MILLER FREEMAN GAME GROUP MARKETING

Group Marketing Manager Gabe Zichermann

MarComm Manager Susan McDonald

Marketing Coordinator Izora Garcia de Lillard

CIRCULATION

Vice President Cirulation Jerry M. Okabe

Assistant Circulation Director Mike Poplardo

Circulation Manager Stephanie Blake

Circulation Assistant Kausha Jackson-Crain

Newsstand Analyst Joyce Gorsuch

INTERNATIONAL LICENSING INFORMATION

Robert J. Abramson and Associates Inc.President Libby Abramson720 Post Road, Scarsdale, New York 10583t: 914.723.4700 f: 914.723.4722e: [email protected]

Chairman-Miller Freeman Inc. | Marshall W. FreemanPresident/COO | Donald A. PazourSenior Vice President/CFO | Warren “Andy” AmbroseSenior Vice Presidents | H. Ted Bahr, Darrell DennyGalen A. Poss, Wini D. Ragus, Regina Starr Ridley, Andrew A. Mickus, Jerry M. OkabeVice President/SD Show Group | KoAnn VikörenSenior Vice President/Systems and Software Division | Regina Ridley

BPA International Membership Applied for March 1998

Miller FreemanA United News & Media publication

Indie Game Festival? Take Two.

W here's our Sundance? (fromSeptember 1998 GamePlan)

What a strange question. By your ownadmission, Sundance is used toscreen completed films. Howmany games do you know ofthat are actually completedwithout a publisher paying thebill? An indie market doesn't exist.Instead, you would be more likely to seea "technologydemo" of agamewhichmay“wow”— butthis islike watching atrailer instead of a completed film.

Indie films are financed out of pocket,in the hope that the producers will gainbig when a distributor picks it up. Thereare over 80 years of procedure andanalysis for how a film producer willmake his money back, including thefact that technology for showing themedia already exists in mass formats.Every time a movie shows, the producergets a check.

Currently, the best an "IndependentGame Producer" could see is his moneyback (ooh) and perhaps a small royalty(the bulk of it goes to the game develop-ers) if the game's sale recoups its cost. Ifthe game fails, that's it, it's gone forever(no market for residuals, as old gamesare low tech.). Being an independentgame producer would be great for taxwrite-offs, but not much for income.

Indie films are also quickie films. Theproduction is complete in under amonth. Games can take 6 to 12 produc-tion months (especially if low budget).That's a lot of time to have one's moneytied up with no guarantees. Bottom line,this business needs to mature andbecome more profitable. Then, and notbefore, we can have comparisons withSundance (or the Oscars or Variety, ormany other Hollywood examples we donot currently fit).

Now the obvious. E3, as you noted, isnot the Sundance equivalent. But theComputer Game DevelopersConference [now the GDC] is as closeas you are going to get today.Networking, seminars, demos and yes,

even a completed independent gamemay be found there (in a relaxedvenue).

T o n y V a n

P r o d u c e r , E l e c t r o n i c A r t s

I agreewith youreditorialin Game

Developer100 percent.

As a developer forSierra, I see how large companies are

incapable of exhibiting the faith andvision required to break out of the "Howdo we copy id this time?" mentality.Marketing drives the industry morethan the talent. "How do we sell this toWal-Mart?" becomes the make or breakmoment for a game concept.

Continuing with your Hollywoodanalogy, too many games are put intoproduction on pitches such as, "It's across between QUAKE and DIABLO with alittle MYST thrown in." OpenGL,DirectX, and the Internet have providedindie developers with all of the resourcesneeded to make a great game but littlechance to get that game to market.

An added benefit, if this could growto other cities, would be the contactbetween gameplayers and developers. Atscreenings, indie filmmakers get instantfeedback on what worked and whatdidn't allowing them to improve on thenext one. Game players also get insightinto why decisions are made in thegames they like or don't like. E3 doesnot provide that kind of contact.

J i m E d w a r d s

v i a e - m a i l

Your idea promoting the organizationof an independent game developer festi-val is intriguing, but given the nature ofthe software development industry, I'dbe surprised to see anything like it takeshape. E3, obviously, is not a festival somuch as it is a conference — a placewhere established companies showcasetheir products before other industryexecutives, and where even smallerdevelopment houses typically have thesupport of a larger parent company. Tobring a game concept to playable demolevel, much less completion, requires alot of resources (money, talent, equip-ment, salaries, and so on) that don'texist in the same way that they do inthe film industry. To top it off, smaller

companies developing a product for,say, a popular console, must do so inthe usual entanglement of legal secre-cies and NDAs, as well as laboring underthe financial responsibilities of licenses,development kit purchases, and othercomplications.

Maybe the landscape for indepen-dent development would be different ifthings like the black PlayStation(Yaroze) were more widespread. Theproblem is, once you're involved intechnology, you're involved in licens-ing. Software products don't standalone as autonomous entities the wayfilms do (meaning: platform and hard-ware, not marketing and distributing).

There are so many other problems —the time to develop a game vs. the timeto shoot a film (16 weeks for a filmcompared to over a year for a game),the presence of independent sources ofmoney for filmmaking, and so on. Thenotion that a team of developers canbring a product to bear, showcase it,only to then have it picked up and dis-tributed is, frankly, almost absurd.

There are currently a number of festi-vals which highlight the undergroundof digital filmmaking (D.FILM,ResFest), and perhaps something thatprovides a showcase for all indepen-dent digital creativity (games, films,animation, graphic design, and thelike) would be more likely to succeed.

As a video maker and game animatormyself, I would be more interested in aproject that is more encompassing.Let's not forget that Sundance hasbecome an inflated feeding frenzy, crit-icized profusely and abandoned bymany members of the independentfilm community.

S e a n C a p o n e

v i a e - m a i l

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

4

Y O US A Y S

Got an idea? E-mail us [email protected]. Or write to GameDeveloper, 600 Harrison Street, San

Francisco, CA 94107.

v

Due Credit for the October Cover Image.The Skaar from GT Interactive/Epic

MegaGame’s UNREAL, was modeled by

Dave "Motornerve" Carter. Dave built

this image with Kinetix’s 3D Studio R4,

BonesPro from Digimation, and propri-

etary texture-mapping tools. It should

be noted that the image shows actual

in-game models, skins, and environ-

ments. Dave can be reached at

[email protected].

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

New Productsby Wesley Hall

New Network EngineRTIME recently released the latest ver-sion (V3.0) of the RTIME InteractiveNetworking Engine, a scalable, high-performance client/server networkingengine that supports real-time, multi-player gaming over both the Internetand Local Area Networks (LANs).

The engine enables game developersand publishers to build or port multi-player games to the Internet. This newrelease is built on top of a completelyrebuilt core engine, extends theengine’s performance and capabilities,and includes new features in responseto the requests of RTIME’s customers.One such feature is the new RTIMEIntegrated Server. Now RTIME-enabledgames no longer require a dedicatedserver to act as a host. A client applica-tion can now link directly with a localserver library that services all otherconnected gamers. V3.0 also helpsreduce bandwidth consumptionthrough the use of server-side dynamicfilter management. The ParallelWorldMasters feature extends the previ-ous WorldMaster (a server-side, super-client used to drive inanimate objects,provide server-based authority andsecurity, maintain scores, and so on) toenable multiple copies to run in paral-lel. Each one can be used to control dif-ferent simulations in the virtual world.Other new features include the abilityto specify restriction information onpublic and private objects, enhancedtransport directives, and streamlinedobject-level API. These build on alreadyexisting functions such as the

Distributed Timebase Manager (to keepglobal time synchronization), theRealtime Filter Manager (uses affinity-based data distribution to determinethe appropriate information to sendeach player in realtime), the IntelligentUpdate Manager, and Server-to-ServerCommunications. These features arebeneficial for many game genres,including action, strategy, sims, sportstitles, and persistent worlds. RTIMEV3.0 is currently being integrated intoseveral fall titles, including Acclaim’sTUROK 2: SEEDS OF EVIL, and Ripcord’sSPECOPS: RANGERS LEAD THE WAY.

The RTIME Client runs on Windows95, Windows NT, SGI, and Solaris. TheRTIME Server runs on SGI, Solaris, andWindows NT. A development-only ver-sion is available for Windows 95. ■ RTIME Inc.

Seattle, Wash.

(206) 281-7990

http://www.rtimeinc.com

Glide 3.03DFX just announced Glide 3.0, the newversion of its low-level software inter-face that enables control of the compa-ny’s Voodoo family of graphics chips.

Glide can serve as the primary appli-cation program interface (API) or maywork in conjunction with another APIto enable optimal acceleration on 3Dfxhardware. The API is designed specifi-cally and only for 3Dfx hardware. Glide3.0 is more streamlined than previousversions in an effort to make it easier towrite complex games or applicationsthat can fully take advantage of presentand next-generation 3Dfx chips. Glide3.0 utilizes triangle strips and fans, andhas new features including gamma tablesupport for complete control over light-ing brightness (including individual

color brightness control), vertex layoutsupport for complete control over indi-vidual vertices, and an extension mech-anism to allow developers to add addi-tional functionality and optimizations.

The Glide software developer’s kit(SDK) is available free of charge via the3Dfx web site. The kit also includesGlide programming libraries, tools, andsample code. Glide 3.0 and its SDK areavailable for download immediately.■ 3Dfx Interactive Inc.

San Jose, Calif.

(408) 935-4366

http://www.3dfx.com

Updated PolyTransOKINO recently updated its stand-alonePolyTrans Model Translator (forWindows and SGI) to version 2.2.

PolyTrans is a model translation pro-gram that allows 3D models and scenefiles to be converted between variousindustry standard file formats in theirentirety. Rather than convert just sim-ple geometry and some material attrib-utes, the PolyTrans program convertsevery aspect of a file so that the trans-lated file is "render ready.” New fea-tures include: animation conversion,auto-bitmap conversion for RIBexporter; animation conversionbetween 3D Studio MAX, Lightwave,RIB, and DirectX; Direct plug-in sup-port for 3D Studio MAX v1.2, v2.0,and v2.5; support for several new fileformats; and fully integrated trimmedNURBS support.

PolyTrans is available for Windows95/NT and SGI. Pricing starts at $395(PC, Windows) and $495 (UNIX).■ Okino Computer Graphics Inc.

Mississauga, Ontario

(905) 672-9328

http://www.okino.com

New Products: RTIME InteractiveNetworking Engine V3.0, 3Dfx’s Glide3.0, and Okino’s new version ofPolyTrans p. 6

Industry Watch: Many mergers, upsand downs at 3Dfx, and Broderbund’slayoffs p. 8

Product Reviews: Intel’s VTune 3.0and Sonic Foundry’s Acid p. 10News from the World of Game Development

6

B I T B L A S T S

Industry Watchby Alex Dunne

EIDOS announced record results for thethree months ending June 30. It sawrecord revenues to the tune of £25.8million (up from £9.4 million last year),amounting to a net loss of £3.0 million(compared to a £6.8 million loss lastyear). In other news, the companyacquired Crystal Dynamics in a deal val-ued at about $47.5 million, but don’texpect any Gex-Croft collaborations.GT BAGS FUGITIVE. GT Interactiveacquired equity interest in FugitiveStudios, a recent startup cofounded byGreg Williams, James Phinney, JessMcReynolds, and Brian Sousa. Many ofthe Fugitive employees were among thecontingent that bolted from Blizzardafter STARCRAFT shipped. In the deal, GTgets exclusive global publishing rights toFugitive software titles for both PC andconsole platforms, plus print and mer-chandising rights. Fugitive’s first titlewill be an “innovative 3D game” for thePC, and should ship in late 1999.AS EXPECTED, Broderbund layoffs willbe heavy as a result of the company’sacquisition by The Learning Company.Approximately 500 of Broderbund’s1200 jobs will be trimmed. Half of thesecuts will come from Broderbund'sCalifornia operations in Petaluma(which is closing this month) andNovato. The company hasn’t yet decid-ed where the other 250 layoffs willcome from. LUCASARTS SIGNED an exclusive two-year publishing and distribution agree-ment with Activision, wherebyActivision will handle all upcoming LAtitles in the United Kingdom,Scandinavia, Central Europe, the MiddleEast and certain African countries. ELECTRONIC ARTS completed its previ-ously announced acquisition ofWestwood Studios from VirginInteractive Entertainment (which isitself a division of SpellingEntertainment Group). As a result of the$122.5 million cash deal, WestwoodStudios becomes EA’s tenth studio. Brett

Sperry and Louis Castle have agreed tofive-year employment contracts, andwill remain with Westwood.DISCREET MAX! The 3D tools industryhas seen quite a bit of activity lately,and plots continue to unfold. Followingclosely on the heels of Microsoft’s sell-off of Softimage to Avid, Autodeskacquired Discreet Logic for $520 mil-lion, creating quite a powerhouse ofdigital content creation tools. As aresult, Autodesk's Kinetix division hasmerged into the new Discreet division,and tools such as 3D Studio MAX willnow carry the Discreet name. NEW PARADIGM. In the world of real-time 3D tools, MultiGen and ParadigmSimulation merged, creating MultiGen-Paradigm Inc. MultiGen, with its strongmodeling tool Creator (recently high-lighted in the August 1998 Postmortemof Atari’s SAN FRANCISCO RUSH) is a goodmatch-up with Paradigm’s simulationtools, such as Vega. MultiGen will con-tinue its operations in San Jose, andParadigm offices will remain in Dallas,and the two firms will combine theirworldwide sales operations.3DFX’S MIXED NEWS. The burgeoning3D hardware market isn’t all happinessand joy. In fact, it’s getting awfullycrowded on those store shelves. 3Dfxannounced that its Q3 retail sales fig-ures would be lower than anticipated,due a slowdown in the retail channel.Now there’s a glut of 3D inventory inthe hands of retailers, and the companyis pinning hopes on a healthyChristmas season to clear out someinventory. Assuming there’s no increasein demand, 3Dfx anticipates losing sev-eral million dollars at the pre-tax oper-ating level for its third fiscal quarter.Fortunately for the firm, its recent set-tlement with Sega (over the Dreamcastdeal) gave it some wiggle room, and3Dfx still anticipates a profitable thirdquarter. Following 3Dfx’s announce-ment, Robertson Stephens downgraded3Dfx shares from "Strong Buy" to "Buy",and the stock at press time is trading atits 52-week low (about $9).

On the upside for 3Dfx, softwareretailers Babbage's and Software Etc. justannounced the creation of a special

3Dfx section within their 450 nation-wide stores. This 3Dfx-only area will sell3Dfx-related hardware and softwareproducts, such as the Diamond MonsterFusion and Creative Labs' 3D BlasterVoodoo2, plus 3Dfx-optimized titlessuch as UNREAL, NFL GAMEDAY '99, NEED

FOR SPEED 3: HOT PURSUIT, and FINAL

FANTASY VII. ■

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

8

Game Developers ConferenceRoadTrip: Seattle

WASHINGTON STATE CONVENTION

AND TRADE CENTER

Seattle, Wash.November 9-10, 1998$225www.gdconf.com/1998/road-trips

Game Developers ConferenceRoadTrip: Austin

AUSTIN CONVENTION CENTER

Austin, TexasNovember 16-17, 1998$225www.gdconf.com/1998/road-trips

Game Developers ConferenceRoadTrip: S. San Francisco

SOUTH SAN FRANCISCO

CONFERENCE CENTER

South San Francisco, Calif.November 21-22, 1998$225www.gdconf.com/1998/road-trips

Digital Content Creation

LOS ANGELES CONVENTION CENTER

Los Angeles, Calif.December 2-4, 1998$595www.dccexpo.com

UPCOMING EVENTS

B I T B L A S T S


10

VTune 3.0by Dan Teven

If it seems as though we’ve devoteda lot of coverage to Intel’s VTuneprofiler this year, you’re not imag-

ining it. Ron Fosner awarded four starsto VTune 2.5 in an April review. Thenwe wrote up VTune again, in June,when it won the Front Line Award forProgramming Utilities. And now,despite déja VTune, I’m going to tellyou why release 3.0 is worth an addi-tional half star.

I’ll assume you’ve seen an earlierincarnation of the product, or at leastread Fosner’s review (which is online atwww.gamasutra.com/tools/reviews/).While VTune has always been a greatproduct for optimization junkies, itsold user interface was seriously flawed— Fosner called it “cluttered” and“annoying.” Happily, Intel has jetti-soned the old UI and replaced it with afar superior one.

Releases of VTune have alwaysadvanced the art of performance mea-surement, and 3.0 is no exception.You can now view an annotated func-tion-call hierarchy, showing explicitlyhow many times a function wascalled as well as the time taken by thefunction and its descendants. You canalso correlate operating system eventssuch as context switches or pageswaps with your application’s behav-ior. The new information dovetailsnicely with conventional hotspotanalysis, resulting in a more completepicture of performance.

QUICK START. The first time you runVTune, you’ll see an Easy Start menuwith three options: Quick PerformanceAnalysis, New Project Wizard, andOpen VTune Project. All of these tasksare just as easily accomplished fromthe File menu, and you have theoption of turning off Easy Start.

Quick Performance Analysis samplesthe current CS:EIP of each processor —yes, VTune 3.0 supports multiprocessorsystems — every millisecond for 20 sec-onds. It automatically charts the resultsby process, by processor, and by mod-ule, in three tabs of a single window. Asecond window shows the hotspotswithin the main module you’ve speci-fied. The main module doesn’t have tobe an executable file; it can be a .DLL,an .OCX, a device driver, a Java class,or even an object module.

Quick Performance Analysis is anexcellent place to begin when you’reprofiling anything that takes less than20 seconds. The two-window view isjust right. You not only find the bottle-necks in your main module, you findout if other modules are consumingmore time than you expected.

Behind the Easy Start menu, the oldpostage-stamp-sized main window(with multiple pop-ups) has beensuperseded by a full-size main window(with multiple children). Child win-dows can be tiled, minimized, andmaximized. Not only is this layoutmore familiar, it’s less cluttered.

The Navigator window, down the leftside of the screen, is a tree control thatlets you switch quickly among myriadsampling sessions and views of the data.I like this feature, but I do some of mywork on a notebook with a 640×480display, and it’s not worth the screenreal estate in that situation. DRILLING DOWN. More improvements areevident as soon as you try to drill downto the instruction level. In earlier ver-sions, you would start with a system-wide view and select the module thatinterested you. This would pop up a

new window showing hotspots in thatmodule. Then you’d select the hotspotthat interested you — and pop upanother window. Eventually, you’d getto a window with a source or disassem-bly view. To make matters worse, you’dfrequently have to perform these opera-tions by selecting a pixel-wide bar withyour mouse, and VTune’s hit testingwas sometimes off by a couple of pixels!

Now, VTune opens the hotspot win-dow for the main module automatical-ly, saving a step. And you don’t get anew window every time you zoom in;instead, windows are recycled. It’s stillpossible for the hotspots to be a pixelor two wide, and I wish Intel wouldimplement a magnifier tool to makethe selection process easier, but themouse click precision bug is fixed.

Whether you’re looking at graphsor raw sample data, time-based orevent-based sampling, or static ordynamic code analysis, all windowsshare the same main menu and tool-bar. This is a big improvement. Inearlier releases, where windows hadtheir own individual interfaces, Ioften had trouble figuring out how toget from point A to point B.

The source and disassembly viewshaven’t changed much since earlierreleases. It’s easy to see where you’respending CPU cycles, and VTune doesan excellent job of explaining pairingissues and execution penalties. I washappy to find the reference manualsfor the Pentium Pro instruction set andfor Intel’s MMX intrinsic functionsadded to the online help. Likewise, theevent-based sampling feature hasn’tchanged much.CALL GRAPH ANALYSIS. Consider a pro-gram that decompresses a bitmap andthen, accidentally, copies it to thescreen twice. Hotspot analysis by itselfwon’t reveal the problem. Say you pro-file with VTune 2.5 and observe thathalf the time is spent in your decom-pression code, with the rest spread outamong the operating system (BBiittBBlltt)and video drivers. You optimize thedecompressor, but the program’s stilltoo slow, and you’re stymied.

Fortunately, VTune 3.0 lets you docall graph profiling. This means collect-

Not so long ago, Dan Teven was obsessed with making a really cool game go really,really fast. This morning, he saw the game in a bargain bin for $15. Write him [email protected] to commiserate.

Excellent Very Good Average PoorBelow Average


11

ing data about every function call inyour program: not only who calledwhom, but how many times, and howmuch time elapsed between the func-tion call and the return. You find that adecompression call takes twice as longas a call to BBiittBBlltt; from the hotspotanalysis, you’d have expected the callsto take equally long. This can onlymean you’re calling BBiittBBlltt too often.VTune reveals the extra call, from anunexpected place. Bingo — another 25percent speed improvement.

I’m a firm believer in using call-tim-ing data to crosscheck hotspot data. Infact, I’ve often instrumented my pro-jects with function timing calls. Nowthat I can use VTune to gather thesame information — more thoroughlyand with better viewing capabilities —I’ll be retiring that code.

The only downside to call graph pro-filing is that it affects the performanceof a program. The instrumented callsare slower to execute, and the extracode can have adverse effects on thecache. VTune gives you some basicchoices about which modules to instru-ment, but I’d really like to see an APIso I could have fine-grained control.CODE COACHES. VTune now has codecoaches for five languages: C, C++,Java, Fortran, and assembly. Thecoaches are surprisingly skilled. I ranthe C coach on a program with anobvious bottleneck: a brute-force checkfor duplicate strings in a list. The bot-tleneck is so obvious that a commentin the source code warns about it andsuggests binary searching as a fix.VTune not only recognized that theproblem lay with the algorithm, itoffered better advice than the com-ment, suggesting both binary search-ing and hashing as solutions.

The assembly coach, which is new in3.0, looks for assembly-level optimiza-tions such as instruction schedulingand partial stall elimination. It won’tfind much that a good optimizingcompiler wouldn’t, but it would be anexcellent learning tool for an assem-bly-language programmer.EVENT CHRONOLOGIES. Two new featuresthat promise more than they deliverare Processor and OS Chronologies.

Essentially, VTune tracks various eventsduring the session — processor events,such as cache misses, or OS events,such as page swaps (the same ones youcan display in System Monitor) — andgraphs the data over time. Selecting atime range on the graph opens a newwindow illustrating the modules thatwere active during that time period.However, sometimes the windowwouldn’t open. And when the featureworked, there wasn’t much feedback toconfirm what I was viewing.CODE AND SYMBOL FORMATS. VTune 3.0supports C/C++ compilers fromMicrosoft, Intel, Inprise, Watcom, andIBM; Java compilers from Microsoft,Inprise, and Asymetrix; Delphi, fromInprise; Microsoft Visual Basic; andIntel’s Fortran. Most PC games indevelopment are Windows 98 titlesusing one of these compilers (OK,maybe not the Fortran). Some featuresaren’t available with all compilers. Ingeneral, the closer you are to the main-stream of development, the more fea-tures are supported.

Alas, VTune won’t be of much helpin speeding up any legacy tools uponwhich you may still be relying. I wasable to profile a DOS-extended buildtool running in a DOS box. Unfor-tunately, I couldn’t get VTune to mapthe samples to instructions properly,and I had to correlate the resultsmanually. I had even less luck when I

tried to statically analyze an objectmodule from a ROM BIOS. VTune canparse COFF object files, but notIntel’s own OMF.WRAPPING IT UP. There’s a lot that Ididn’t discuss here, because Intel hadthe good sense not to fix what wasn’tbroken. Instead, they fixed all the bugsthat used to frustrate me, added a cou-ple of features from my wish list, andmade the product a lot easier to use.This is a mandatory upgrade, and ifyou don’t already own the product,you’re in for a treat.

One important feature remains onmy wish list: an API. I’d like to beable to write loaders for differentmodule types, monitors for differentperformance events, and filters for dif-ferent output formats. I’d like to beable to control VTune’s behavior frommy program. I’d even like a redistrib-utable run-time module, so I couldwrite a program that monitored itsown performance.

Company: Intel Corp. Santa Clara, Calif.(800) 253-3696http://developer.intel.com/design/perftool/vtcd/

Price: $429 ($169 upgradefrom any previous ver-sion)

System Requirements:Windows 95 or 98,Windows NT 4.0 (SP3) orNT 5.0 beta 2. IntelPentium, 32MB RAM,50MB disk space. Theevent-based samplingfeature requires aPentium Pro familyprocessor.

Pros:

1. Shows performanceinformation in abundantdetail, by instruction,module, process, orprocessor.

2. New call graph profilingfeature counts, times,and charts function calls.

3. Code coaches and onlinehelp are excellent teach-ing tools.

Cons:

1. Needs an API that devel-opers can use to controland extend the product.

2. Data in Chronologiesview is hard to correlatewith other views.

3. Limited support for non-Windows code runningon the Intel architecture.

VTune 3.0:

B I T B L A S T S


12

Sonic FoundryÕs Acidby Andrew Boyd

A cid is not, and is not intendedto be, a standard multitrackaudio environment. Unlike

Pro Tools or Cool Edit Pro or even digi-tal audio sequencers, Acid is completelyfocused on building music from loops.You can’t do much in Acid that youcouldn’t also do in one of these otherenvironments, but if you find yourselfmaking music out of looping audio,you won’t find an easier, faster, or morefun program in which to do it. AndAcid does offer enough peripheral fea-tures to make it flexible. It isn’t perfect,but it is very impressive, and it could aseasily find a place with a completenovice as with a hardcore professional.Essentially, this is a product you proba-bly didn’t know you needed, but thatonce you’ve tried, you won’t give up. USING ACID. Acid isn’t so much aboutcomposing or even editing as it isabout assembly. It accepts sound filesof three basic types (in several formats)— loops, one-shots, and disk-based —and gives you a set of specialized toolswith which to piece them together.Loops and one-shots tend to be shortsounds loaded in RAM (Acid provides aRAM monitor so you’ll know whenyou’ve filled available memory). Themain difference between them is that

one-shots don’t loop — they tend to becrash cymbals, drum hits, vocal snip-pets, and so on. Disk-based files areoften larger files that Acid can get offdisk as the project plays. So you mightbuild a rhythm track out of a bunch ofdrum and bass loops, then load in (orrecord) a long vocal track to play alongwith it. That file would be a disk-basedstream by default. If for some reasonyou wanted to load it into RAM, andhad enough available, you could over-ride the default settings to do just that.

The program presents a screen splitinto three adjustable viewing panes: theTrack View, the Track List, and a multi-function section that can be set toshow an Explorer, an Edit Window, aMixer, or Effects plug-in pages. The pri-mary pane is the Track View — this iswhere you put together loops, drawautomation curves (“envelopes” in Acidparlance), drop markers, and so on.Though this section looks a lot like atypical multitrack editing environment,its function is pretty different. Forinstance, a given track can only hold asingle sound. It can be any supportedtype and can have as many instances asyou want, but you can’t slip a drum fillinto a space in a drum loop track tosave tracks — the fill will initiate itsown track. The down side is that pro-jects build up a lot of tracks very quick-ly and viewing and navigating throughthem can become a bit of a chore.

The Track List sits next to the TrackView and provides the name of the filein the track, an icon to indicate itstype, and some mixing controls (level,pan, effects sends, output assignment,solo, and mute). The bottom pane hasa number of modes selectable by stan-dard Windows-style tabs. Most often Iused it in Explorer mode, where it pro-vides a standard Windows Explorerview from which to select loops andsounds to load into the project.Another mode allows for “Acidizing” aloop, which involves adding propri-etary information, including a root

note for transposition, number of beatsand/or tempo for time scaling, and soforth. This pane also lets you access aMixer application, which presents levelcontrols for all wave devices installedin your system (nice — discrete outsfor multiple sound cards). Finally, thereare tabs to select settings for up toeight DirectX-compatible effects plug-ins (I used some CFX plug-ins installedby Cakewalk Pro Audio 6.01).

The first thing that’s noticeable aboutusing Acid is that it has essentially nolearning curve. If you’ve ever done any-thing with computer audio before andhave even a basic idea of how loopingworks in a musical context, you’ll bemaking music in minutes. The programships with a number of very usableloops on its CD (additional LoopLibraries from Sonic Foundry are about$60), and these are a great place tostart. Set the bottom pane to Explorerview and locate the loops on the CD.As you click on them, they’ll automati-cally play an audible preview. Whenyou find one you like, a double-clickwill add it to the Track List and create atrack for it in the Track View pane (youcan also drag and drop it into eitherpane). Click and drag anywhere in theTrack View with the pencil tool (here’sone of those really innovative features),and you’ll draw a perfectly looped andquantized bit of that sound. Oops,dragged for five bars instead of four!Hold the cursor near the end of thischunk of sound and it becomes a trim-ming tool. Click and drag back and itwill snap to the next bar (or whateverquantization resolution to which you’recurrently zoomed). On the next track,drop another loop that works well withthe first (because tempo and key arematched automatically, nearly every-thing sounds good together), draw asection of it out, and a song is born.Repeat until done.WILL COMPOSE FOR FOOD. Of course, ifyou really consider yourself a musicianor a composer, there’s a chance Acidwill insult you. Let’s face it: it’s cheat-ing. Using Acid to compose music islike sculpting with Legos rather thanclay. One method requires talent, skill,training, and patience while the

Andrew Boyd has been creating sound for games since 1993. He now runs AudibleImages, a music and sound design house in San Francisco, Calif. He can be reachedat [email protected].

Excellent Very Good Average PoorBelow Average


13

other… well, if you have thumbs tograsp the pieces, you’re pretty muchon your way. Still, schedules and bud-gets being what they are for gamesound, you’ve probably found yourselfbuilding pieces entirely out of samplesand loops anyway. Why not make iteasier on yourself? You’ll be able to puttogether polished pieces that impressclients in no time, you’ll own thelicense to the music, and you’ll evenhave fun. If you know music andaudio, your Acid arrangements will bethe better for it, plus you’ll work fasterand more efficiently.

One potential use for this program ina serious music environment is as awriting or practicing tool. Use it as asuper sophisticated drum machine —get a CD full of drum loops, pick out acouple that fit the direction you wantto go, and set them to looping. Thenyou can play your own parts — say ona guitar — over the loops until you getthem just right. Want to change thetempo? Just drag the slider (no process-ing all the loops and reloading theminto the project or any of that kind ofnonsense). Add a baseline to fill out thegroove and you can easily transpose itskey too. When your jam sounds good,you can record the guitar part rightinto Acid along with the rhythm track,and then export it as a sound file towhatever program you use for finalproduction. Acid doesn’t really havethe features to do a full production, butas an accessory to a more general tool,its simplicity and ease of use can freeup time and creative energy.

Which brings me to a few of Acid’slimitations and shortcomings. Forinstance, because each loop gets its owntrack, screen real estate becomes veryprecious very quickly. The ability toresize the various viewing panes pro-vides some flexibility, and there is azoom shortcut menu available througha simple right-click, but the only realsolution is to run in absurdly high reso-lutions. I tested at 1,024×768, and itwasn’t nearly enough to get a good viewof the piece being edited. I don’t have asuggestion for how to show the infor-mation better, but the way it is now canget pretty frustrating on a big project.

Also, the mixing function-ality is too limited. Forinstance, while eight effectssends is pretty generous,because individual tracksdon’t have even simple EQcontrols, if you want EQ(and to mix a lot of pre-made loops well, you will)you’ll have to start burningthrough those sends. Becausethe source material is usuallya bunch of little files, it’seasy and fast enough to pop them intoyour wave editor (a single button-click), EQ them, and reopen them inAcid. But given the clean, simpleapproach of the rest of the program, itdoesn’t seem as though that should benecessary for so fundamental a process.PERFORMANCE. Sonic Foundry has obvi-ously got some real throbbing-braintypes engineering its stuff. Acid’s per-formance is stunning. My test machineran Windows 95 on a not-very-impres-sive-anymore Pentium 200MMX with64MB RAM and a Turtle BeachPinnacle sound card. Acid was alwaysquite responsive, even while playinghuge projects with time and pitch scal-ing and a couple of effects plug-insrunning. Specifically, I noted the fol-lowing: on a 15-track piece with notime or pitch modulation and a CFXtwo-band EQ on FX1 and a CFXReverb on FX2, the program usedabout 50 percent of available processor

power, occasionally peaking as high as70 percent. Enabling some time andpitch scaling added around 5 to 10percent to these numbers. But on acurrent, fast machine you should runout of the desire to add loops or effectsbefore you run out of horsepower.WHAT A TRIP. When I first heard aboutAcid, I thought it seemed like a goodidea, but I really didn’t see the point.I’ve built plenty of pieces of music outof licensed loops and samples, and Ihave plenty of tools with which do it.But as I started playing with this tool, Ithought about how many hours of mylife have been sunk into searchingaround for that perfect loop at theright tempo, trying to pitch-adjust allthe loops in a song individually sothey’ll work in the right key, and soon. Acid does what it does so well, andis just so much fun to use, that I havelittle doubt it will soon be a standardaudio tool. ■

Company: Sonic FoundryMadison, Wis.(800) 57 SONIChttp://www.sonicfoundry.com

Price: $399

System Requirements: AnIntel Pentium 133 orAlpha AXP microproces-sor, Microsoft Windows95 or Windows NT 4.0 orlater, a Windows-com-patible sound card, aVGA display, a CD-ROMdrive, 32MB RAM, and5MB hard-disk space forprogram installation.

Pros:

1. Very fast and transparentway to assemble loop-based productions.

2. An interface so intuitiveit’s actually fun to use.

3. Excellent sounding (andefficient) real-time pitchand time scaling algo-rithms.

4.Ability to utilize discreteoutputs is a nice touch.

Cons:

1. Somewhat inadequatemixing functionality.

2. Limited built-in waveediting.

3. Homemade loops requiremore fine-tuning thanclaims indicate.

4. As fun as it is, it’s a bitpricey for a toy — makesure you actually have ause for it.

Sonic Foundry’s Acid:

b y M e l G u y m o n A R T I S T ’ S V I E W

this is done through the use of colorvertices. Color vertices allow us to givelife to our environments through theuse of light and shadow, and also allowus to alter the colors of our 3D modelswithout changing the textures or map-ping coordinates. Although the tech-nology for using color vertices hasbeen around almost as long as we’vebeen rendering polygons, the applica-tion and widespread use of the tech-niques has been largely ineffective dueto limited on-screen polygon counts.This is yet another example of how theincrease in rendering power of today’shardware accelerators has an unexpect-ed side-benefit.

This month we’ll look at three exam-ples of how to use color vertices to ouradvantage, and also talk about thetools and technology that make thesechanges possible.

Terms and Definitions

C OLOR VERTEX. In many real-time 3Dengines, the RGB value of each

vertex is stored right along with thegeometry. In most cases, this value isnormalized to somewhere in thelighter end of the spectrum (on a scalefrom 0 to 255, values of 175, 175, 175,or about 2/3 the distance betweenblack and white). If at some point inthe data generation process these val-ues can be altered, we can add andadjust the colors in our geometry with-out spending any of our valuable tex-ture space. GENERAL COLOR VERTEX APPLICATION. Colorvertices derive their color through acombination of up to three basicprocesses: • Color vertices can be modified by

hand, by directly choosing the colorof each vertex

• Color vertices can be procedurallygenerated through lighting

• Color vertices can be procedurallygenerated through texture sampling.While there are many capable pro-

grams on the market that support andallow modification of color vertices,we’ll only be looking at two, 3D StudioMAX 2.5 and Softimage 3.8.VERTEX COLOR LIMITATIONS. The main limi-tation when working with color ver-tices is that you need to have a vertexin order to have vertex color. This com-mon-sense notion comes into play par-ticularly when you use color vertices to

add areas of shadow to your environ-ments. Typically, large flat floors aremade up of a minimum number ofpolygons simply for efficiency. Yet, asFigure 1 shows, trying to use color ver-tices to represent cast shadows requiresthat you have sufficient vertices to addcolor. You may find yourself doingsome tesselating in certain areas simplyto get enough vertex resolution.BASIC COLOR THEORY. There are manyexcellent references on this topic, andit helps to have an idea of what worksbefore sitting down to add lighting toa scene. Here are some very general

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

25

Painting With Vertex Colors

Y et another weapon in the arsenal of today’s 3D artists, vertex colors

allow us to get more bang for our pixel buck without spending an iota

of texture space. Most of today’s cutting edge 3D engines support light-

ing of some sort, either dynamic or precalculated, and in many cases,

Mel has worked in the games industry for several years, with past experienceat EIDOS and Zombie. Currently, he is working as the art lead on DRAKAN

(www.surreal.com). Mel can be reached via e-mail at [email protected].

F I G U R E 1 . When using color vertices to represent cast shadows, you must have a

sufficient number of vertices to add color.

principles to remember when workingwith color:• Colors affect emotion. Reds are hot

and elicit excitement and restless-ness, while cool blues and warmgreens tend to engender feelings ofhappiness and calm.

• Color affects perception. Objects thatare lighter in color appear larger,especially when placed in darkspaces. The flip side is true as darkerobjects appear smaller.

• Complementary colors contrast. Theboundary between complementarycolors acts as a focal point; chooseyellow lights to highlight areas in ablue-lit environment, red for cyan,and so on.

• Color balance is key. Subtle lightingeffects are usually more effective insetting the mood; try to stick withtwo or three colors in each scene.

Environmental Lighting

I n this case, we’ll look at environ-mental lighting with procedural

color generation through raytracedlighting. Most 3D engines supportreal-time dynamic lighting using sim-ple point lights in 3D space. Theselights can greatly enhance the moodof an environment, but can be com-putationally expensive. In this exam-ple, we look at how to create a lightedenvironment in Softimage withoutusing any real-time lights.

Although animation is probablySoftimage’s real strength, Softimagedoes have a rather robust native mod-eling and texturing package, as well asa color vertex utility calledRenderVertexColors. This aptly namedplug-in, found in the Matter module,

allows the user to “bake” the colorsinto the vertices based on the materialproperties and lighting in the scene.It’s actually as simple as it sounds; youselect the object whose vertices you

want to color, then you execute theRenderVertexColors utility. The pro-gram then renders the object internal-ly, and determines the color of eachvertex based on the lighting and/or

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


26

F I G U R E 2 . Wireframe-rendered envi-

ronment in Softimage 3.8.

F I G U R E 3 . The wireframe scene after the application of textures and a generic

lighting model.

F I G U R E 4 . The scene was lit using several point lights, and then the lights were

removed, so that the lighting values remain, stored in the vertices.

texturing of the object. The vertex isthen assigned that color, and the datais hardcoded into the geometry. Thelights can now be removed from thescene and the geometry exported tothe 3D engine.

In Figure 2, we have a Softimagewireframe of a scene in a real-time 3Dgame. Figure 3 shows this same scenewith a generic lighting model and tex-tures applied (this is similar to whatwe usually see in most 3D engines: astatically lit world with some areas ofcolor). Figure 4 shows the result oflighting the scene with several pointlights, removing those lights, and thenstoring the lighting values “in the ver-tices.” Note that to light this singlescene in real-time with eight to tenlights would bring most 3D engines toa shuddering halt, yet we’ve accom-plished the same result without theuse of a single real-time light.SUGGESTIONS FOR IMPLEMENTATION. Leavethe lighting alone until the final pass.Taking the time to get the lightingright can make the difference betweena really stunning environment andone that’s just run of the mill. But this

time is often wasted if the geometryneeds to be modified for game play or

polygon-count considerations. Don’tbe afraid to use primary colors. A good


27

F I G U R E 5 . Character before the addition of color vertices in 3D Studio MAX 2.5.

lighting scheme is a blend of bothhigh and low-saturation light sources,blue/yellow, purple/orange, purple/green, and blue/red combinations areall pretty safe.

Procedural coloring routines, such asthe one in this example, are fine formaking macroscopic adjustments to ter-rain and environments, but what if youwant to do some fine detail work, suchas coloring the vertices on a character?

Hand-Adjusted Color

G enerating color vertices basedupon lighting for characters is

usually not effective. Characters tra-verse several lighting schemes whileinteracting with their environments, soit’s virtually impossible to find a singleset of color vertices that works for allcases. We can, however, modify thecolor vertices by hand to give highlydetailed results. Coming up with waysto distinguish between damaged andhealthy characters without blowing atexture budget can drive a good textureartist off the deep end. In this example

we’ll look at ways to accomplish thesame effect using 3D Studio MAX’s ver-tex coloring tool without adding a sin-gle pixel to the texture budget.

3D Studio MAX’s Assign VertexColor utility works in much the sameway as Softimage’s RenderVertex-

Colors. Vertices receive their color dataeither from a texture map or fromlights in the scene. We can also modifythe vertex colors by selecting the ver-tices and assigning the colors directly.Figures 5 and 6 show a player characterin a “before” and “after” mugshot. To

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


28

F I G U R E 8 . Textured terrain using color vertices.

F I G U R E 6 . Hand-painted color vertices using MAX’s Assign Vertex Color utility.

F I G U R E 7. The two textures that cre-

ate the terrain in Figure 8.

get this same effect using textures, we would need to dupli-cate the entire set of textures for the face and upper body.Furthermore, until we get a really good 3D paint tool, theprocess of painting blood onto a character is anything butan exact science; you’ll end up swapping back and forthbetween paint programs and 3D programs to get it right.

To achieve this effect using vertex colors literally tookabout five minutes. Using MAX’s vertex selection tool, yousimply select the vertices you want to color, and then selectthe color you want. The process is fully interactive, and theresult updates in the shaded window as you change the col-ors. This same method can be used on static objects to createthe illusion of dirt and grime, or to make an object appeardamaged. The only limitation is the number of vertices in themodel, because the resolution of the color vertices is directlylinked to the detail you can achieve.SUGGESTIONS FOR IMPLEMENTATION. Most engines allow you tostore multiple versions of each object, usually for level ofdetail. One way to take advantage of this process is to storemultiple versions with identical vertex counts, but withdiffering color vertex sets. And because the storage spacerequired for 3D geometry is virtually nothing compared tothat required for texture space, it’s possible to get a largedegree of diversity at virtually no expense. The last exam-ple uses both of the previous techniques, as well as a thirdaspect of the color vertex process: baking a texture mapinto the geometry.

Large-Scale Terrains

One of the problems encountered by people doing flight-sims is how to texture map extremely large expanses of

terrain. This is one case where the application and use of colorvertices provides an interesting solution to an otherwisedaunting problem.

Figure 7 shows the two textures that were used to create thisterrain. The first is a simple color gradient and the second is atiling noise map. The gradient texture is applied with a hori-zontal projection, so that vertices of a given height all corre-spond to the same color. Note the high, uniform vertex densi-ty in this example — this would probably represent a fairlyhighly detailed patch.

Figure 8 shows the fully lit terrain after the application ofcolor vertices, and the small noise map which serves to pro-vide the requisite pixel detail. Again, note that there are nolights in this scene; the lighting information has already beenstored in the color vertices. The final result is pretty impres-sive, since we only take up around 20K of texture space, andwe get several square miles of detailed terrain in the bargain. SUGGESTIONS FOR IMPLEMENTATION. Try a combination of allthree processes; bake the lighting and texture values in, andthen go back and adjust areas of interest by hand. Try usinga high-density mesh with a top-down project of a photo-realistic texture map, then go back with a noise map andtweak the result.

We’ve just scratched the surface when it comes to ways toeffectively use color vertices, and with our polygon-budgetscontinually on the rise, we are sure to see even more.

Special thanks to Melisa Bell, Hugh Jamieson, HayleyReed, and Louise Smith. ■

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

The value of PC game sales throughthe various retail channels comes toabout $3 billion. Let’s look at how these4,200 titles find their way into homes.

Skewed SKUs

A ccording to PC Data, software andcomputer stores carry approxi-

mately 1,500 SKUs each (these includeall software — games, applications, utili-ties, and so on). Direct mail vendorscarry nearly 700 SKUs, and the Wal-Mart-types carry about 500 softwaretitles. (Note that CompUSA, with overtwenty thousand square feet of storespace, carries fewer than 6,000 SKUs.)

Compare these numbers to a largebookstore like Barnes & Noble, whichcan carry up to 12,000 book titles at anyone time. Granted, there may only beone or two copies of some books instock, but most titles can sit there onthe shelf quite happily for six months ormore. Unfortunately for us, these condi-tions don’t apply to software. Softwareretail establishments simply don’t haveenough shelf space for all of the titlesthe game industry puts out, and thisshortage of “shelf space” is especiallydetrimental to independent developersand self-publishers. (Although, sadly,since the top ten game titles account for15 percent of all the game industry’srevenue, the lack of shelf space might bea moot point.)

Internet game sales aren’t even a blipon the radar right now. Many publish-ers, however, feel that the Internetcould account for as much as 20 percentof all revenues within the next fiveyears. Could this be possible? Even ifthis prediction pans out, I don’t thinkthat we will see a jump in the numberof SKUs retailers put before consumers.The reason is that Internet vendors, like

direct mail vendors, don’t want to stocka large selection of titles. These firmswant to pitch a product, get the order,collect the money, and ship it from aconsignment warehouse belonging to adistributor or publisher. To get 4,200SKUs out before the public wouldrequire one monster consignment ware-house, and I doubt that level of coopera-tion between the various publishers anddistributors will happen anytime soon.

What about taking the Internet to thenext step and making it a delivery vehi-cle for software as well? Ideally, con-sumers would embrace the idea of pur-chasing and downloading a title,thereby eliminating the box and printeddocumentation. But at today’s retailprices that’s a no-go. Psychologically,when you pay big money for goods youwant something more substantial thana three-hour download. Hence, I’m notenthusiastic about the Internet’schances as a fulfillment mechanism.

Segment and Conquer

I ’ve noticed an interesting phenome-non in the retail sales channel: the

best place to sell game titles is not nec-essarily the best place to buy game titles.For example, although a computer storelike CompUSA or Fry’s Electronics maycontinue to be the primary source ofsales for PC games by market share (seeTable 1), these types of stores don’t ful-fill the entire game industry’s needs.The reason is that computer stores caterto all computer users, from novice con-sumers all the way up to large corporatebuyers. With a desire to move volume

hardware, peripherals and software(and the commensurate marginsqueeze that accompanies this kind ofselling), the computer superstores wantpublishers to prominently display theirtitles and offer them at low prices toboot. This is how Broderbund keepsselling copies of MYST and Print ShopDeluxe: the titles are easy to recognize,easy to find, and a nice item to dunk inthe shopping cart as a person walksdown the aisles. Unfortunately, notevery publisher can afford lavish dis-plays or cut margins enough to succeedin computer superstores.

Next, let’s examine consumer elec-tronics stores. These stores, such as BestBuy and Circuit City, currently selltremendous amounts of software.Recently, though, they have begun tocut back on their computer productssections to enlarge their consumer elec-tronics and appliances sections (whichhave fatter margins and are poised forhigh growth with the emergence of digi-tal television products). So I don’t viewstores like Best Buy as a source of growthfor the PC game industry.

Toy stores such as Toys ‘R Us can’thelp the PC game industry much. Theyoung demographic of the Toys ‘R Usshopper certainly appeals to publishersof console games, but not necessarily toPC games publishers.

A Console Future?

I ’m more optimistic about consolegames. Console game publishers are

not too reliant upon the traditional soft-ware retail channels like CompUSA, and


31

Trends in the Sales Channel

T here are many changes happening in software sales channels today. As a

result, the opportunities for game publishers and developers are shifting.

This is especially true for game companies in the PC sector; the large chains

and the big warehouse clubs are eating up the market.

Omid Rahmat works for Doodah Marketing as a copywriter, consultant, tea boy, andsole employee. He also writes regularly on the computer graphics and entertainmentmarkets for online and print publications. Contact him at [email protected].

H A R D T A R G E T S


32

Store Type Name Number of Total Software SalesStores ($M)

Consumer Electronics Store Best Buy 285 $3,422.00

Computer Store CompUSA 153 $3,178.00

Office Superstores Office Depot 565 $2,350.00

Consumer Electronics Store Circuit City Stores 493 $1,810.00

Computer Store Computer City 96 $1,375.00

Office Superstores Staples 523 $1,250.00

Office Superstores OfficeMax 713 $1,080.00

Computer Store Micro Center 13 $1,030.00

Department Store Sears, Roebuck 835 $890.00

Warehouse Clubs Sam's Club 444 $728.00

Computer Store Fry's Electronics 16 $705.00

Mass Merchants Wal-Mart Stores 1,700 $700.00

Warehouse Clubs Costco 204 $502.00

Consumer Electronics Store RadioShack 6,906 $341.00

Military Store Army Air Force Exchange 142 $305.00

Software Stores Egghead Computer 86 $280.00

Computer Store PC Warehouse 82 $263.00

Software Stores Electronics Boutique 470 $229.20

Computer Store J&R Computer World 1 $195.00

Consumer Electronics Store Future Shop 27 $194.80

Software Stores Babbage's Etc. 466 $175.00

Consumer Electronics Store Sun TV & Appliances 48 $160.00

Consumer Electronics Store The Good Guys! 76 $140.00

Retail Dealer Computown 5 $140.00

Retail Dealer Creative Computers 8 $126.00

Consumer Electronics Store Nobody Beats the Wiz 49 $125.00

Retail Dealer Computer Renaissance 187 $107.00

Bookstore Barnes & Noble 1,013 $105.00

Consumer Electronics Store Nationwide Computers 4 $95.00

Computer Store CDW Computer Centers 2 $84.00

Toy Store Toys R Us 686 $75.00

Retail Dealer PC Club 15 $73.00

Warehouse Clubs BJ's Wholesale 87 $70.00

Mass Merchants Target Stores 799 $69.00

Computer Store RCS Computer Experience 2 $59.00

Music Stores Musicland 226 $58.00

Consumer Electronics Store P.C. Richard & Son 40 $57.80

Consumer Electronics Store American TV 8 $56.40

Retail Dealer SBI Computer Warehouse 6 $56.00

Retail Dealer Computer Ware 10 $52.00

Computer Store DataVision 1 $50.00

Retail Dealer Lucky Computers 18 $48.00

Retail Dealer Computer Town 7 $46.00

Direct Mail Global DirectMail 2 $25.00

Direct Mail Micro Warehouse NA NA

Direct Mail Insight Enterprises NA NA

Direct Mail PC & Mac Connection NA NA

Direct Mail Multiple Zones NA NA

Direct Mail Damark NA NA

TA B L E 1 . Top retailers by software sales alone (Source: Computer Retail Week).

with Sega, Sony, and Nintendo spend-ing hundreds of millions of dollars onChristmas promotions and sales, theconsole industry is set for healthygrowth for the next two years.

The onslaught of console marketingdollars means that direct channels, suchas mail order and Internet sales, havethe most potential for the PC gameindustry. The factor damping thegrowth of these direct channels is sim-ply the present industry structure. Thetop ten PC game publishers are loatheto damage their existing distributionchannels, limited or not, by putting toomuch emphasis on direct sales. So thetwo-tier distribution model (where a bigdistributor warehouses products, takesorders directly from retailers, and shipsthese stores their inventory) will not seeany significant changes for some time.

Putting the Squeeze On

W hat we can expect from thetop-ten PC game publishers is

that they will squeeze more out of theexisting distribution channels. These

big publishers have already started tofilter the titles carried by outlets suchas CompUSA and Wal-Mart. Theseretailers see the game market as benefi-cial to their business, but they willbecome increasingly stringent aboutwhat products make it to their shelves.Just look at the way EA and GTInteractive already control their chan-nels. The publishing community isbecoming a closed set, a private clubwith a waiting list.

The only option available to smallpublishers and developers going theself-publishing route is to circumventthe whole process – to market directlyto the consumers. It’s analogous to thesituation facing the makers of PCclones. These firms must market direct-ly via mail order and the Internet, too.Some clone vendors may somedaygrow up to be the next Dell orGateway, but for most that’s a longway off.

PC game developers have to startviewing publishers as brand equity inthe channel. If developers want inde-pendence, they must look for nicheaudiences that can be targeted with

direct sales. The losers in this scenariowill be the small retailers who can’tcompete with the superstores or take aslice of the direct marketing business.

I believe that PC game developmentis going to shrink in the next twoyears, and be replaced in part by con-sole development projects. The cost ofgoods and sales on games will rise,while the retail prices will continue todrop. These big publishers with largecatalogues of titles and economies ofscale will be the firms that flourish. ■


33

Top Ten Entertainment SoftwarePublishers In Computer Retail Channels

1. Cendant

2. Broderbund

3. The Learning Company

4. EA

5. GT Interactive

6. LucasArts Entertainment

7. Microprose

8. Interplay

9. Activision

10. Mindscape


RunRun

Graphics programmers are constantly looking

for ways to improve the realism of the

graphics in games. One of the simplest techniques

employed to do this is tex-

ture mapping, and

while texture mapping

does add considerable realism to a scene, it

also adds a number of new problems. The

most obvious visual problems that appear when using

textures in a scene are the aliasing artifacts that are

visible when texture-mapped polygons are some dis-

tance from the viewpoint. If you’re moving rapidly

around your virtual world, these artifacts appear as

flashing or sparkling on the surface of the texture. Or,

if the viewpoint is fixed, the artifacts appear as

unwanted patterns within the texture after it has been

mapped to a polygon. This is clearly visible in Figure

1, where the checkered texture map becomes distort-

ed as its distance from the viewpoint increases.

35


Andrew Flavell is yet another out-of-work PhD grad, wondering why he spent all of those years at school studying graph-theory and Markov models. Questions regarding the article and job offers can be sent to [email protected]

TimeMIP-Map Filtering

TimeMiP-MapFiltering

b y

A n d r e w

F l a v e l l

Illustration by RobertZammarchi

MIP-mapping helps alleviate this problem. The acronymMIP comes from the Latin phrase multum in parvo, meaning“many things in a small place.” Researchers at the New YorkInstitute of Technology adopted this term in 1979 todescribe a technique whereby many pixels are filtered andcompressed into a small place, known as the MIP-map. Tosee how MIP-maps improve visual clarity, see Figure 2, inwhich MIP-mapping with bilinear filtering has been used tosmooth the texture.

In order to understand what is what’s causing the prob-lems in the Figure 1, you have to look within the texture-mapping renderer and understand how the process of sam-pling the texture maps affects what’s displayed on thescreen. Look at Figure 3A, in which a sine wave is being sam-pled at a much higher frequency than the wave itself. As youcan see, a fairly good representation of the wave can beobtained from these samples. However, if the sampling fre-quency drops to exactly two times the frequency of thewave, as shown if Figure 3B, then it’s possible that the sam-pling points will coincide with the zero crossing points ofthe sine wave, resulting in no information recovery.Sampling frequencies of less than twice that of the sine wavebeing sampled, as shown in Figure 3C, causes the informa-

tion within the samples to appear as a sine wave of lower fre-quency than the original. From these figures, we can guessthat for complete recovery of a sampled signal, the samplingfrequency must be at least twice that of the signal beingsampled. This is known as the Nyquist limit. So, from wheredoes the seemingly magic value of twice the signal beingsampled come? In order to answer, that we’ll have to digressa bit further and take a stroll into the Fourier domain.

A Stroll in the Fourier Domain

A complete discussion of Fourier theory could take up sev-eral books by itself, so for those of you who haven’t suf-

fered through a signal-processing course at college, I suggestthat you take a look at the text by Bracewell that’s mentionedat the end of this article. What follows is a very limited intro-duction to Fourier transforms and sampling, but it should beenough to demonstrate how the Nyquist limit is derived.

Figure 4A shows a plot of the function h(t)=sinc2x and aplot of its Fourier transform, H(f). It’s convenient to think ofH(f) as being in the Fourier (or frequency) domain and ofh(t) as being in the time domain. (If you’re wondering why I


36

M I P - M A P P I N G

F I G U R E 1 . Checkerboard with no MIP-mapping.

F I G U R E 2 . Checkerboard with MIP-mapping and bilinear filtering.

chose to use sinc2x for this example, it’s because it has a sim-ple plot in the frequency domain.) To convert from the timedomain to the frequency domain, the following transform isapplied to h(t):

Eq. 1In this form of the Fourier transform, f defines the frequen-

cies of the sine waves making up the signal, and tells usthat the exponential term is complex (that is, it has both realand imaginary parts). The operator ⊃ is often used to denote“has the Fourier transform,” so we can write h(t)⊃ H(f). Figure4B shows the train of impulses used for sampling and theFourier transform of the impulses. An impulse, denoted asδ(t), is a theoretical signal that is infinitely brief, infinitelypowerful and has an area of one. An interesting property ofan impulse train with a period of Ts is that its Fourier trans-form is an impulse train with a period of 1/Ts.

Eq. 2The effect of sampling h(t) with the sampling function s(t)

is shown in Figure 4C. In the time domain, the sampling canbe thought of as multiplying h(t) by s(t), and in the frequen-cy domain, it can be thought of as the convolution of H(f)and S(f).

Eq. 3Convolution of any two functions f(x) and g(x) is given by

Eq. 4If the thought of plugging the Fourier transforms of both

h(t) and s(t) into Equation 4 has you wanting to skip to thecurrent Soapbox article (p.72), just hold on a second — itisn’t as bad as it looks. The convolution of a single impulselocated at t=t0, with h(t) is just the value of h(t) shifted tothat location.

Eq. 5We can apply the result of Equation 5 to find the convolu-

tion of H(f) and S(f).

Eq. 6Equation 6 simply means that the result of the convolu-

tion of H(f) and S(f) is such that H(f) is duplicated at inter-vals of 1/Ts, as can be seen in Figure 4C. The sinc2x functionis bandlimited (that is, its bandwidth is limited) to fmax, sothe only requirement needed to ensure that there are nooverlapping portions in the spectrum of the sampled signalis that fs>2fmax, where fs=1/Ts. So, this is from where theNyquist limit comes. As you can see in Figure 4D, if the sam-

pling frequency drops below 2fmax, adjacent spectra overlapat higher frequencies, and these frequencies are then lost inthe resulting signal. However, instead of disappearing com-pletely, these high-frequency signals reappear at lower fre-quencies as aliases; this is where the term aliasing originat-ed. To prevent aliasing from occurring, either the signalbeing sampled must be bandlimited to less than 2fs or thesampling frequency must be set to be higher than 2fmax.

MIP-Mapping Basics

L et’s look at how MIP-mapping helps to reduce aliasingartifacts in our texture-mapped image. Remember that

texture mapping is designed to increase the realism anddetail in scenes. However, all of the fine details in the tex-ture maps are effectively-high frequency components andthey are the cause of our aliasing problems. Since we can’treally modify our sampling frequency (1/∆U and 1/∆V in thetexture-mapping portion of our renderer), we have to filterthe textures to remove the high-frequency details.

Although it would be possible to filter each individualtexel at run time, this would require a significant amountof effort. To get around this problem, we can use MIP-maps, which are made up of a series of prefiltered andprescaled textures. The filtering of the textures either canbe carried out during the startup of your game, or you can

h t s tT

Hf nTs s

( ) ( ) ⊃ −

∑1

h t t t h u t t u du h t t( ) −( ) = ( ) − −( ) = −( )−∞

∞

∫* δ δ0 0 0

f x g x f u g x u du( ) ( ) = ( ) −( )−∞

∞

∫*

h t s t H f S f( ) ( ) ⊃ ( ) ( )*

δ δt nTT

f nTs

sn s

−( ) ⊃ −

=−∞

∞

∑ ∑1

i = −1

H f h t e dti ft( ) = ( ) −

−∞

∞

∫ 2π


37

-1

1

1 2 3 4 5

A.

-1

1

1 2 3 4 5

-1

1

1 2 3 4 5

B.

C.

F I G U R E 3 . Sampling a sine wave with varying sampling

intervals.

prefilter all of your textures during development. Anotheralternative with some graphics cards, such as those usingthe Nvidia RIVA 128 accelerator, is to have the card auto-matically generate MIP-maps for you when textures areuploaded into video memory. Figure 5 illustrates the pyra-mid-like structure formed by the MIP-map for a 64×64pixel texture. As you can see in the figure, the level ofdetail (LOD) decreases as the MIP-map level increases.Once textures have been filtered, all you have to do at runtime to achieve basic per-polygon MIP-mapping is to selectthe correct MIP-map level (or LOD) for the desired textureand pass this to the renderer.

Generating MIP-Maps

There are a number of ways to generate MIP-maps. Oneoption is simply to prebuild them using a graphics process-

ing tool such as Photoshop. The alternative is to generate yourMIP-maps on the fly. Prebuilding MIP-maps requires about 30percent more storage space for your textures when you ship


38


F I G U R E 5 . A MIP-map pyramid.

h ( t )

1

-1 1 2-2

s ( t )A.

Tsh ( t ) s ( t )

h ( t ) s ( t )

B.

C.

D.

H ( f )

fmax

H ( f ) * S ( f )

Ts

1

H ( f ) * S ( f )

S ( f )

F I G U R E 4 . Fourier analysis of sampling.

your game, but it gives you finer control over their generationand it lets you add effects and details to different MIP levels.Regardless of which method you choose, MIP-maps require 30percent more storage space at run-time than the original tex-tures, so they can have a significant effect on your game’smemory requirements.

Let’s begin by generating a MIP-map for an 8-bit texture.Generating a MIP-map is a fairly simple process andalthough there are many possible filtering techniques thatcould be applied during MIP-map generation, a standard boxfilter usually suffices. The first level of the MIP-map is gener-ated by taking the raw input texture and copying it directlyinto the MIP-map data structure shown in Listing 1. [In theinterest of conserving editorial space, code listings are avail-able for download from Game Developer’s web site. -Ed.]

Creating the rest of the MIP levels of a texture is an itera-tive process. Each successive level of the MIP-map is generat-ed using the preceding, larger, MIP-map level. As each levelof the MIP-map is created, it’s stored consecutively in mem-ory, and a pointer to the starting memory address of the MIPlevel is stored as well, so that the game engine can quicklyaccess the correct LOD during rendering.

The first step in generating a new pixel value is to calculatethe average color value from the four corresponding pixels inthe preceding level, as shown in Listing 2. As there is a paletteassociated with the texture in this example, once the newcolor value has been calculated, we need to search the palette

associated with this texture to find the entry that most closelymatches the desired color. This process is shown in Listing 3.The color search process is quite simple, but it can be time-consuming, as we need to search the palette for a color matchfor every pixel in each level of the MIP-map. Thankfully, thisstep is only required during the initialization of the MIP-map,so it’s not much of a problem. However, if you want to per-form other effects during rendering (such as bilinear or trilin-ear filtering), the search process will be too slow.

In this case, we’ll need to use 16- or 24-bit textures. Becausemost graphics cards currently support 16-bit screen depths,we’ll use 16-bit textures here. The process of building MIP-mapsfor 16-bit textures is very similar to that used for 8-bit textures,as you can see in Listing 4. Because 16-bit textures don’t requirea palette, averaging the color values from the four correspond-ing pixels in the preceding level directly gives each new pixelvalue. One problem that can occur as a result of repeatedlyaveraging the color values for each LOD is that the texture mapwill become darker at each successive LOD. You can compen-sate for this effect by adding a small amount to each color com-ponent at each LOD, but this compensation usually isn’t neces-sary, as the loss of color during the entire process is very small.

Applying MIP-maps at Run Time

F igure 6 shows some of the problems you can encounterwhen selecting which LOD to apply at run time. In the fig-

ure, the rectangular texture that’s mapped onto the triangle intexture space is transformed into a quadrilateral in screenspace, and the perspective projection of the texture causes the


39

V

U

Y

X

Texture SpaceScreen space

F I G U R E 6 . Texture distortion after perspective projection.

F I G U R E 7. Texture mapping with incorrect LOD. F I G U R E 8 . Road rendered with per-polygon MIP-mapping.

individual texels to become quadrilaterals of varying sizes. In acase such as this, where the orientation of a polygon is skewedin screen space, determining the best LOD to apply to a poly-gon is especially crucial if you want to produce good visualresults. If the chosen LOD is too high (the texture dimensionsare too large), aliasing will occur in the texture. If the LOD istoo low (the dimensions of the texture are too small), then theimage will appear blurred. For example, the LOD chosen forthe texture in Figure 7 is much too low, as can be seen by thelarge texels visible in the inset zoomed image. Many differentmethods can be used for LOD selection, all of which haveadvantages and disadvantages. The two well-known methodsthat we’ll examine here are the selection of the LOD based onthe area of the texture in screen space, and the selection of theLOD using the projected u and v vectors.

One further point to consider here is that it’s possible that adifferent number of texels map to each pixel in screen space.As a result, correct LOD selection requires calulating the LODfor each pixel. Calculating which LOD to use can be quiteslow; consequently most software renderers (and quite a fewolder hardware accelerators) calculate the LOD on a per-poly-gon or per-triangle basis. An added advantage of per-polygonMIP-map selection, especially for software-based renderers, isthat you can use smaller versions of textures for distant (small-er) polygons, helping to reduce the amount of processor cachethat’s required during texturing operations. However, per-pixelLOD selection lets you do a number of other things with MIP-mapping, including point sampling, bilinear filtering within asingle LOD, or trilinear filtering between the two closest LODs.

Per-Polygon MIP-Mapping

P er-polygon MIP-map selection is the least expensivemethod from a computational standpoint, becuse you

only do MIP-map selection once per polygon. There are,however, a couple of drawbacks to this approach. One prob-lem is that adjacent polygons that share a texture may bedrawn using differing LODs; this will be appear as a disconti-nuity in the texture when displayed on the screen (this iscalled MIP-banding). Figure 8 shows a small amount of MIP-banding that is occurring due to the use of per-triangle MIP-

mapping. Another problem is that visible popping mayoccur as a texture’s LOD is changed due to movement of theviewpoint (or the polygon). AREA-BASED LOD SELECTION. Area-based LOD selection comple-ments per-polygon MIP-mapping techniques. In thismethod, you select the LOD by determining the amount oftexture compression that will be applied to the texture inscreen space. To determine the proper texture compression,you calculate the area of the polygon in screen space and thearea, in texture space, of texture that is mapped onto thepolygon. As shown in Listing 5, you can determine the ratioof texels to pixels and then determine which LOD to use. Theu and v dimensions of each successive LOD are one-half thesize of the preceding LOD, so each successive LOD has one-quarter the area of the preceding level. During LOD selection,we step up one level in the MIP-map pyramid for each multi-ple of four that the texel area is greater than the pixel area.For example, if the texel-to-pixel ratio is 3:1, we would selectMIP-map level zero, or, if the texel-to-pixel ratio is 7:1, wewould select MIP-map level one. Once the LOD has beenselected, we can pass a pointer to the correct LOD, along withthe LOD’s dimensions, to our normal texture-mapping rou-tines. One problem with any approach that uses the project-ed area of the polygon and the texture area as the basis forLOD selection is that aliasing will tend to occur whenever aprojected polygon is very thin, due to the anisotropic natureof the texture compression (that is, the texture is compressedmore in one dimension than the other).

Per-Pixel MIP-Mapping

P er-pixel MIP-mapping offers far better control of LODselection than per-polygon MIP-mapping, and it also

permits additional texture filtering — but at some additionalcost. All of the per-pixel methods require storage of theentire MIP-mapped texture in memory, and adding LODselection to the inner loop of a renderer’s texture-mappingroutine can significantly reduce rendering performance.Fortunately, most of today’s 3D chips support per-pixel MIP-mapping with bilinear filtering (a few of the latest deviceseven support trilinear filtering), so we’ll look at what it takes


40


ux = ∂u

∂x

vx = ∂v

∂x

vy = ∂v∂y

uy = ∂u

∂y

P0 = x,y( ) P1 = x+1,y( )

P2 = x,y +1( )

'P u,v( )

'P 1

2

ux2 + vx

2

uy

2+ v

y2

1 Pixel

Screen Space Texture Space

P '

0 =

F I G U R E 9 . A single pixel back-projected into texture space.

to implement sophisticated per-pixel MIP-mapping.Although we could use area-based LOD selection here also(we’d need to calculate the texture area underneath eachpixel rather than for the entire polygon), we’ll look at an all-together more accurate method.EDGE COMPRESSION-BASED LOD SELECTION. In 1983, Paul Heckbertprobably examined more LOD calculation techniques thanhe’d care to remember before he decided that techniquesbased on the compression that a texture suffers along the edgeof a pixel seem to work best. Figure 9 shows a single pixel inscreen space and the corresponding parallelogram in texturespace. To prevent aliasing from occurring, we want to selectthe LOD based on the maximum compression of an edge intexture space. This corresponds to the maximum length of aside in texture space, which is given by Equation 7.

Eq. 7The values of ux, uy, vx, and vy are given by four partial deriv-

atives. Because we already know how to calculate the u and vvalues for any pixel on the screen, we can use this knowledgeto determine the partial derivatives. We know that, given theu/z, v/z, and 1/z gradients in x and y, and the starting u/z, v/z,and 1/z values at the screen origin, the u and v values for thetexture at any pixel can be found using Equations 8 and 9.The notation in Equations 8 through 19 is derived from ChrisHecker’s series on perspective texture mapping, which can befound on his web site (see “Acknowledgements” for the URL).

Eq. 8

Eq. 9We can use these results to find the partial derivatives, as

shown in Equations 10 through 13.

Eq. 10

Eq. 11

Eq. 12

Eq. 13

Where a, b, c, d, e, and f are given by Equations 14through 19.

Eq. 14

Eq. 15

Eq. 16

Eq. 17

Eq. 18

Eq. 19An important point to note here is that the numerators of

the partial derivatives ux and vx are functions of y only, andthe numerators of the partial derivatives uy and vy are func-tions of x only. The values of a, b, c, d, e, and f are calculatedonce per polygon, along with the usual texture gradients, asshown in Listing 6. Finally, the formula for finding the max-imum edge compression is given by Equation 20.

where

Eq. 20At first glance, it would seem that we would need to carry

out a square-root function at each pixel. However, if you lookclosely, you’ll see that we only need to compute yl once forthe polygon’s range of x values. Furthermore, we only need tocompute xl once per scan line. Listing 7 shows how we pre-compute the yl values for a polygon’s range of x values duringthe normal set-up for texture mapping, and also that we onlycalculate xl once per scan line. We also don’t have to worry

x c ay d by

y e ax f bx

l

l

= =( ) + +( )

= =( ) −( )

2 2

2 2

Compression =1Z

max x2 l l,y( )

f = ∗ ∗dVOverZdY OneOverZ -dOneOverZdY VOverZ0 0

e = ∗ ∗dUOverZdY OneOverZ -dOneOverZdY UOverZ0 0

d = ∗ ∗dVOverZdX OneOverZ -dOneOverZdX VOverZ0 0

c = ∗ ∗dUOverZdX OneOverZ -dOneOverZdX UOverZ0 0

b = ∗ ∗dVOverZdX dOneOverZdY -dOneOverZdX dVOverZdY

a = ∗ ∗dUOverZdX dOneOverZdY -dOneOverZdX dUOverZdY

vf by

y = ∗ − ∗ =Z dVOverZdY VOverZ dOneOverZdYZ

+Z2 2

ue ay

y = ∗ − ∗ =Z dUOverZdY UOverZ dOneOverZdYZ

+Z2 2

vd by

x = ∗ − ∗ =Z dVOverZdX VOverZ dOneOverZdXZ

+Z2 2

uc ay

x = ∗ − ∗ =Z dUOverZdX UOverZ dOneOverZdXZ

+Z2 2

vx y

x y= ∗ + ∗ +

∗ + ∗ +

=

dVOverZdX dVOverZdY VOverZdOneOverZdX dOneOverZdY OneOverZ

VOverZ

Z

0

0

ux y

x y= ∗ + ∗ +

∗ + ∗ +

=

dUOverZdX dUOverZdY UOverZdOneOverZdX dOneOverZdY OneOverZ

UOverZ

Z

0

0

max ,u v u vx x y y2 2 2 2+ +


41

F I G U R E 1 0 . Road rendered with per-pixel MIP-mapping

and point sampling.

about the divide required for the denominator, because it’salready required for standard texture lookup. So the overheadfor the compression calculation within the texture-mappinginner loop is just two multiplies and a compare. Now that weknow how to calculate the edge compression, let’s apply per-pixel LOD selection to our texture-mapping routines usingpoint sampling, bilinear filtering, and trilinear filtering.POINT-SAMPLED PER-PIXEL MIP-MAPPING. Point sampling is thesimplest form of per-pixel MIP-mapping, and as you can seein Listing 8, there isn’t much difference between our normaltexture-mapping loop and one that uses point sampling.Once we’ve found the amount of edge compression for thecurrent pixel, we need to determine the correct LOD. The rawcompression value ranges from a zero to one, but we need toscale it by the texture dimensions to get a meaningful heightin our MIP-map pyramid. Once we have the height, we deter-mine the correct LOD by stepping up one level in the pyra-mid for each power of two that the height is greater thanone. We then use our fast LOD lookup table to get a pointerto our texture and access the correct texel as usual. Figure 10shows the same object that we used to generate Figure 8, butthis time we’re applying point-sampled MIP-mapping. As youcan see in the figure, the main problem with point-sampledMIP-mapping is that MIP-banding is clearly visible at thepoints where transitions between different LODs occur. Thisis because adjacent pixels can have different LODs, so a dis-continuity appears as we switch between LODs.BILINEARLY FILTERED PER-PIXEL MIP-MAPPING. Bilinear filteringattempts to further reduce any aliasing errors present in ascene by averaging the values of the four pixels that are clos-est to the real u and v texture values for each pixel. As youcan see in Figure 11 and Listing 9, bilinear interpolation can

be implemented using three linear interpolations. We calcu-late the correct LOD and retrieve the pointer to our texturein exactly the same way that we did with point sampling.However, we then retrieve four texture values and applybilinear interpolation to each color component to generatethe new pixel value. Figure 12 shows our road after MIP-mapping and bilinear filtering. Although Figure 12 is animprovement over Figure 10, you can still make out theMIP-banding. Nothing has been done to remove the discon-tinuities that occur when we switch between LODs.TRILINEARLY FILTERED PER-PIXEL MIP-MAPPING. The current state-of-the-art for 3D hardware-accelerated MIP-mapping is trilinearfiltering. Trilinear filtering attempts to remove the problemsassociated with MIP-banding by smoothly blending betweendiffering LODs. As you can see in Listing 10, we once againcalculate the correct LOD in exactly the same way that we didit for point sampling, then retrieve pointers to the calculatedLOD and the next lower LOD (the next level up in the pyra-mid). Trilinear interpolation is implemented using eight lin-ear interpolations. We begin by carrying out bilinear interpo-lation separately for each of the selected LODs, then finish offby linearly interpolating between the two LODs. As you canseen in Figure 13, trilinear interpolation does result in asmooth transition between LODs (though the overall sceneappears somewhat blurred). Unfortunately, this feature comesat a considerable cost: the straightforward implementation oftrilinearly filtered MIP-mapping presented here requires eighttexture accesses for each pixel and a considerable amount ofcomputation. Although it’s possible to cut down on the num-ber of texture look-ups by saving texel values between loop


42


T00 T01

T10 T11

U

V

ru

rv

T0 =T00+ ru T10- T00( )

T1 =T01 + ru T11- T01( )

Tb =T0 + rv T1 - T0( )

Tb

T0

T1

F I G U R E 1 1 . Bilinear filtering calculation.


and bilinear filtering.


and trilinear filtering.

iterations, the interpolations themselves need to be per-formed for each loop, so achieving acceptable frame rateswith software-based trilinear filtering is very difficult.

Closing Remarks

W e’ve covered a lot of ground for one article, andalthough the output of our renderer using trilinear

MIP-mapping is significantly better than plain old texturemapping, it still isn’t perfect. The biggest defect remainingin our filtering is that, as I mentioned earlier, we’ve ignoredthe fact that the texture compression is anisotropic. We’reselecting LODs using the maximum compression along oneedge, but what if there’s a significant difference in theamount of compression between each edge? In this case, theLOD selected will be too low for the least compressed edge,

and our scene will appear blurred. You can clearly see thiseffect in Figure 14, which is a screen shot from the CHAOSVRdemo that was rendered using a card based on 3Dfx’sVoodoo2 chipset. This problem will occur with any 3Daccelerator that uses methods similar to the ones that we’vedeveloped here for calculating the LOD — not just theVoodoo2 card that I’m using. Clearly, the next step toimprove rendering accuracy will be to adopt some form ofanisotropic filtering. I’m sure that it won’t be long beforethis capability appears on high-end accelerators. ■


43

Bracewell, R. N., The Fourier Transform and its applications,

McGraw-Hill Book Co., New York, 1986.

Williams, L., “Pyramidal Parametrics,” Computer Graphics,

vol. 17, no. 3, (Proc. SIGGRAPH 1983).

Heckbert, P., “Texture Mapping Polygons in Perspective,”

NYIT Tech. Memo No. 13, 1983

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

Thanks go out to Chris Hecker who kindly allowed me to plugmy MIP-mapping into his texture mapping routines, saving mea lot of time. Check out Chris’s home page, http://www.d6.com/users/checker, for more information on texture mapping andhis old columns from Game Developer.

I’d also like to thank Paul Heckbert for taking the trouble tosend me one of the first publications to ever discuss MIP-map-ping. You can also find a lot of information about texture map-ping and myriad other graphics techniques on Paul’s home pagehttp://www.cs.cmu.edu/afs/cs/user/ph/www/index.html.Finally, I’d like to thank Peter Laufenberg for allowing me to usea screen shot from Virtually Unlimited’s CHAOSVR demo. Youcan find out more about the demo at http://www.virtually3d.com.

Acknowledgements

F I G U R E 1 4 . Screen shot of CHAOSVR rendered using trilinear filtering on a Voodoo2.

objective of a polygon reduction algorithm is to take a high-detail model with many polygons and generate a versionusing fewer polygons that looks reasonably similar to theoriginal. In addition to talking about what polygon reduc-tion is and why it is useful, this article explains one methodfor achieving it. Before going any further, I suggest youdownload my application, BUNNYLOD.EXE, which demon-strates the technique that I’ll explain. You can find it on theGame Developer web site.

Motivation

B efore diving into a sexy 3D algorithm, you may be ask-ing yourself if you really care. After all, there are com-

mercial plug-ins and tools that reduce polygons for you.Nonetheless, there may be reasons why you want to imple-ment your own reduction algorithm.• The results of your polygon-reduction tool may not meet

your specific needs, and you would like to build your own.• Your current polygon-reduction tool may not produce the

morph information that you require for smooth transi-tions between different levels of detail.

• You want to automate your production pipeline so thatthe artist has to create only one reasonably detailed model,and the game engine does the rest.

• You’re creating a VRML browser, and you want to providea menu option for reducing those huge VRML files placedon the Web by supercomputer users who didn’t realize theframe rate would be slower on a home PC.

• Special effects in your game modify the geometry ofobjects, bumping up your polygon count and requiring amethod by which your engine can quickly reduce polygoncounts at run time.


44

R E D U C T I O NP O L Y G O N

A Simple, Fast,and EffectivePolygonReductionAlgorithm

f you’re a game developer, there’s a good

chance that 3D polygonal models are part

of your daily life and that you’re familiar

with concepts such as polygons per sec-

ond, low-polygon modeling, and levels of

detail. You probably also know that the IIb y S t a n M e l a x

Stan Melax is researching interactive 3D techniques and algo-rithms for his Ph.D. in computer science at the University ofAlberta. He is also the Director of Technology at Bioware,where he had worked on SHATTERED STEEL and is now imple-menting cool stuff for their next 3D titles. He can be contactedvia e-mail at [email protected].

Still not convinced? Figure 1 shows a concrete example ofan instance in which a game engine requires polygon reduc-tion capabilities.

At Bioware, I implemented real-time Boolean operationsand used them in a game prototype that we developed toimpress our publisher. Players could shoot and blast arbi-trary chunks out of a solid object wherever they decided topoint the gun. Modifying the game environment where thebullets impact produces much more stunning results thanthe typical “place pipe bomb here” technique, in which thegame world only changes in a predetermined manner.Unfortunately, repeated use of Boolean operations per-formed on polygonal objects generates lots of additional tri-angles, as you can see in Figure 1. Many of these additionalfaces are small or splinter triangles that don’t contribute tothe visual quality of the game — they just slow it down. Thesituation demanded run-time polygon reduction, so I beganmy quest to find an algorithm that would do this efficiently.

Collapsing Edges

R ather than attacking this problemall by myself, I studied polygon

reduction with some other people at theUniversity of Alberta Graphics Lab. (Ithelps to work with a team in order to fig-ure out how the different algorithmswork and which technology is appropri-ate for which task.) A lot of research hasgone into this subject recently, and mostof the better techniques are variations ofthe progressive meshes algorithm by H.Hoppe (see “For Further Info”). Thesetechniques reduce a model’s complexityby repeated use of the simple edge col-lapse operation, shown in Figure 2.

In this operation, two vertices u and v(the edge uv) are selected and one of

them (u) is “moved” or “collapsed” onto theother (in this case, v). The following stepsimplement this operation:1. Remove any triangles that have both u andv as vertices (that is, remove triangles on theedge uv).2. Update the remaining triangles that use u asa vertex to use v instead. 3. Remove vertex u.

This process is repeated until the desired polygon count isreached. At each step, one vertex, two faces, and three edgesare usually removed. Figure 3 shows a simple example.

Selecting the Next Edge to Collapse

T he trick to producing good low-polygon models is toselect the edge that, when collapsed, will cause the

smallest visual change to the model. Researchers have pro-posed various methods of determining the “minimal cost”edge to collapse at each step. Unfortunately, the best meth-ods are very elaborate (as in, difficult to implement) andtake too long to compute. Motivated to find a way to reducepolygons during run time in a game, I performed manyexperiments and eventually developed a simple and blazing-ly fast approach for this selection process that generates rea-sonably good low-polygon models.


45F I G U R E 1 . Effect of Boolean operations on polygon count.

Before After

vvu

F I G U R E 2 . Edge collapse.

Original Final

F I G U R E 3 . Polygon reduction via a sequence of edge collapses.

where Tu is the set of triangles that contain u and Tuv is the set of triangles that contain

both u and v.

costn

u,v u v f normal n normalf Tu Tuv

( ) = − × − •( ) ÷{ }{ }∈ ∈max min . .1 2

E Q U AT I O N 1 . The edge cost formula.

Obviously, it makes sense to get ridof small details first. Note also thatfewer polygons are needed to representnearly coplanar surfaces while areas ofhigh curvature need more polygons.Based on these heuristics, we define thecost of collapsing an edge as the lengthof the edge multiplied by a curvatureterm. The curvature term for collapsingan edge uv is determined by comparingdot products of face normals in orderto find the triangle adjacent to u thatfaces furthest away from the other tri-angles that are along uv. Equation 1shows the edge cost formula in moreformal notation. The specific detailscan also be found in the source code(which you can dowlnoad from GameDeveloper’s web site).

You can see that this algorithm bal-ances curvature and size when deter-

mining which edge to collapse. Notethat the cost of collapsing vertex u to vmay be different than the cost of col-lapsing v to u. Furthermore, the formulais effective for collapsing edges along aridge. Although the ridge may be asharp angle, it won’t matter if it’s run-ning orthogonal to the edge. Figure 4illustrates this concept. Clearly, vertexB, sitting in the middle of a flat region,can be collapsed to A or C. Corner ver-tex C should be left alone. It would bebad to move vertex A, sitting along thetop ridge, onto interior vertex B.However, A could be moved (along theridge) onto C without affecting theoverall shape of the model.

If you’re implementing your ownreduction algorithm, you may wish toexperiment with this equation in orderto meet your needs. For example, in the

case of an animating mesh, you mightwant to develop a formula that will lookat more than just one keyframe whencomputing the cost of a potential edgecollapse. If quality is more important toyou than the reduction algorithm’s exe-cution time, then you should considerusing Hoppe’s energy function. We’veadded our own extensions to deal withtexture coordinates, vertex normals,border edges, and surface discontinu-ities such as texture seams.

Results

T he effectiveness of a polygonreduction algorithm is best demon-

strated by showing a model before andafter it has been simplified. Mostresearch papers demonstrate theirresults using highly tessellated modelsin the neighborhood of 100,000 poly-gons, reducing them to 10,000 poly-gons. For 3D games, a more appropri-ate (and challenging) test of analgorithm is how it demonstrates itsprowess by generating models that useonly a few hundred polygons.

For instance, Figure 5 shows a bunnymodel taken from a VRML file createdby Viewpoint Datalabs. The initial ver-sion (left) of the model contains 453vertices and 902 polygons. Reductionsto 200 (center) and 100 (right) verticesare shown. Hopefully, you’ll agree thatthe models look reasonably good giventhe number of polygons used in eachimage. Figure 6 shows the conse-quences of not selecting the right edgeto collapse at each step. In this case,edges were chosen randomly.

After completing animal testing, webegan human clinical trials for the algo-rithm. Figure 7 shows three versions —at 4,858; 1,000; and 200 vertices — of a


46

P O L Y G O N R E D U C T I O N

B to A

A

AAA

AAA

B

BBB

BBB

C

CCC

CCC

A to B

B to C

Original

C to A

A to C

C to B

F I G U R E 4 . Good and bad edge collapses.

F I G U R E 5 . Bunny model at (left to right) 453, 200, and 100 vertices.

F I G U R E 6 . Random edge selection

(200 vertex version).

female human model made by Bioware.(From Euler’s formula, we know that thepolygon counts are roughly double thesenumbers.) Once again, these images areshown with flat shading so you can seethe difference in the meshes. Whensmooth shading and textures areapplied, the differences are less apparent.

Practical Application

O ur initial goal was modest: wewanted to find a way to get rid of

a few excess polygons caused by toomany Boolean operation effects.However, after developing the reduc-tion algorithm and noticing better-than-expected results on actual models,we decided that the technique wasgood enough to generate the level ofdetail (LOD) models for the gameengine. An improved version of thisbasic algorithm has since been incorpo-rated into Bioware’s 3D graphicsengine, Omen. Now, for many gameobjects, our artists only have to createone detailed model. A preprocessingstep does the polygon reduction. Then,when the frame rate falls below a prede-fined threshold or an object is to berendered in the distance, a lower poly-gon version is used instead. Being ableto make these choices at run timeincreases the scalability of a game. Thegame adapts itself to the horsepower ofthe system on which it’s running.

Implementation Details

This algorithm only works with trian-gles. Nothing is lost by this limita-

tion; polygons with more sides are easilytriangulated if necessary. In fact, manyapplications use triangles exclusively.

Most data structures for storing polyg-onal objects use a list of vertices and a

list of triangles that contain indices intothe vertex list. For example,VVeeccttoorr vveerrttiicceess[[]];;

ccllaassss TTrriiaannggllee {{

iinntt vv[[33]];; //// iinnddiicceess iinnttoo vveerrtteexx lliisstt

}} ttrriiaanngglleess[[]];;

The IInnddeexxeedd FFaaccee SSeett node data typeused in VRML is another example ofthis type of data structure. When two


47

F I G U R E 7. Female human model showing 100 percent of the original polygons (left), 20 percent of the original polygons (cen-

ter), and 4 percent of the original polygons (right).

ccllaassss TTrriiaannggllee {{

ppuubblliicc::

VVeerrtteexx ** vveerrtteexx[[33]];; //// tthhee 33 ppooiinnttss tthhaatt mmaakkee tthhiiss ttrrii

VVeeccttoorr nnoorrmmaall;; //// oorrtthhooggoonnaall uunniitt vveeccttoorr

TTrriiaannggllee((VVeerrtteexx **vv00,,VVeerrtteexx **vv11,,VVeerrtteexx **vv22));;

~~TTrriiaannggllee(());;

vvooiidd CCoommppuutteeNNoorrmmaall(());;

vvooiidd RReeppllaacceeVVeerrtteexx((VVeerrtteexx **vvoolldd,,VVeerrtteexx **vvnneeww));;

iinntt HHaassVVeerrtteexx((VVeerrtteexx **vv));;

}};;

ccllaassss VVeerrtteexx {{

ppuubblliicc::

VVeeccttoorr ppoossiittiioonn;; //// llooccaattiioonn ooff tthhiiss ppooiinntt

iinntt iidd;; //// ppllaaccee ooff vveerrtteexx iinn oorriiggiinnaall lliisstt

LLiisstt<<VVeerrtteexx **>> nneeiigghhbboorr;; //// aaddjjaacceenntt vveerrttiicceess

LLiisstt<<TTrriiaannggllee **>> ffaaccee;; //// aaddjjaacceenntt ttrriiaanngglleess

ffllooaatt ccoosstt;; //// ccaacchheedd ccoosstt ooff ccoollllaappssiinngg eeddggee

VVeerrtteexx ** ccoollllaappssee;; //// ccaannddiiddaattee vveerrtteexx ffoorr ccoollllaappssee

VVeerrtteexx((VVeeccttoorr vv,,iinntt __iidd));;

~~VVeerrtteexx(());;

vvooiidd RReemmoovveeIIffNNoonnNNeeiigghhbboorr((VVeerrtteexx **nn));;

}};;

LLiisstt<<VVeerrtteexx **>> vveerrttiicceess;;

LLiisstt<<TTrriiaannggllee **>> ttrriiaanngglleess;;

L I S T I N G 1 . The enhanced data structure.

triangles on an object meet at thesame vertex, they’ll have the sameindex (so they share the same entry inthe vertex list).

We’ve enhanced this data structureas required by our polygon reductionalgorithm. One major improvement isthat we now have access to more infor-mation than just which vertices eachtriangle uses — we also know which tri-angles each vertex bounds. Further-more, for each vertex, we have directaccess to its neighboring vertices(which gives us the edges). Listing 1shows the enhanced data structure.

Member functions such asRReeppllaacceeVVeerrtteexx(()) have been added to per-form edge collapses during polygonreduction. Consistency of this data must

be maintained as vertices and trianglesare added, deleted, or replaced. The con-structors, destructors, and member func-tions contain code to keep things inorder. We cache face normals becausethey are frequently used by the edgeselection formula. In order to save us theeffort of recalculating these costs, thebest edge and its cost is cached for eachvertex. The implementation of themember functions is fairly straightfor-ward, so I haven’t included it in this arti-cle. If you’re interested, simply examinethis algorithm’s source code on theGame Developer web site. Listing 2 con-tains the code for determining edge costsand doing the edge collapse operation.

Performing polygon reduction iseasy given these functions. Simply ini-

tialize the vertex and triangle lists withthe object’s geometry, and then dosomething like this: wwhhiillee((vveerrttiicceess..nnuumm >> ddeessiirreedd)) {{

VVeerrtteexx **mmnn == MMiinniimmuummCCoossttEEddggee(());;

CCoollllaappssee((mmnn,,mmnn-->>ccoollllaappssee));;

}}

The demo, BUNNYLOD.EXE, doesn’tuse this simple loop. Instead it createsan additional data structure for theanimation.

Making Better Use of the Data

R ather than throwing away infor-mation about triangles and ver-

tices that have been removed, thisinformation can be preserved so that a


48

P O L Y G O N R E D U C T I O N

ffllooaatt CCoommppuutteeEEddggeeCCoollllaappsseeCCoosstt((VVeerrtteexx **uu,,VVeerrtteexx **vv)) {{

//// iiff wwee ccoollllaappssee eeddggee uuvv bbyy mmoovviinngg uu ttoo vv tthheenn hhooww

//// mmuucchh ddiiffffeerreenntt wwiillll tthhee mmooddeell cchhaannggee,, ii..ee.. tthhee ““eerrrroorr””..

ffllooaatt eeddggeelleennggtthh == mmaaggnniittuuddee((vv-->>ppoossiittiioonn -- uu-->>ppoossiittiioonn));;

ffllooaatt ccuurrvvaattuurree==00;;

//// ffiinndd tthhee ““ssiiddeess”” ttrriiaanngglleess tthhaatt aarree oonn tthhee eeddggee uuvv

LLiisstt<<TTrriiaannggllee **>> ssiiddeess;;

ffoorr((ii==00;;ii<<uu-->>ffaaccee..nnuumm;;ii++++)) {{

iiff((uu-->>ffaaccee[[ii]]-->>HHaassVVeerrtteexx((vv)))){{

ssiiddeess..AAdddd((uu-->>ffaaccee[[ii]]));;

}}

}}

//// uussee tthhee ttrriiaannggllee ffaacciinngg mmoosstt aawwaayy ffrroomm tthhee ssiiddeess

//// ttoo ddeetteerrmmiinnee oouurr ccuurrvvaattuurree tteerrmm

ffoorr((ii==00;;ii<<uu-->>ffaaccee..nnuumm;;ii++++)) {{

ffllooaatt mmiinnccuurrvv==11;;

ffoorr((iinntt jj==00;;jj << ssiiddeess..nnuumm;;jj++++)) {{

//// uussee ddoott pprroodduucctt ooff ffaaccee nnoorrmmaallss..

ffllooaatt ddoottpprroodd ==

uu-->>ffaaccee[[ii]]-->>nnoorrmmaall ^̂ ssiiddeess[[jj]]-->>nnoorrmmaall;;

mmiinnccuurrvv == mmiinn((mmiinnccuurrvv,,((11--ddoottpprroodd))//22..00ff));;

}}

ccuurrvvaattuurree == mmaaxx((ccuurrvvaattuurree,,mmiinnccuurrvv));;

}}

rreettuurrnn eeddggeelleennggtthh ** ccuurrvvaattuurree;;

}}

vvooiidd CCoommppuutteeEEddggeeCCoossttAAttVVeerrtteexx((VVeerrtteexx **vv)) {{

iiff((vv-->>nneeiigghhbboorr..nnuumm====00)) {{

vv-->>ccoollllaappssee==NNUULLLL;;

vv-->>ccoosstt==--00..0011ff;;

rreettuurrnn;;

}}

vv-->>ccoosstt == 11000000000000;;

vv-->>ccoollllaappssee==NNUULLLL;;

//// sseeaarrcchh aallll nneeiigghhbboorriinngg eeddggeess ffoorr ““lleeaasstt ccoosstt”” eeddggee

ffoorr((iinntt ii==00;;ii << vv-->>nneeiigghhbboorr..nnuumm;;ii++++)) {{

ffllooaatt cc;;

cc == CCoommppuutteeEEddggeeCCoollllaappsseeCCoosstt((vv,,vv-->>nneeiigghhbboorr[[ii]]));;

iiff((cc << vv-->>ccoosstt)) {{

vv-->>ccoollllaappssee==vv--nneeiigghhbboorr[[ii]];;

vv-->>ccoosstt==cc;;

}}

}}

}}

vvooiidd CCoollllaappssee((VVeerrtteexx **uu,,VVeerrtteexx **vv)){{

//// CCoollllaappssee tthhee eeddggee uuvv bbyy mmoovviinngg vveerrtteexx uu oonnttoo vv

iiff((!!vv)) {{

//// uu iiss aa vveerrtteexx aallll bbyy iittsseellff ssoo jjuusstt ddeelleettee iitt

ddeelleettee uu;;

rreettuurrnn;;

}}

iinntt ii;;

LLiisstt<<VVeerrtteexx **>>ttmmpp;;

//// mmaakkee ttmmpp aa lliisstt ooff aallll tthhee nneeiigghhbboorrss ooff uu

ffoorr((ii==00;;ii<<uu-->>nneeiigghhbboorr..nnuumm;;ii++++)) {{

ttmmpp..AAdddd((uu-->>nneeiigghhbboorr[[ii]]));;

}}

//// ddeelleettee ttrriiaanngglleess oonn eeddggee uuvv::

ffoorr((ii==uu-->>ffaaccee..nnuumm--11;;ii>>==00;;ii——)) {{

iiff((uu-->>ffaaccee[[ii]]-->>HHaassVVeerrtteexx((vv)))) {{

ddeelleettee((uu-->>ffaaccee[[ii]]));;

}}

}}

//// uuppddaattee rreemmaaiinniinngg ttrriiaanngglleess ttoo hhaavvee vv iinnsstteeaadd ooff uu

ffoorr((ii==uu-->>ffaaccee..nnuumm--11;;ii>>==00;;ii——)) {{

uu-->>ffaaccee[[ii]]-->>RReeppllaacceeVVeerrtteexx((uu,,vv));;

}}

ddeelleettee uu;;

//// rreeccoommppuuttee tthhee eeddggee ccoollllaappssee ccoossttss iinn nneeiigghhbboorrhhoooodd

ffoorr((ii==00;;ii<<ttmmpp..nnuumm;;ii++++)) {{

CCoommppuutteeEEddggeeCCoossttAAttVVeerrtteexx((ttmmpp[[ii]]));;

}}

}}

L I S T I N G 2 . Determining the edge costs and performing the edge collapse operation.

model at any specified number of ver-tices can be retrieved on demand with-out having to recompute the polygonreductions. This feature is easily imple-mented by storing the vertex to whicheach vertex is collapsed and sorting thevertices by the order in which theywere collapsed.

The BUNNYLOD.EXE demo uses thismethod. Initially, the bunny is reducedfrom 450 to 0 vertices in approximatelyone second. Then, as the slider on theleft animates the bunny, the model isrendered in increasing detail using thespecified number of polygons. Anotherway to think of this animation is as asequence of models for every numberof vertices between 0 and the numberin original model.

The edge collapse sequence couldalso be used for progressive transmis-sion. Just as interlaced .GIF and .JPGpictures come over the Web in increas-ing detail, the vertices of an object canbe broadcast in the reverse order fromwhich they were collapsed. The receiv-ing computer can display the modelwhile it is reconstructed from theincoming data stream. This is a niceidea, but it’s probably not relevant forgame developers just yet.

An important component in manygames is the LOD of models. A handfulof models can be selected from thesequence generated by our algorithmto represent the object at various LODs.One problem with swapping models isthat players often notice when thisoccurs (the phenomenon known as“popping”). A solution to the poppingeffect is to morph smoothly betweenthe models. In order to morph betweentwo models, the vertices of one modelmust be mapped onto the other.Fortunately, this information can beextracted from the edge collapsesequence. The BUNNYLOD.EXE demoalso shows an example of morphing.

Alternatives to Edge CollapseTechniques

P olygon reduction algorithmsaren’t the only way to create a

model with fewer faces. Artists willalways be able to do a better job of rep-resenting a model using fewer polygonsthan any reduction algorithm. One rea-son is that algorithms have little or nohigher-level understanding of the

model. An artist, on the other hand,knows the object that he or she is creat-ing (be it a rabbit, a chair, and so on)and can make careful aesthetic deci-sions as he or she manually reduces theface count. The human visual system isbiased towards certain details, such asthe eyes and mouth, and pays lessattention to other details such as thecollarbone or kneecaps. On the otherhand, our simple algorithm merelycompares a few dot products and edgelengths, and obviously doesn’t have theintelligence to place automaticallyvarying amounts of importance on dif-ferent pieces to optimize for humanperception. The advantage to using apolygon reduction algorithm is that itautomates the process.

Another technique for doing LODsin a game is to represent an object’sgeometry using parametric surfacepatches, which are tessellated on thefly to the desired detail. Shiny’sMESSIAH engine uses a similarapproach. Certainly, these surface-based methods are preferable (andprobably optimal too). Figure 8 illus-trates the advantage using a 2D analo-gy. An octagon reduced by one edge isregenerated as a regular heptagon bythe parametric approach. Collapsing anedge on the octagon produces non-reg-ular results.

Unfortunately, using curved para-metric surfaces isn’t always appropri-ate. Some of the challenges include get-ting the object into this sort ofrepresentation and being able to gener-ate polygons at render time so thatadjacent surfaces fit together properly(without gaps or T-intersections).Furthermore, jagged objects aren’tgood candidates for use with curvedsurface patches because the number ofsurfaces would be no less than thenumber of polygons required. Polygon-

based reduction methods are more gen-erally useful, and work with typicalmodels used these days.

While I hope that this informationand the accompanying demonstrationapplication that I’ve provided are use-ful, this article has not touched onissues such as dealing with texturecoordinates, vertex normals, borderedges, nonmanifold topology, textureseams, and so on. These subjects havebeen left as an exercise for the reader.Furthermore, many other variationsand enhancements to this algorithmare worth exploring. One exciting topicis adaptive simplification, in which dif-ferent parts of the same mesh are ren-dered at different levels of detailaccording to run-time parameters. Thisis especially useful for open terrainenvironments so that more detail canbe used near the current viewpoint. ■


49

Original Octagon Regenerated from circle equation using 7 edges

Edge Collapse

F I G U R E 8 . Comparison of techniques.

Polygon reduction has been a hot

research topic lately, and most of the

literature about it can be found in pro-

ceedings from academic computer

graphics conferences. Some more

places you can look:

• Cohen, J., M. Olano, and D.

Manocha. “Appearance-Preserving

Simplification”, SIGGRAPH ‘98.

• Hoppe, H. “Progressive Meshes,”

SIGGRAPH ‘96, pp. 99-108.

• Luebke, D. and C. Erikson. “View-

Dependent Simplification of Arbitrary

Polygonal Environments”, SIGGRAPH

‘97, pp. 199-207.

• I have a demo on my university web

site at http://www.cs.ualberta.ca/

~melax/ polychop

• H. Hoppe, the Guru of polygon

reduction, maintains a web site at

http://research.microsoft.com/~hoppe/



51

F A C I A L A N I M A T I O N

my lumps, I’m in a good position to help you understandyour options and teach you a bit about the process itself.

First, let me say that you’d have to be crazy to try to ani-mate a face to match a voice. Entire regions of the humanbrain are dedicated to recognizing facial patterns and bodylanguage. Hundreds of muscles in a human face move, con-tract, and slide in and out of one another, mocking ourattempts to duplicate their deceptively simple duties. Onesimple mistake can transform your life-like character into anevil pile of face parts and prompt reactions such as, “Ooh,that’s disturbing,” from passersby.

It didn’t take much for me to realize why I’d never seen aconvincing realistic 3D head model talking, especially onecomposed of only a few hundred polygons. After beingbriefly exposed to the technology and noting the queer ges-tures and difficult timing problems of facial animation, I feltthat the technology simply wasn’t ready.

But if you have to make it work, and we had to make itwork, what can you do? We had a very large script withmany medium and close-up shots, and I had to come upwith a way to animate pages of script spoken and acted outby low-polygon characters.

Approaches

Y ou can approach facial animation in any one of severalways; you’ll need to decide early on which way you’d

like to go. Probably the most flexible and powerful of these isthe approach used by Pacific Data Images in the upcomingDreamWorks film Antz. This solution involves researching allthe muscles of the face and using a huge team of artists andprogrammers for a couple of years to develop an animationsystem based on the way human facial muscles move andslide on the skull. You probably don’t want to approach theproblem in this way, however. A more reasonable approach is

AnimatingFacialExpressions

he challenge of capturing the sub-

tleties of facial movement is what

brought me back to motion capture

after a brief but scarring first experience

and, consequently, what compelled me to

write about my trials. Now that I’ve taken

b y J a k e R o d g e r s

Jake Rodgers has earned the prestigious title of “One of many” atDigital Anvil, and his dream is to art direct the Second Coming.His first game experience was WING COMMANDER II, VENGEANCE

OF THE KILRATHI, and he has a feeling his career is “about to real-ly take off.” He can be reached at [email protected]

Ima

ge

co

urt

es

y o

f P

yro

s P

ictu

res

.

TT

to use either some form of phoneme tar-get blending, 2D or 3D motion capture,or a combination of these. I will explaineach of these methods briefly just incase you aren’t familiar with them.

Phoneme Blending

W ebster defines phoneme as,“Any of the abstract units of the

phonetic system of a language that cor-respond to a set of similar speechsounds (as the velar \k\ of cool andthe palatal \k\ of keel) which are per-ceived to be a single distinctive soundin the language.”

There are many different ways toblend phonemes in an animated charac-ter, but the vast majority of softwaretools share the same process. Theprocess involves creating a template ofphonemes, or gestures, then assigningeach of them to specific MIDI channels,which are in turn controlled by slidercontrols. The position of each sliderdetermines the percentage of thatphoneme’s contribution to the overall

gesture. A channel updates only the ver-tices of the polygon in the face usedwith a particular phoneme’s gesture,allowing you to mix a frown with ayawn, or a wink with a smile, and so on.Plug-ins such as Lambsoft’s Smirk andPlatinum Pictures’ MorphMagic work inthis way. Kaydara’s FiLMBOX has a fea-ture called Voice Reality that can recog-nize phonemes from a voice track andlip-sync the animation for you.

Phoneme blending is a way to makesure your gestures look correct (assum-ing that you have a good template ofphonemes) because it allows you tointeractively see the results. You canthen say, for example, “Hmm, it needsmore frown” or “More ‘ooooohh’please.” Unfortunately, this processleaves the burden of timing on yourshoulders. Animators may be readingthis and saying to themselves, “Noproblem. I’m an animator, after all.”However, remember that my projectinvolved a large script that would havedriven even the purest animator nutstrying to keyframe every sequenceusing these kinds of tools.

Phoneme blending is a good solutionif you want the ability to change thetiming of the voice after you’ve ani-mated the face, if you have quick ani-mations, if you’re working under atight budget, or if you really enjoyphoneme blending.

2D Facial Capture

Two-dimensional facial capture is awidely used, efficient way to apply

motion to a character’s face. The hard-ware typically used for 2D facial cap-ture is Adaptive Optics Associates’FaceTrax, Motion Analysis’s Face-Tracker, and Vierte Art’s Xist. Theseproducts use head-mounted devicesthat track markers applied to an actor’sface, usually using one camera. Two-dimensional facial capture is a goodmethod for performance animationand near-real-time animation.

Another method uses a regular videocamera and a tool such as Techimage’sArtiface. This tool uses a sophisticatededge-detection program to track themovement of the lips (and only the lips)of a filmed actor. The user then importsa 3D object, applies some simple musclestructure to the object to control theway the mesh is deformed, and thenapplies the captured animation.

If your character is going to be look-ing directly at the camera, and not gen-erally seen at different angles, 2D cap-ture might be suitable for your project.However, this method is limited in thatit really can’t capture subtleties on theface, and it can’t accurately reproducewhat’s happening in the z axis (whichis very important for smiles).

The other problem with 2D facial cap-ture is that the head-mounted camerascan hamper the actor’s natural motion,and you want him or her to be comfort-able (especially during lengthy capturesessions). I’m sure there are lighter unitscoming out on the market, but consid-ering the aforementioned cons and theparticulars of our project, 2D facial cap-ture was not a good solution for us.

3D Facial Capture

T hree-dimensional facial capturegives you the most movement

information, including head move-ment and almost any facial gesture


52


F I G U R E 1 . Lambsoft’s ProMotion lets the user actually draw over the function

curves for markers. This made cleaning up spikes in the data fairly easy.

ProMotion also lets the user apply global filters such as median and average, as

well as a Fix Eulers filter that takes away unwanted flips in rotation data for body

motion capture. ProMotion is very good at taking motion capture data and putting

it on characters whose proportions don’t match the actor. The screenshot is from

a beta release of ProMotion.

your talent can muster. It also givesyou the ability to match up, with rela-tive ease, any actor’s face with a com-puter generated character (I’ll explainthis process shortly). Although thisapproach also poses the most potentialproblems, at least you’re capturing agreat deal of data. With the right mixof accurate captures and good clean-upsoftware, you’ll be able to use this dataonce you’re back in your office.

One of the known problems of 3Dfacial capture is that it’s difficult tomanipulate the geometry of a face onceyou’ve applied the motion to it. Oneprocess I’m currently trying to developis a hybrid of 3D capture and phonemeblending. During the capture session,the face actor is asked to go through thetypical phonemes — frowns, smiles,and so on — from which we wouldconstruct a base phoneme library. Eachgesture would have a keyframe for eachmarker, which could be layered uponthe capture data. Just as with phonemeblending, we would assign each markerto a MIDI channel. Now, if we need thecharacter’s mouth to shut more, wesimply adjust the appropriate sliders,which in turn moves the markers a cer-tain percentage of the way towards thekeys we had previously set.

Tools

S everal tools are available to gamedevelopers trying to achieve good

facial animation results. And eventhough it might not be a good idea forsomeone to stick their neck out andrant about tools, I did a modestamount of research on every majorsolution I could find.

Right now, I would argue that thecombination of Kinetix’s 3D StudioMAX, Character Studio, and Lambsoft’sProMotion (Figure 1) makes the mostsense on several levels. The most obvi-ous advantage is cost. Most comparablepackages (such as Alias|Wavefront’sPowerAnimator or Maya in its impres-sive, but young form) would have cre-ated a budget problem for us, especiallyconsidering that our desired result wasa real-time animated object with a low-polygon count. To us, the tool(s) inquestion had bend to the specific needsof our game engine, yet still have suffi-cient power and a relatively shortlearning curve. MAX had the benefit of

a few years of real customer feedbackand some very useable plug-ins, whichmade it the winner for us.

Another noteworthy tool is SvenTechnology’s SurfaceSuite Pro. It’s per-fect for creating head textures, usingmultiple projections on one object(top, sides, front, back), and maskingprojection layers so that you can blendseveral photographs (for example, afront view, a side view, and so on)seamlessly onto a head (Figure 2).SurfaceSuite then uses its own rendererto create a single, seamless cylindricaltexture for real-time export, askingonly that you define the resolution.

Process

T he preproduction stage is critical toa project, particularly if you’re

going to employ a nascent technologysuch as facial motion capture. Figure 3illustrates our development processworkflow for everything relating tofacial animation, from concept to gameengine. Note that everything sproutedfrom the script and storyboards. A littleinspirational art before that stage ishelpful, but in our company, no trueproduction is allowed until the produc-

er signs off on concepts, scripts, andstoryboards. (Of course, in practice,we’ve never strictly adhered to thisrule. But you must agree it is a wonder-ful model to which to aspire.)

Getting Started

O nce you have a good script andyour characters have been fleshed

out visually, the next step is to getvoice talent. For a number of reasons,it’s likely that the voice actor and theface model won’t be the same person.In this case, it’s best to get the audiorecording out of the way first, and letthe facial actor synchronize his or hergestures to the prerecorded voices dur-ing the motion capture session — inother words, lip sync. If possible, findsomeone who’s done facial motioncapture before, and knows exactlywhat’s expected. Directing the talent toover-exaggerate all motions, includingeyebrow activity, worked well for us.Overacted movements are much easierto remove, modify, or subdue than try-ing to exaggerate a subtle performance.

Because one group of people willproduce the audio and another teamwill work on the motion capture data,


53

F I G U R E 2 . This head was created to get a low polygon count (about 700) and to

limit anomalies when animating. Kelcey Privett created the texture using three

photos and SurfaceSuite. There are few things more frustrating than a face that

almost works.

make sure you chop up the script intosmall pieces. The captures should beshort enough that the talent can easilyperform sections in one or two takes,but not so short that you have millionsof individual captures (note that somemotion capture studios charge by thecapture). One or two sentences per cap-ture seems to be a good rule of thumb.

A good optical motion capture sys-tem — such as Motion Analysis’s sys-tem — lets you trigger a capture from a.WAV file. For example, after we breakup the script into separate audio files,we add three audible beeps one secondapart before the voice recording. Thethird beep is at 500Hz, which activatesthe motion capture. Another 500Hzbeep is played after the actor stops talk-ing, automatically stopping the capturesession. These beeps help the actorpractice ahead of time, and once youget the data back, the audio is alreadymatched up to your capture. This

method saves huge amounts of timelater on trying to synchronize theaudio with the motion capture data.

I recommend that you send your faceactor the script and audio tracks as earlyas possible. It really helps to have somekind of description of the characters youwant them to portray. One of our actorswanted to know a lot about the charac-ters beforehand. Initially, I felt that thisperson was just being diffi-cult. I thought that giving theactor the voice track wouldsuffice. Now that I’ve had achance to look at the motioncapture data, I understand alittle more about the sub-tleties that can make a gestureeither look believable or total-ly disturbing. In fact, now I’deven recommend videotapingthe voice actor’s recordingsessions so the face actor canreview them.

Make Your Face

A dding detail where it’s most need-ed is essential for animating.

Before you create the face mesh, con-sider how your character will animate.This advice may sound completelyobvious, but it’s important to addnonetheless. The fundamental thing toremember is to check all thephonemes, emotions, and properblinking against your model (Figure 4).One good way to do this is have a facecalibration motion capture file, whichconsists of your face actor goingthrough a series of phonemes andextreme facial positions, so you can seewhere your face needs editing. Ideally,in the near future we’ll be using patch-es to animate faces smoothly and to doautomatic levels of detail. Don’t counton your first low-detail head to workwith the captures you get; the initialcalibration is more of a test-and-see-what-works kind of process.

Put the Motion on Your Skeleton

I t would be nice if there were a verysimple way to deform your low-reso-

lution mesh, but there isn’t. Many toolsout there help the process, but complica-tions always arise. We faced a number ofchallenges when we tried to apply ourmotion capture data to our geometry.

First, it became obvious to us wasthat no matter how hard the actortried, the starting position for eachcapture was not constant. Luckily, Iwas working closely with JeffThingvold, chief scientist at Lambsoft,and he came up with a way to create abasis file that allowed us to base a seriesof animations on a given start frame.As long as the markers start in prettymuch the same spot, they will work.


54


F I G U R E 4 . Checking the phonemes to make sure

the face will hold up.

Script/ Storyboards

Voice talent Final Audio

Body Mocap

Face Mocap

Character Concept Sketches

Character Bodies Ready to deform

Character Heads Ready to deform

Generic Conversation

Fidgets

Generic Room Fidgets

Game/Scripting Engine

TWEAK DEPT.

Cleanup

Cleanup

Cleanup

Supervisor Audio Director Choreographer/Director Mocap Studio Modelers/Texturers

Key

F I G U R E 3 . Sample workflow.

The flip side to having complete 3Ddata from a capture is that you need away to separate out the whole head’smotion from the just facial expres-sions. ProMotion can compare thepositions of the markers and subtractthe motion that all markers have incommon so that only the relative facemotion remains. Later, you can takethis whole head motion and apply it toyour neck bone separately.

We had a problem with head shapes.The game characters had differentlyshaped heads, and none of them resem-bled the shape of our face actor’s head.To remedy this discrepancy, we came upwith a bone structure that matched ouractor’s face and linked it to the markers,rather than using the markers them-selves to deform the mesh (Figure 5).Thus, for each head, we just moved thebones to match the face, regardless ofthe polygon count. As a side benefit, wewere able to assign to the markers vary-ing amounts of influence over thebones. For example, some of the motioncapture files had a little too much eye-brow motion. To fix this, I wrote expres-sions for the eyebrow bones that scaledback their movement to a percentage oftheir respective markers’ motions. Hereare some other problems that we faced:EYES. Obviously, we couldn’t place anymarkers on the face actor’s eyelids oreyes. Nonetheless, we found that creat-ing eye blinks was straightforward oncewe got the timing right. Later in devel-opment, we arrayed and moved blinkkeys to more natural positions.

The eyes themselves can be difficultto create at first. Try creating a halfsphere, set the pivot point just a little infront of the center, then assign a “lookat” (how appropriate) controller to theeyes. Another trick that’s helpful is tocreate an invisible target object in thescene a few feet in front of the head,and force the character’s eyes to track it.Once you take the creepiness out ofyour character’s look, it’s extremely easyto adjust where the character looks bysimply moving the target object around. JAW. The jaw is easily deformed bydefining bones that are the length ofthe jaw bone. Their pivot pointsshould be where a jaw’s joint actuallyis (directly below the ears), with expres-sions or controllers that point themtowards the chin.MOUTH. We had problems moving themouth; the face model would tear in

between the bones.We solved the prob-lem by creatinglonger bones andsetting their pivotpoints close to thecorners of themouth. Next, weassigned a “look at”expression to thethe next closestbone to the centerof the lip. This struc-ture assured asmooth continuitybetween the bones and prevented thegeometry of the mouth from tearing —even in extreme circumstances.

It’s Not in the Game Yet

W e spent most of our time clean-ing up the motion capture data

and applying it to the geometry. At thisstage, you’ll find out how well youplanned. The clean-up and applicationof data requires a few people (affection-ately called the Tweak Department inFigure 3), who are typically animators.These individuals need a very highthreshold for pain. Tweaking anima-tion data isn’t the most glorious job,but it is a very necessary productionstep that requires hard work.

If you’ve never worked with facialmotion capture before, I suggest con-ducting the following test. First, go to amotion capture studio and spend a daycapturing facial animations. Have yourteam clean up the data and apply it toyour skeleton. See how well the datadeforms the face, and then put it allinto your game engine. Document howlong each step takes and how much itcosts. This practice will give you(and/or your boss) an idea of how theprocess works and what it involves.

This Is Not a Postmortem

I t’s difficult to figure out a reason-able solution for facial motion cap-

ture. After attending several SIGGRAPHtalks earlier this year on the subject, Isuspect that many left more confusedthan when they arrived. Furthermore,as you research the pros and cons ofmotion capture, almost invariably thebulk of your information comes from

someone attempting to sell you somevery expensive hardware or software.The hardware people will try to con-vince you that you need to spend bigbucks on a new optical system, whenall you need are some generic motionsthat you could buy from House ofMoves. On the other hand, motioncapture studios aren’t always clearabout their pricing schemes.

The bottom line is that regardless ofthe amazing hardware and softwareyou use, everything rides on youractor’s abilities. The acting is what theaudience sees. You don’t want to spendany time covering up bad acting —make sure the moves are right beforethe reflectors leave the face. Today, ofcourse, the tools affect the outcome ofa motion capture shoot, and I look for-ward to the day when the actors are incharge and the motion capture toolsare an afterthought. ■


55

F I G U R E 5 . The markers on the face, the bone structure at

a neutral pose, and the combination of the bones and

markers.

Lambsofthttp://www.lambsoft.com

Platinum Pictureshttp://www.platinumpictures.com

Kaydarahttp://www.kaydara.com

Adaptive Optics Associateshttp://www.aoainc.com

Motion Analysishttp://www.motionanalysis.com

Vierte Arthttp://www.vierte-art.com

Techimagehttp://www.techimage.co.il

Sven Technologyhttp://www.sven-tech.com



56ANITARIUM is an original adventure game filled

with madness, delusion, and personal anguish. The

same can be said for the development cycle.

SANITARIUM was developed by DreamForge

Intertainment Inc., set in the heart of

Greensburg, Pennsylvania. DreamForge employs about

45 people working on three to four projects at a time. We had

previously developed an adventure game entitled CHRONOMASTER, and

our staff has a strong background in the development of computer

RPGs. SANITARIUM was a landmark game for us, primarily because the

project originated in-house,

and we had so much of our-

selves invested in it.

b y C h r i s P a s e t t o

SSDreamForgeÕsSANITARIUM

P O S T M O R T E M

Chris Pasetto is the co-writer of SANITARIUM. He can be found at your neighborhood bar, wearing a kimonomade out of a Dukes of Hazzard bedsheet and repeatedly screaming, “These are not my pants!” He can nei-ther walk nor chew gum. He can be reached via e-mail at [email protected].

57


The Designers’ Tale

S ANITARIUM was born of a simple desire to create some-thing special, something different. About two years ago,

a few of us at DreamForge were feeling burnt out. We weretired of bandwagon games, eager for a fresh concept that wecould dig into with enthusiasm. Most important, we wantedto make a fun game with substance and soul.

So, over some lukewarm cheeseburgers, Chris Straka(Director of Creative Development) asked Chad Freeman(Lead Programmer), Jason Johnson (3D Art Coordinator),Mike Nicholson (Lead Art and Design), Eric Rice (ArtDirector), and Tracy Smith (Post-Production ArtCoordinator) what games they liked and why. Ideas wereoffered, counter-ideas brought forth, cheeseburgers grewcold and at times were nibbled upon. We discussed otherforms of entertainment that would pertain to the game wewanted to make. Movies such as Jacob’s Ladder, Seven, and 12Monkeys were mentioned repeatedly, television shows suchas The Outer Limits and the original Twilight Zone episodeswere discussed. At a certain point in the discussion, itbecame clear that we wanted to make an adventure game.

However, predictably, each of us had his own ideas ofwhat the game should be about. Once the sound of humanheads cracking together reached a deafening pitch, ChrisStraka suggested that we make a game incorporating all ofthe ideas. He drew a crude wheel on a piece of paper, with acentral hub and spokes radiating outward. The spokes wouldeventually become the diverse worlds within the game. Thehub, that all-important plot framework that linked thoseworlds, had yet to be decided upon. Soon we realized thatthose separate ideas could be played out as psychoticepisodes seen through the eyes of a mentally disturbed char-acter. From that point on, the project was code-namedAsylum. This would have been the game title, but we laterdiscovered that the name was in use elsewhere. Hence thegame was called SANITARIUM.

Once the design process started in earnest, we hadSANITARIUM on the brain twenty-four hours a day. Each of usput a lot of fist-clenching, heart-soaring, spleen-churningeffort into the project. It was a rewarding process for us,because most members of the team were new to the designexperience. Sometimes at the end of the day, loose endsremained — questions regarding some story element orproblems with the configuration of a certain puzzle. Many awide-eyed game designer went to bed with visions of gar-goyles and deformed children dancing around his head.When morning came, new angles and twists would revealthemselves like spirited flashers in the dawning sun.

We knew that we were on to something good. Though thecore story was an afterthought in those original design meet-ings, we were determined to create a main plot line that heldthe game together and evoked strong emotions in the play-er. Working from disparate design notes, Mike Nicholson,the art and design lead, assumed the monumental task ofscripting the game dialogue and creating the dialogue trees.As if he’d been suddenly transplanted into a Roger Cormanmovie, Mike quickly found himself neck deep in awkwardlines and weak characters. After several days of confusion, herealized that the problem resided in the game worlds them-selves. They had no true history, thus making it impossible

to create detailed, realistic dialogues for the worlds’ inhabi-tants. He went back to the design document and wrote back-ground stories for each of the worlds, fleshing out the under-lying themes and character motives, and smoothing overany inconsistencies. Mike also pushed the Sarah/Max con-nection and drafted the infamous “death scene.” When heread his proposal to the design team, three of them nearlycried. With a concrete story in place, the characters all hadrich backgrounds from which to draw and the same refer-ence points to which they could refer. Scripting from thatpoint on became relatively easy.

After Mike put together a rough draft of the script,DreamForge hired Chris Pasetto as the project’s writer. Hisprimary responsibility was to refine all character and cine-matic scripts. As the development process went on, thescripts became more complex (as we noticed things we’dmissed) then simple (as we tried to streamline the dia-logues). Eventually, the script files looked like a slaughter-house — tatters of butchered text casually strewn about likesoggy meat by-products.

To maintain a consistent flow of game play and story,Chris had to balance the amount of dialogue that occurred

The original SANITARIUM design team: (left to right) Eric

Rice, Jason Johnson, Mike Nicholson, Tracy Smith, Chad

Freeman, Chris Straka, and Scot Noel. (The author is off to

the side, chasing squirrels.)

DreamForge Intertainment Inc.Greensburg, Penn.(724) 853-0200http://www.dreamforge.com

Team Size: 37 men and women who no longer feel any painRelease date: March 1998Time in Development: 16 monthsCritical tools: 3D Studio MAX, Adobe After Effects, Adobe

Photoshop, Adobe Premiere, Cool Edit Pro, DeBabelizer Pro,FileMaker Pro, Inprise’s Delphi, Inprise’s Paradox, MicrosoftProject, Microsoft Word, Smacker video codec, Sound Forge,Strata MediaPaint, Visual C++, Visual SourceSafe.

Target platforms: Windows 95

SANITARIUM

during any one non-player characterinteraction with how NPCs were dis-tributed throughout the levels. Duringbeta testing, testers complained thatmany of the dialogue interactions weretoo long and that the keyword-basedinteraction trees were sometimes toocomplex. In addition, characters couldend up talking about subjects thatseemed strangely out of order, jumpingbetween disparate topics like a badnews segment. Since a lot of us heretend to work that way anyway, wedidn’t find it too confusing.

Travis Williams, our executive pro-ducer, insisted that we trim some ofthe encounters and link many key-words together to prevent confusion. Alot of the original dialogue was purelyatmospheric and time-consuming forthe player to wade through in search ofreal answers. The final version had animproved narrative flow and betterpacing through a balance of dialogueand action.

We were constantly concerned thatthe emotional content of the gamewould be lost in the medium. Our goalwas to give the player the creeps. Wetook the time to think out what wewanted the player to feel on each level,what message and mood we wanted toget across. Our efforts in creating acohesive atmosphere included not justa good storyline, but an immersiveaudio experience as well.

SANITARIUM was DreamForge’s firstproduct to utilize stereo sound. Thepoint-sourced sound system made forvery natural-sounding effects withineach level. But technology alonecouldn’t make the sound great withoutthe right people to take advantage of

it. Steve Bennet,our music andsound effectscomposer for theproject, did someawesome workwith the sound-track. Workingfrom lists gener-ated by thedesign team,Steve searched ahuge sound CDlibrary for thenecessary effects.Then heprocessed the

sounds using CoolEdit Pro and Sound Forge, sometimesworking over a sound effect multipletimes to match the atmosphere of thelevel. The moody music he added,entirely original compositions createdon a Kurzweil keyboard, brought a def-inite style to the levels that enhancedthe creepy atmosphere.

Nonetheless, the voice actingshould have been better. It’s difficultto compete with other developers whohave access to nameactors and meet every-one’s expectations. Thisisn’t an excuse, but a sim-ple matter of economics.Would we have liked tohave, say, James EarlJones for the voice ofMorgan? Of course. Butwith 80 NPCs and a limit-ed budget for voice act-ing, big-name actors werean impossibility.

The final hurdle in thedesign process came fromour publisher. Late in theproject, during beta test-ing, ASC Gamesapproached us with a sig-nificant design change.Dave Klein, the presidentof ASC Games, was whole-heartedly behind the pro-ject and loved our game.But… “Could you make iteasier to play?” Heexplained that ASCGames wanted SANITARIUM

to have mass-marketappeal and to be accessi-ble to everyone, not justadventure game players.

Our faces turned Barney-purple withindignation. We felt that such a movewould both compromise the game’ssophistication and seriously jeopar-dize our completion of the project.We were a few weeks away from thefinal ship date and being asked toundergo a major revision of our basicapproach to the game design. Also, wewere stubborn.

Travis Williams came out to discusswhat could be done and what couldn’tbe done in a reasonable amount oftime. Our original approach to gameplay could be summed up as, “You’rean adventure gamer. Figure it out.”This new way of thinking forced us toask hard questions, such as, “Where inthe game is this information conveyedto the player?” In many cases, it sim-ply wasn’t. This led to a lot of easyfixes — having the main characterutter a strategically placed bit of dia-logue or even altering existing dia-logue to help the player make puzzleconnections. When this couldn’t bedone without a metric ton of con-trivance, we adjusted the puzzles to bemore user-friendly.


58

P O S T M O R T E M

Admittedly, the changes madeSANITARIUM focus more on entertain-ment than frustration. Players aren’tperpetually stuck on difficult puzzles,so they participate in the story at aconsistent pace and are able to enjoy it.Even the hardcore adventure gameplayers that we initially targeted weresatisfied by the balance of puzzle diffi-culty and richness of story.

The Artists’ Tale

F or all the designers’ concentrationon SANITARIUM’s story, many of the

game elements were conceived in artis-tic terms. We knew that the visualatmosphere of the game would beextremely important to the game play.The art conveyed the emotions thatthe player would feel, as well as theplayer character’s state of mind.Because it’s all about emotions andstates of mind, SANITARIUM is a very art-intensive game. Thus, early in theprocess, the design team spent a lot oftime determining the correct look foreach part of the game.

One of the first things that we didwas to gather reference material. Wewent on field trips to cemeteries, tookpictures of St. Vincent’s Cathedral,and raided local libraries. Eric Riceeven captured a picture of a hauntedgravestone on one of our cemeteryphoto shoots.

Back in the office, the heavy-dutywork was getting underway. From con-cept sketches to full 3D models totouched-up game art, we strove to

maintain thatdisturbing, realis-tic visual style asmuch as possible.

One of the firsthurdles was anaccurate isomet-ric camera view.Finding a way torender six byfour screenwidths of land-scape from twen-ty-four view-points and seamthe shots togeth-er without anyperspective warp-ing was daunting. Tracy Smith workedout the bugs on this one. The finalsolution was to pull the cameras backto what would be the equivalent ofviewing a city block with the Hubbletelescope.

The biggest bottleneck that occurredduring SANITARIUM’s developmentcame during the post-production ofthe art. We call the post-productiondepartment “5D,” not because theyexist on some H.P. Lovecraft penta-dimensional plane, but because theywork on a combination of 3D and 2Dart. Once materials such as screens,characters, and animations pouredsmoothly out of 3D like good scotch,they had to go through the 5D twelve-step program before they would beready for programming.

For the game art, Jason Johnsoncoordinated DreamForge’s art staff asthey used 3D Studio MAX to make the

designers’ vision a reali-ty. The artists retouchedthe 3D background inPhotoshop, then gener-ated a temporarypalette. Still barrierswere clipped in truecolor, then squeezedinto the temporarypalette; coordinateswere determined. 3Danimations underwentalterations, retouches,and special effects asnecessary. The artiststhen composited theanimations into theretouched background.A final palette was gen-erated and applied to all

artwork for any given level. It wastough to create a palette that couldsupport the massive environmentsand all the NPCs. The enormous num-ber of colors used in the game was anightmare for our post-productionteam. Using DeBabelizer Pro, theseguys had to reduce entire levels oftrue-color renders to less than 230 col-ors. At that point, the original artistswould walk over and ask, “Hey, whatdid you do to my level?” or manage-ment would say, “Is it gonna look likethat when it’s done?”

The steps continued. Still barriersin the temporary palette were refor-matted into the new palette.Animations were then clipped andcoordinates determined. Free-walkingNPCs were retouched and clipped.Cursors, icons, and inventory wereretouched and clipped. The playercharacters were put into a 24-colorpalette, retouched, and clipped. Thiswas mind-numbing work at times.Even as brains turned to protein-richpudding and limbs lost all feeling, thegame art was taking shape.

All of this took anywhere from 50 to350 man-hours per level. It was ademanding set of tasks requiring notonly technical skill but the experienceof having worked on games before andknowing how to deliver game art to aprogramming team in a perfectlyusable form. Problems arose mainlydue to inexperience.

The final look and quality of the lev-els and animations in SANITARIUM is atestament to some very determinedartists who stayed late, worked week-ends, and apologized when they weretoo sick to crawl to their desks.


59

The Programmers’ Tale

A t first, we planned to convert anexisting adventure game engine.

Initial prototyping showed that thiswas about as likely as an Oscar nomi-nation for Jackie Chan. So, we set outto create a new engine, re-using exist-ing source code wherever possible. Byusing source code from earlier finishedproducts, we avoided absolutely allbug-hunting hassles. Ha ha. That’s abald-faced lie. But using proven codedid give us less to worry about — weknew it had worked at some point.

The basic engine was completedearly in the project cycle, leaving usplenty of time during the rest of the

project to sprawl in great big chaiselounges and sip tequila from fishbowls.Actually, that’s not true either. Oncethe basic engine was complete, most ofour time was spent on level building. Alevel scripting system based only onactions, flags, and flow control simpli-fied the work. The rest of our time(those hours normally reserved forbasic human functions such as sleep)was devoted to interaction scriptingand special case programming, includ-ing blow-up puzzles and action areas.We had originally planned to create ablow-up puzzle editor, but time did notallow it. Reaching into the wiry guts ofthe beast, we hand-coded each blow-uppuzzle instead.

Deciding on acodec for cut sceneswas like clipping alion’s toenails. Thefirst codec we lookedat, True Motion, pro-vided better visualquality but lackedsupport and ease ofimplementation.The second codec,Smacker, had justthe opposite traits.We couldn’t waitaround for some-body to achieve thebalance of propertiesthat we neededbecause: first, wedidn’t have time;and second, we did-n’t know if anyonewould get it rightany time soon. Thefinal decision camelate in the develop-ment process: sup-port and ease ofimplementationwon out over visualquality.

For SANITARIUM’s bug testing, weentirely divorced ourselves from track-ing bug reports on paper. Both our in-house testers and the test team at ASCGames used FileMaker Pro 4.0 to gener-ate, sort, and track the status of allbugs. Because we were both using thesame software, we were able to tradedatabases with ease, do proper triage,compare priorities, and eliminateduplication. SANITARIUM wasDreamForge’s most thoroughly testedproduct to date.

But even with this extensive testingregimen, the game still shipped withthe infamous “lockout bug” on Level 2.If the player wandered around thetown long enough and fulfilled certainconditions, it became impossible toenter any of the buildings. This was abig disappointment. In the countlessman-hours of testing between ASCGames and DreamForge, no oneencountered this bug. Herein lies avaluable lesson, grasshopper. There issimply no test group more likely tofind a crash bug than those tens ofthousands of initial buyers.

The Sweet

S ANITARIUM represented a signifi-cant success for DreamForge in

several areas. Many of these have to dowith our personal sense of accomplish-ment in making this game, but othersare things we learned along the way.

1.BRING IT ON HOME. As a game thatwas designed in-house, an enor-

mous amount of energy and personalpride went into SANITARIUM. Rememberthat this project began as a few guyshanging out after work saying,“Wouldn’t it be cool if we made thegame that we would enjoy playing?”Even after months of work, we weren’tsure if the game would ever reach theshelves. As the team’s hard labor began


60

P O S T M O R T E M

to bear fruit, the whole company’senergy and enthusiasm grew, sustain-ing us through the crunch periods.That sense of personal ownership in aproduct cannot be underestimated. Itdefined the experience of SANITARIUM

for us as developers.Not only that, but our staff offered

us an inexpensive focus group. Fairlyearly on in the project, the ideas wedesigners had been bouncing off oneanother seemed like stale old super-balls. We needed more outside opin-ions to give the project perspective.We invited small clusters of Dream-Forge employees to join us in thedesign room. Like a nightmare ride atDisney World, we took these groupsthrough the game puzzle by puzzle,plot twist by plot twist. Questions andcomments gave us valuable informa-tion — what looked interesting andwhat seemed confusing.

As a result of those walkthroughs, itbecame painfully clear that Level 6 ofour design just wasn’t cutting it. It wasas though Al Gore had walked into theroom. People’s eyes glazed over at thatpoint in the walkthrough; yawns wereabundant. We looked at each otherand said, “This is not good.” So weasked people, What would be clever,interesting, and creepy? Bugs seemedto be the answer. Based on staff input,the resulting Level 6 of SANITARIUM ismuch stronger and enjoyable than ouroriginal design.

2.HOME MOVIES. From the verybeginning of the development

cycle, we wanted to give SANITARIUM adark, cinematic feel. In most games,the cut scenes are treated like a neces-sary evil or worse — a pageant of plug-ins du jour meant to dazzle viewers anddraw their attention away from thegame play. We were determined toestablish a style for the cinematic cutscenes, to make them an integral partof the game. We especially wanted the

flashback cut scenes to deliver an emo-tional impact to the viewer, becausethey dealt directly with Max’s life, love,and suffering. To support that idea, weshot the scenes to mimic the letterboxlook of movies. Our cinematic coordi-nator, Marty Stoltz, drew upon hisfilmmaking background to guide us inprecise cinematic screen direction. JoeSkivolocke also lent his post-produc-tion expertise to the effects for allmemory cinematics. A lot of work wentinto ensuring correct camera usage andpost-production of cinematic scenes —especially for the flashback sequences,which were meant really to touch theplayer emotionally.

All cinematics came into the worldas storyboards —carefully laid out inAdobe Premiere andpassed on to theartists. The 3D staffworked from story-boards to create raw.AVIs. Our post-pro-duction team workedwith these .AVIs,touching up therough edges andapplying specialeffects using AdobePhotoshop, AdobeAfter Effects, andStrata MediaPaint.Some of the raw .AVImaterial had to bethrown out in theend (because it didn’twork, because some-thing looked wrong,because one of thelighting crew mem-bers was eating asandwich in thebackground). Still,our shooting ratiowas about 3:1 (forevery second of cine-

matic material that we used, 3 moreseconds were tossed out) — that’s pret-ty good when you consider that theaverage movie has a 20:1 shootingratio. The polished cut scenes thatwent into the game were the bestDreamForge had ever produced,anchored thematically by a unique andconsistent vision.

3.MODULAR FURNITURE. We had allworked on other games and were

familiar with the potential threat ofcutting levels, puzzles, and whateverelse seemed expendable when thecrunch was on and no amount ofMountain Dew could keep us going.From the beginning of the design, weprepared for such eventualities by


61

structuring the game in a modularfashion. We constructed the game inportions that would add to game playand advance the story, but wouldn’tdetract from the game overall if theywere taken out. In the end, we wereable to keep the amputations to a min-imum. A big combat zone and someblow-up puzzles took a trip throughthe plumbing, but otherwise the cutswere fairly minor. Modular design atthe start of the project ensured thatthe final game would remain true to itsinitial vision.

4.HEY, NICE ASSETS. As an experi-ment, lead programmer Chad

Freeman implemented an asset man-agement system utilizing a Paradoxdatabase, which centralized all of thegame assets in one place. Tools devel-oped in Delphi and Visual C++accessed the assets from this database.This solution provided several bene-fits. For one thing, we could easilyanalyze the asset data and take appro-priate actions when total asset sizebroke the budget for a level. We couldalso view filenames and descriptionsof individual assets. The database sys-tem let us group assets by levels or byother criteria. A single game level hadhundreds of art and sound files.Searching for a particular asset by thefilename alone would have been theequivalent of finding the fat guy wear-ing the Star Trek shirt at a sci-fi con-vention. Naturally, the ability to sortthrough assets quickly saved time andenergy.

Because this process was experimen-tal, we weren’t able to fully exploit thedatabase system. For example, the pro-grammers were the only ones who uti-lized the system during the level-cre-ation process. However, Chad Freemanwould eventually expand the system sothat artists and sound technicianscould add assets to the database andlevel creators could access them direct-ly from there, eliminating redundantfile storage. In addition, the systemcould also store level information,allowing these same types of reporting,sorting, and other benefits to beextended to the levels themselves.Overall, the development ofSANITARIUM never made full use ofthese database management tools. Asgame content grows larger and larger(DVD and beyond), using databasetools for data storage will help develop-ers more and more.

We also utilized Visual SourceSafefor the first time during SANITARIUM’sdevelopment. Historically, program-mers have been beset with theextremely time-consuming andtedious job of hand-merging code.Never again. Like a divine beam oflight shining into our otherwise dankand shadowy cubicles, SourceSafemade code merging far easier andmore reliable. SourceSafe also hasother benefits, including the ability tokeep a precise revision history of yourcode, so that you can painlesslyretreat from the inevitable “badmove” programming-wise.

We chose SourceSafespecifically because itallowed multiple check-outs;the structure of our C filesprior to adopting SourceSafewas such that it was com-mon for more than one per-son to be working on a singlefile at the same time. Source-Safe also allows a project tobe branched off, letting oneperson work on a demowhile another continuesdevelopment of the game.The projects can later be re-merged, so that fixes in thedemo can be integrated intothe main source.

5.PROJECT MANAGEMENT FOR

THE INSANE. UsingMicrosoft Project and his

own devious tracking tablesprepared in Microsoft Word, projectmanager Scot Noel would recalculateour progress every week to two weeks.This method accounted for theprogress of every single game element,from blow-up puzzles to art fixes tocode implementations. GANTT chartsdemonstrated the flow of workbetween departments and individuals.These enabled us to respond promptlyto the most critical problems by show-ing how the late delivery of a particularasset might throw off the final shipdate by days or weeks.

Critical paths were plotted usingPERT charts in Microsoft Project. Uponseeing these Daedalean webs of near-infinite complexity, many of us feltthat Scot had gone, finally and irrevo-cably, insane. But once we penetratedthe mysteries of the PERT chart, we sawthe value of tracking the sensitiveinterdependencies of tasks throughcritical paths. As different departments,or even particular individuals, caughtup with one another or moved aheadof expected schedules, the critical pathwould change. Armed with this knowl-edge, Scot could walk up to any givenprogrammer and say, “The critical pathfor this game is going right throughyou at the moment.”

Such monitoring helped direct thepressure and motivate the right people,letting others go home and get a goodnight’s sleep. As are all systems, thePERT charts were imperfect. Some peo-ple always seemed to be on the criticalpath, most notably Chad Freeman, the


62

P O S T M O R T E M

game’s lead programmer. All of us hereat DreamForge hope that Chad will beable to leave the hospital soon. Wealready have a respirator set up along-side his desk.

6.PUBLISHER BUY-IN. Our publisher,ASC Games, believed in what we

were trying to accomplish and provid-ed valuable input throughout devel-opment. They behaved as if they werebuying into our vision rather than justpurchasing it. For the most part, theytook a hands-off approach, and onlyrequired changes that they were con-vinced would significantly improvethe quality and salability of the game.Travis Williams, SANITARIUM’s execu-tive producer, put a lot of heart intothe project — not to mention all thecool prerelease games and toys he sentus. We were so grateful, we put hishead in the game.

We were very pleased with ASCGames’ strong commitment to market-ing SANITARIUM. The box is a work ofart in itself, and the rule book hasreceived praise for its strength and sim-plicity. The magazine ads are impres-sive and true to the spirit of our game.One simple act for which the team iseternally grateful: ASC Games’ market-ing department didn’t give away thegame plot on the box or in the manual.It’s always a relief when you don’t seethe central mystery of your game print-ed in big red letters across the back ofthe game box.

The Sour

W hile SANITARIUM represents aphenomenal success for us here

at DreamForge (both professionallyand personally), there were someunfortunate stumbling blocks alongthe way. We keep telling ourselves:that which did not kill us has made usstronger. Never mind the scar tissue.

1.ANIMATIONS. Due to the size of thegame, each character had a limit-

ed number of animation frames. Inmany cases, this caused the movementto look stiff and unnatural. Lookingback on it, we would have preferredsmoother animations with moreangles — especially for the main char-acter, Max. If we had taken this intoaccount earlier in the project, wemight have had an opportunity to fixit. By the time we realized that eight

angles looked a little stiff, it was toolate. The limited angles also causedproblems for players trying to navigateMax through the levels. He’d often getstuck on corners, then either walk inplace like some demented mime orfrustrate the player with a litany of,“Can’t go that way.”

Getting consistent lighting betweenthe characters’ standard animations(status quo, walk, use, and so on) andthe specific animations requiring inter-action with the environment (such askicking in the school door) was anoth-er nightmare. Different artists did theseanimations months apart, and this wasa constant battle from beginning toend. A huge amount of time was spentfixing things as opposed to advancingthe project.

2.COMBAT ZONES. The actionsequences needed more atten-

tion. They were important for guidingthe pace of the story, but didn’t havethe feel that we were after in the endproduct. The original idea behind theseareas was based on one ofDreamForge’s earlier titles, VEIL OF

DARKNESS. It had wonderful combatareas that helped break up the pacingbetween the puzzles. However, inSANITARIUM, multiple factors forced usto water down the combat zones or insome cases cut them altogether. Wehad originally planned a large combatzone for the Hive level of the game.

We’d hoped to make “Grimwall vs. theHive” one of the most fun and integralcombat areas, but it was cut from thegame for various reasons.

3.STURM UND DRANG. When you havea company of forty to fifty peo-

ple, it’s impossible to do anythingwithout rubbing someone the wrongway. SANITARIUM was put together by adesign team that in part came togethernaturally and in part was hand-pickedby Chris Straka, our head of creativedevelopment. Individual employees(usually Chris) designed our previoustitles. But we decided that team designwould be the way to go. While teamdesign has the potential to fracture theunified vision of a game, the variousteam members ultimately complementeach other’s interests and goals, lend-ing more depth to the game. This is anice way of saying, “The team argued alot, but came up with better solutionsas a group.”

Difficulties didn’t end there. OnceSANITARIUM became a full-time project,many staff members complained, “Whydidn’t I get a chance to be on thedesign team?” Quite a bit of frictionwas generated because people felt asthough they’d been snubbed.Unfortunately, a design team reachescritical mass once it has more than sixmembers. Design teams work in muchthe same way as clown cars. Too manypeople cramming themselves into the


63

design would have certainly brought analready volatile process to a grindinghalt. At the same time, SANITARIUM’spersonnel power structure createdinequalities between staff members thatwere never meant to happen.

DreamForge learned much aboutdesign teams from SANITARIUM, andwe’re having great success with thedesign team setup in our current pro-jects. We’ve taken steps to recognizepeople’s desire and initiative, and haveparceled out responsibilities to thoseindividuals willing to take up leader-

ship positions. Now, rather than say-ing, “Why wasn’t I included?” every-one moans, “Why did I get into this?”It’s great fun.

4.LOAD TIMES.While long level load-ing times were an accepted

design limitation from the beginningof the project, a system that could bet-ter manage memory and allow forstreaming of more data from the CDcould have benefited the game. Thetight schedule left such a systemimpossible to pursue. A more sophisti-cated memory-management scheme

could have allowed for shorter initialloading times, larger levels, and so on.

5.NEW KIDS IN THE CUBE. SANITARIUM isa huge game. A lot of people

worked on it, meaning additionalefforts had to be taken to coordinateand organize everyone’s labor.Familiarizing people with the visionof the game from an artistic anddesign point of view was a real chal-lenge. Sometimes, keeping everyoneon the same page seemed to be achore, especially as new people cameonto the project.

A lot of time was spent getting peo-ple to understand the status of theproject and the direction in which itwas headed. A new artist would ask,“Why am I making this one-eyedguy?” and we’d say, “Didn’t anyonetell you?” We made the mistake ofprojecting time schedules as if newhires, following a brief training peri-od, would be as competent as ourmost experienced people. Some ofthose experienced people were per-forming administrative and trainingtasks, and thus weren’t producingmuch art. Art delivered by our newpeople often had problems when itwent to the programmers. This meantdoing things twice, sometimes threetimes. Projections and flow charts sliddownhill, taking into account theflow of asset delivery, identification ofproblems, correction of problems, andre-implementation of assets. Since artdelays were slowing down program-ming, we tried to use temporary art.This didn’t work out because creatinguseful temporary art for the program-mers proved to be nearly as time-con-suming as the real thing. And just tothrow a little cherry on top of thethree-layered cake of delays, we losttwo artists during production.

Even though SANITARIUM had alonger production time than any pre-vious DreamForge project, there werestill some things that we would haveliked to tweak or add to make it bet-ter. As it was, we went through a lotof crunch periods in order to getthings done on time. The sheeramount of artwork required for thegame nearly overwhelmed us.Unfortunately, due to the nature ofthe game, delays in artwork had asnowball effect because the levelimplementers needed the actual art-work in order to set up their levels. ■


64

P O S T M O R T E M

NT Workstation may cohabitate witheither Windows 95 or Windows 98, buthave you tried getting Windows 95 andWindows 98 to live together? Don’tbother trying — it’s not going tohappen.

So, how can a meager gamedeveloper have access to lots ofoperating systems and multipletest beds on a limited budget?The answer is: images! Thereare several products nowavailable that will giveyou the ability to make asector-by-sector image ofa hard drive and/or harddrive partition. Here arethe two with which I ammost familiar:•ImageBlaster. A module in

Rapid Deploy by Keylabs’new spin-off software company,Altiris (Preferred Product mention inthe 1997 FLA Awards). http://www.keylabs.com/software/rdeploy/index.htm.

•Ghost. (Which we recently purchased).By Symantec. http://www.symantec.com/sabu/ghost/index.html. Pricing for these products is based on

a sliding scale that takes into accounttheir usage, so it’s best to contact thepublisher’s sales team for pricing. Thesemanufacturers gear their products moretowards the hardware builder whobuilds several computers with the exactsame components. However, theseproducts are a dream-come-true forquality assurance test labs who need tomaximize their budget dollars in order

to test a wide variety of operating sys-tems and installation scenarios.

Let’s take the typical game develop-ment test lab as an example. If they’relucky, they have 15 to 20 testmachines. (Hey, I said “lucky.”) They’vedone their best to amass the widestvariety of hardware components possi-ble within these 15 to 20 machines. Butwith such a relatively small number ofmachines, it’s impossible to have everypotential configuration.

In terms of operating systems, a testlab needs Windows 95, Windows 98,and Windows NT 4.0. But rebuildingeach system every single time thoseoperating systems need testing con-sumes hours and hours of labor time,and completely obliterates productivi-ty. (The preceeding list of operating sys-tems doesn’t even take into account the

imminent release Windows NT 5.0, andthat all games currently in testingshould be tested on the version of thatsystem as well.)

The biggest obstacle to adopting anImaging QA Test Bed System

(IQATBS) thatI’ve heard is “We can’t

afford it.” My answer to thatis “You can’t afford not to!” Take a

look at Tables 1 and 2 (see page 71).With these estimates, there is one

image for each machine, and room toadd several more images for eachmachine at the cost of approximately$45-$49 per image (including labor,image licenses, and materials). Now,where are the savings?

Compare those costs to the testingtime lost by constantly rebuilding sys-tems to recreate usable test beds with-out stored images, or the costs of buy-ing enough hardware to have a separatemachine for each scenario. And don’tforget that those systems would need tobe rebuilt every time the test bed isaltered by the installation of a newbuild. Let’s look at a testing scenario asan example. It takes place in the sameten-computer lab, and involves testingone station with eight operating sys-tems over the course of one week. We’llcompare the costs and productivity ofworking with rebuilds vs.

Continued on page 71.


72

b y J e a n n e C o l l i n sS O A P B O X

Turbo-Charge your Test Lab

L et’s face it, Microsoft may have a corner on the

operating system business, but that doesn’t

mean we have any fewer operating systems or

software configurations to support.

Jeanne Collins is a quality assurance manager at GTE Internetworking. She is some-times referred to as a “self-proclaimed evangelist for quality assurance in the gamingindustry.” Send her feedback at [email protected].

S O A P B O X


Continued from page 72.

working with images. This scenario isrepresented in Table 3.

By comparing the figures in Table 3,you can see that the cost differencebetween rebuilds and images amountsto a total savings of $306.68 for justone machine in one single week. If allmachines could be tested with eightoperating systems, the savings wouldbe $3,066.80 in labor alone for oneweek. Using the CD-ROM methodwith existing CD-ROM masteringequipment, just two workstationsnearly pay for the setup expense in aweek. Not to mention the savingsgained by not purchasing duplicate

hardware that will become obsolete inanother month.

These are elementary figures basedon sequential work. When a system isrebuilt manually, the employee mustsit in front of the machine to be avail-able to answer installation questions.With images, employees can start a re-build and move to the next machine,and the next, and the next. Also con-sider the flexibility of building testbeds for each scenario when testing dif-ferent drivers for the same video card.The possibilities are endless. Put yourown scenario in here and see if usingthe IQATBS method wouldn’t save youtime and money in your labs. ■

Task Unit Cost Total CostNetwork cards for each system $50 each $500

Imaging software license per machine $30 $300

Boot floppies $1 $10

Labor to setup and image ten systems $40 $400

CD-ROM Media $5 $50

Total Setup Cost $1,260

TA B L E 2 . The cost of setting up a CD-based imaging system useing existing CD-

ROM mastering equipment and temporary space on existing network.

OS Tested Time for Cost of Time for Cost ofrebuilds rebuilds images images

Windows 95 Gold 4:00 $40 0:10 $1.67

Windows 95 SR2 4:00 $40 0:10 $1.67

Windows 95 Plus 4:00 $40 0:10 $1.67

Windows 95 SR2 Plus 4:00 $40 0:10 $1.67

Windows 98 Gold 4:00 $40 0:10 $1.67

Windows 98 Plus 4:00 $40 0:10 $1.67

Windows NT 4 4:00 $40 0:10 $1.67

Windows NT 5 BETA 4:00 $40 0:10 $1.67

System Total 32:00 $320 1:20 $13.32

TA B L E 3 . Testing one station with eight operating systems in a week from the

ten-computer lab. A comparison of costs and productivity.

Task Unit Cost Total Cost9GB+ hard disk space on the LAN $1,000 each $1,000

Network cards for each system $50 each $500

Imaging software license per machine $30 $300

Boot floppies $1 $10

Labor to setup and image ten systems $40 $400

Total Setup Cost $2,210

TA B L E 1 . The cost of setting up a network-based imaging system with ten exist-

ing test machines [labor at $10/hour, imaging software at $300 for ten station

licenses, and all system builds at 4 hours].

Date post:	28-Jun-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

NOVEMBER 1998 - twvideo01.ubm-us.nettwvideo01.ubm-us.net/.../GDM_November_1998.pdf · the second...

Documents