december/january 1995twvideo01.ubm-us.net/.../GDM_DecJan_1995.pdf · 2 GAME DEVELOPER • DECEMBER/JANUARY 1995 GGAMEAEM Editor Larry O’Brien [email protected] Senior Editor Nicole

december/january 1995

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

In the end, I didn’t even have achance to light my pickle. In mybest shot yet at Andy Warhol’spromised 15 minutes of fame, Iblew it, but it all might have beendifferent had they just given me thechance to demonstrate to the worldthe miracle of the electric pickle.I’m often the target of joke e-mails

purporting to be from various people,but I couldn’t dismiss the one purport-edly from Danny!, the daytime talkshow. Danny! (exclamation pointmandatory), of course, is a vehicle forDanny Bonaduce, who, if you’re a cer-tain age, you’ll remember as the red-haired and mysteriously edgy moppetfrom The Partridge Family.

Danny Who?Yes, The Partridge Family, a show thathas been strangely unwelcome in thecurrent “rediscovery” of the 70s. Unlikethe Brady Bunch, there’s been no Par-tridge Family movie, no stage produc-tions, not even a regular slot on Nick atNight. Why? Because the Bradysplayed to the status quo, then andnow—sprawling suburban house, ser-vants, an affluent and secure whitebreadhome in which sons and daughters hap-pily embrace the bourgeois.

The Partridges, on the other hand,were darker. In the cluttered, claustro-phobic garage in which they practiced,they gave birth to songs, not about“Sunshine-y Days,” but about doubtsand fears. “Stop! I Think I Love You”?Why couldn’t he be sure? What wasDavid Cassidy saying? That corporateAmerica, by co-opting the language ofromance, had stolen the emotionalcompass to the point where none of us,in fact, could go forward with confi-dence. The Bradys on the other hand,told us that, “When it’s time to change,you have to rearrange who you are and

what you want to be.” Sha-la-la,indeed.

The Bradys had station wagonsand convertibles, symbols of consump-tion and status. In contrast, the Par-tridges had that most poignant of allsymbols of freedom from the statusquo—a schoolbus with birds painted onthe side.

Where the Bradys had an emo-tionally stunted servant woman in Alice(why did she need Sam the Oh-So-Blue-Collar Butcher to validate herworth?), the Partridges portrayed amuch more complicated world, inwhich one has to dance with the capi-tal ist devil even as one decries itsexcesses. This complex enigma wasembodied in the work of one actor—the young Danny Bonaduce.

So, of course, I returned the call.

A Genius and A SCUBA Master?There was to be a show on brains vs.brawn, and my pro-nerd work over theyears had not gone unnoticed. “Whatmakes you think you’re so smart?” theyasked me. “I don’t think I’m smart,” Ianswered, “I just edit a magazine forsmart people.” “It’ll have to do,” decid-ed Producers Julie Knapp and RitaWhack. “What can you do for the tal-ent competition?”

My immediate answer: “Program acomputer faster than anyone who’s bet-ter, and better than anyone who’sfaster,” drew a stony silence. I triedsports: “Throw a Frisbee-brand flyingdisc 120 yards fairly accurately?” Not ina studio. “Hold my breath while wear-ing diving gear?” Not exactly rivetingtelevision. “Ride a mountain bike over amoderately sized stick?” Stony silence.“I can juggle a little. Just three balls,though.” There was a long sigh and Icould hear the sound of a hand rubbing

The Dark ofthe Electric Pickle

G A M E P L A N

2 GAME DEVELOPER • DECEMBER/JANUARY 1995

MGA EGAME

Editor Larry O’[email protected]

Senior Editor Nicole [email protected]

Managing Editor Nicole [email protected]

Editorial Assistant Deborah [email protected]

Contributing Editors Alex [email protected]

Barbara [email protected]

Chris [email protected]

David [email protected]

Editor-at-Large Alexander [email protected]

Cover Photography Charles Ingram Photography

Publisher Veronica CostanzaGroup Director Regina Starr Ridley

Advertising Sales Staff

Western Regional Sales Manager

Steve Nikkola (415) [email protected]

Promotions Manager/Eastern Regional Sales Manager

Holly Meintzer (212) [email protected]

Marketing Manager Susan McDonaldAdvertising Production Coordinator Denise TempleDirector of Production Andrew A. MickusVice President/Circulation Jerry M. OkabeGroup Circulation Director Gina OhGroup Circulation Manager Kathy HenryCirculation Manager Mike PoplardoNewsstand Manager Debra CarisReprints Stella Valdez (916) 729-3633

Chairman of the Board Graham J.S. WilsonPresident/CEO Marshall W. FreemanExecutive Vice President/COO Thomas L. KempSenior Vice President/CFO Warren “Andy” AmbroseSenior Vice Presidents David Nussbaum, H. VernePacker, Donald A. Pazour, Wini D. RagusVice President/Production Andrew A. MickusVice President/Circulation Jerry OkabeVice President/Software Development Division ReginaStarr Ridley

Miller FreemanA United News & Media publication

a forehead. “Bring your SCUBA gear.We’ll figure it out.”

Breaking deadlines left and right(sorely testing the good humor of manag-ing editor Nicole Claro and, over at Soft-ware Development, Barbara Hanscome),my wife Tina and I flew out to ChicagoThursday night, the night before the tap-ing. Impressive as it was to be picked upat the airport by a limousine, it was lessimpressive that the driver had lost the carin the parking structure, missed the exitfrom the airport, and got lost again on theway to the hotel. I mean, I don’t knowChicago, but does it normally take twohours to get from O’Hare to Evanstonwith no traffic?

Three-and-a-half hours of sleeplater, it was time to get up and get tothe studio. Finally, I would know ifgreen rooms were really green and iftelevision sets had as much good foodas movie sets. Tina and I debatedwhether I should drink two or threecappucinos to give me a little bounce orwhether the resulting quaver in myvoice would come across bad on televi-sion. I didn’t have the choice. By thetime I got to the (not) green room, Icouldn’t even find real cream for thedregs of a pot of Maxwell House coffee.

Show Us Your PickleI was introduced to my fellow “brain”team members, and it was here thatthings started falling apart fast. Aftermeeting Alan, the systems analyst, andCharles, the biochemistry graduate stu-dent, I was introduced to Quentin andGary, two stand-up comedians whowere planted in our panel apparentlybecause the producers weren’t sure we’dbe amusing enough. Quentin wouldeventually “win” as the most interestingof our team, despite the fact that his“talent” was telling an offensive jokethat was stupid when Eddie Murphyfirst told it 10 years ago. With hischunk-gold jewelry and mock inner-city speaking cadences, this guy waspopped straight from the Play-DohCreate-A-Comic kit. When he finallygot on TV, the first words out of hismouth were, I swear to God, “Hey,how y’all doin’? Some fine-looking

women in the audience here!” Then, toput the audience in stitches, he actedeffeminate and waggled his tongue sug-gestively. Quentin had appeared onseveral talk shows, which is apparentlywhat young comics do nowadays ratherthan actually develop a witty routine.

Still, the stand-up comics at leastknew the talk-show drill, which gavethem a distinct advantage over me. I’dbrought some skin diving gear but had

no idea what to do in it. I gave somethought to duct-taping my mouth andnose shut and doing push-ups to showthat one could be fit without beingbulky, but I didn’t even know if the pro-duction staff could find duct tape in thefew remaining minutes before tapingtime. It was then that I was saved by theelectric pickle.

One of the guys replaced by theidiot comics was willing to lend me hispickle and a lamp cord. As I’m sure youknow, when 110 volts of alternating cur-rent flows through a pickle, the result is acoronal discharge that dances like greenneon, what the Romans would havecalled an aurora cucumeralis if only they’dspent a little less time building aqueductsand a little more time installing cheap,universal electrical service.

So I reported to the backstage areanewly charged with confidence. Thereare few things that one can know withmetaphysical certainty, but one is thatelectrifying a pickle on national televi-sion would be a “grabber.” It’s got allthe elements of great drama: surprise,danger (electrocution and explosionbeing distant, but real, possibilities),and visual appeal that can’t be beat.

Then, sad to say, it all came apart.Intimidated by the jeers of the crowd,tongue-tied by the insistence of thestaff that I “know what you’re going tosay before you go out,” tired and crankyfrom lack of sleep, I went on and, in aword, bombed. I was asked to stepaside, to support my team, to be seen,perhaps, but not heard. And then itwas over. The judges decided that Jose,one of the “Macho Maniacs,” was themost interesting of us all, a decision Icouldn’t disagree with, based on whatmade it onto television.

But I can’t help but think whatmight have been. I can’t help butdream of the electric pickle. ■

Larry O’BrienEditor

When Larry O’Brien is not singingBrady Bunch and Partridge Family tunes,he can be found at Game Developer mag-azine or attempting to electrically chargevarious vegetables.

G A M E P L A N


The Partridges

were darker than

the Bradys and

sang songs about

doubts and fear.

“Stop! I Think I

Love You”? Why

wasn‘t he sure?

What was David

Cassidy saying?

Gaming forThe Fun of It??

S E Z U !

Dear Editor:

Ijust have to say I really enjoy your maga-zine. I’ve made a living doing defense andcommercial product design for many years

and have only now gathered the resources todo what the majority of your readers arealready doing—creating games! I’ve testedthe waters by doing game-testing, consult-ing, manual design, editing and much play-ing. Now I’m ready to see if my hare-brainedideas will sell!

I enjoyed Barbara Hanscome’s “Gamin’ forGrrrrls” (Chopping Block, Oct./Nov. 1995).Despite the fact that boys and girls do havediffering tastes, we are after all, both humanand have that much in common. We like to beentertained, challenged, amused, thrilled,and teased. Boys don’t necessarily needblood and violence, and girls can live withoutcute, fuzzy animals. My sons not only like thebackground sound in games, they thrive onit! In addition, my 8-year-old plays all four ofthe characters in Street Fighter 2, includingthe girl (she has “neat powers”)!

I believe we can most easily find commonground by examining games of the past, inaddition to perennial favorites. I have noticedthat both sexes really get into games that letthem insert their own personalities. Role-playing games let players of either sex usetheir unique strengths. Hey, men like a goodgame of chess, yahtzee, cards, and so on–noreal violence there. My point is that I honestlythink these big game companies are tryingtoo hard and maybe they should consult with

some adults who have enjoyed gaming for thefun of it.

Randall G. ArnoldCoppell, Texas

WAIT A MINUTE, MR. POSTMANWAIT A MINUTE, MR. POSTMANDear Editor:

Please stop calling the postal service’s uni-versal access, low technology, informationtransfer media snailmail! Remember, only

10% of the U.S. population is on the Internet atthis time. The rest of them still need to movephysical objects around at the universal cost of32 cents per ounce.

Jason FeinmanVia e-mail

Dear Editor:

How come you don’t put articles online,thereby saving trees and many post offi-cers’ backs? I know money is a concern,

but can’t you just stick the advertisers’ ad inthe articles? I promise to be subliminallyaffected by their ads.

Andrew ShebanowVia e-mail

Editor Larry O’Brien responds:After receiving the preceding disturbinglyangry letter from a postal carrier in response toour referring to ground mail as “snailmail,”we’re not about to become even more of a tar-get by throwing hundreds, maybe even thou-sands, of carriers out of work.


SAY IT !SAY IT !The shady staff of Game Developer would love to hear your comments, questions, and suggestions! Please send them to: GameDeveloper magazine, Sez U!, 600 Harrison St., San Francisco, Calif., 94107. For those of you who do have access to the Inter-net, send e-mail to [email protected] or go to the Game Developer web site at http://www.mfi.com/gdmag. Thanks!

GIMME MORE!GIMME MORE!

Dear Editor:

I’m a big fan of your magazine, and I’m gladto see you’ve lowered the price. I thought theOctober/November 1995 issue was your best

yet. Mike Michaels’s “Organizing User Input,Part I: The Input Queue Manager and KeyboardEvents” was very well written and informative.I do have a suggestion, though: I’d really liketo see more information about game industrysales figures and other market data. Unlikeother PC application categories, game salesinformation is very hard to come by. I’d like toknow how well games sell, what the total mar-ket size is, what typical budgets for games are,and how game developers make their money.After all, being a game developer isn’t simply amatter of hacking out code–you’ve got to sellthose games too. Thanks.

Andy ShebanowVia e-mail

LITTLE NIKKILITTLE NIKKIDear Editor:

Iwas walking down the street the other day

just minding my own business when thiswoman ran into me and knocked me into

moving traffic. Now, I was quite upset untilshe said she worked on this game maker mag-azine or something, and gee didn’t that soundinteresting, and, well I guess I could forget thewhole incident if she would send me a copy ofwhat sounded like a great read, but I neverheard from her again. I thought she said hername was Nakita Freeman or something, so Ilooked up game stuff on my groovy web brows-er and there’s someone on your staff namedNicole. I thought she might be working thereunder an assumed name or something. I don’tcare so much about the magazine anymore,

but I just wanted to warn you that there’s awoman on your staff who doesn’t look whereshe’s going on the busy sidewalks of San Fran-cisco.

Enrique HombrelibreVia e-mail

Contributing editor Alex Dunne responds:Thanks for the note. We’ve taken care of NicoleFreeman, a.k.a. “little Nikita.” She travels undera variety of assumed names, especially wheninvolved in covert pedestrian-bumping opera-tions. Rest assured that everyone on our staffwas alerted to her slip-up and that she will beseverely reprimanded! It’s slip-ups like this thatcan devastate a little magazine like ours.

This month, our

readers have much

to say about gender

differences, the

postal service,

and suspicious

encounters with

the staff of

Game Developer

magazine.

Our Readers

GAME DEVELOPER • DECEMBER/JANUARY 1995 7

E R R AE R R A TT AA

Quality is job one here at GameDeveloper magazine. We strive tocorrect any mistakes we’ve made

to provide you with best product wecan. That said, we lower our headsand admit to the following two mis-takes.

•In Mike Michaels’s Oct./Nov. 1995feature article “Organizing UserInput, Part I: The Input QueueManager and Keyboard Events,” weleft out Listing 3, HEAPMGR.C.

•In “Getting Started with VESA” byMatt Pritchard (June/July 1995) partof the code in Listing 2, VESADE-MO.C, was omitted.

You can access each of these listingsin its entirety (as well as all refer-enced code from previous issues) onthe fabulous carousel that is theGame Developer ftp site.

A HardwareSpec forGames

The standards specifi-

cation under discus-

sion at the Game PC

Consortium is a hot

topic these days. So

hot, in fact, that we‘ve

got the results of the

vote in this month‘s Bit

Blasts (we are so on

top of things).

Alex Dunne

C R O S S F I R E


Last issue, I examined theGamePC Consortium’s(GPCC) efforts to puttogether a benchmark forthree-dimensional graphicsperformance. The GPCC is ayoung organization compris-ing hardware and software

vendors in the PC game industry. Theconsortium was formed to target thevacuum in PC game standards throughthe creation of the GamePCspecification—an all-encompassingGamePC standard similar to the Mul-timedia PC (MPC) specification. Thisstandard is a tough nut to crack, notmerely because of the technical hurdlesthat have to be cleared, but because of

inter- and intracompany politics thatcan hold back rapid adoption of a stan-dard. The three-dimensional graphicsbenchmark I described last issue ismerely one component of this proposedspecification.

StandardizingGame HardwareLike the MPC certification, which iscontrolled by the Software PublishersAssociation’s Interactive Multimediasection, the GamePC certification willprovide a way for consumers to deter-mine the minimum hardware theyneed to enjoy their software purchas-es. It will also help the game develop-ment community develop and market

The GamePC Consortium’s specification for gaming hardware will be implemented as aseal of approval, indicating the type of hardware recommended for game play. Theselogos are still in the design stages.

games because a common level of gameperformance will be expected from thehardware.

Why not simply use the MPCstandard for games? It doesn’t go farenough. For instance, a graphicallyundemanding and processor-friendlygame of the Myst variety would do fineusing the MPC3 specification. A gamethat required a bit more horsepowerunder the hood—perhaps Dark Forcesor Wing Commander 3—would need aspecification that provided for a fasterprocessor, graphics, and perhaps betteraudio as well. Further down the road, asgames demand more sophisticatedhardware, the specification can beupdated or higher levels of the specifi-cation can be created.

The MPC SpecTo see how the GamePC specificationwill be used, look no further than theMPC certification as a model. TheMPC specifications (there are three lev-els—the higher the number the morecurrent the specification) dictate theminimum processor, RAM, hard drive,floppy drive, CD-ROM drive, audio,graphics performance, video playback,user input, I/O, and system softwarepresent on a PC. In addition, the MPCWorking Group provides a test suite onCD-ROM, written by the NationalSoftware Testing Laboratories, forestablishing whether a computer isdelivering MPC3 compliance in the keyareas of processing speed, video play-back, graphics performance and audio.Hardware vendors are required topass the test suite in order todisplay the MPC mark ontheir products. In 1994,the MPC1 MPC2certification markswere extended to indi-vidual CD-ROM dri-ves and sound cards,and in 1995, the MPC3mark was extended tovideo playback boards andspeakers.

Because the MPC standard wasdeveloped years ago, it has alreadystaked out much of the territory that

the GamePC Consortium roams. Cre-ating another specification that dictatessimilar—but not identical—require-ments as the MPC specification willonly confuse consumers. To avoidduplicity or conflicts between the certi-fications, the GPCC has decided tobase the GamePC specification oneither the MPC2 or MPC3 specifica-tion and build on those requirements inareas specific to game play. (You canfind a thorough description of the vari-ous MPC requirements on the WorldWide Web, at http://www.spa.org/-mpc/default.htm.)

As a result, the GamePC specifica-tion will rely to a large degree upon oneof these two MPC levels as a baseline.In theory it’s an excellent plan—con-sumers won’t have to worry about con-flicting requirements in the two specifi-cations. With a little collaboration, thetwo standards organizations should beable to effectively update their specifi-cations on a regular basis without step-ping on each others’ toes. However,there are some parts of the GamePCballot that risk conflict with the MPCspecification.

Turning Suggestions into a BallotThe following items present in theGamePC specification were bandiedabout among GPCC members. Some

items made it onto the ballot formembers to vote for or against

the specification, while otherswere shelved for future ver-

sions of the specification.Some of the suggested

items were pretty cuttingedge, but given that the

logo won’t take effectuntil sometime wellinto 1996, the recom-mendations were ap-propriate. Here’s a quickrundown of items thatwere suggested forGamePC-compatibility:

Three-DimensionalGraphics. The three-dimensional graph-ics benchmark that I profiled in my lastcolumn was probably the part of the

specification that generated the mostdebate. In fact, it wound up being sucha complicated topic that it didn’t make

it into theo f f i c i a lG a m e P Cballot. Thegroup isstill work-ing on itas we goto press,and itwill be

voted on inde-pendently from the rest of the hardwarerequirements. When completed, it willlikely take shape as a test suite thatcomputers will have to pass, similar tothe MPC test suite.

Three-dimensional User Input. Arequirement for three-dimensionalinput (such as a joystick-generatedcommand) was recommended for gamemachines, as the MPC specificationcalls only for a standard 101 keyboardand a mouse. The keyboard is fine forDoom and the mouse is great for Myst,but a Descent-type game or a flightsimulator allowing six degrees of free-dom should require a flight stick tokeep players from auguring in. Howev-er, the ballot sent out by the GamePCConsortium only queried for the pres-ence of a universal serial bus (USB) dig-ital joystick interface and a front-mounted joystick port—there was nomention of the computer actually hav-ing a joystick hooked up. Specifyingthat a person have a joystick port, butnot requiring the joystick itself is some-what like requiring that the computerhave a port for a keyboard, but notrequiring the presence of a keyboard(the big difference being that everycomputer comes with a keyboard, andno computer that I know of automati-cally comes with a joystick).

A consumer without a joystick isapt to look at a flight simulator box, seethe GamePC logo, figure he or she-meets the specification (“Hey—I’ve gotthe joystick port”), bring the gamehome, and find out that the darnedthing doesn’t work too well with a

C R O S S F I R E



mouse and keyboard. I may be nitpick-ing, but I feel that if the specification isgoing to ask for something as nifty as afront-mounted USB, you might want torequire the control that plugs into it.

T h r e e -d i m e n s i o n a lSight andSound . Vari-ous GPCCm e m b e r sp r o p o s e dthat infor-mation per-taining to three-di-mensional sound be included inthe specification, and others favor sup-port for stereoscopic devices in theGamePC mark. My feeling when I firstsaw those suggestions was, yes, thosehigh-end goodies should be in futureversions of a specification, but comingoff the blocks with a specification thatcalls for hardware that a miniscule por-tion of the gamers own (and not manygames will support anyway) will dis-

courage consumers from taking thespecification seriously. This is one ofthose cases where the special interestsof certain companies can cause politicalproblems in specification creation. For-tunately, neither of those items made itonto the ballot.

CD-ROM. This was an item that Isaw in potential conflict with the MPC

specification. The GPCC proposed adata transfer rate from a CD-ROM

at 450KB per second—in otherwords, a triple speed drive. This

raises two questions: why stan-dardize on this rare model of

drive (why not just base it ona 4X speed?), and won’t this

conflict with the MPC3 specification ifthat gets ratified as the basis for theGamePC specification? To attain theMPC3 rating, a computer must have aquad-speed CD-ROM drive, so ap-proval of a triple-speed drive will causethe GamePC rating to dip below analready approved base standard. Somekind of amendment to the standard

might have to bemade to correct thisapparent conflict.

Audio. TheGamePC specifica-tion seems to befairly similar to theMPC specification.Game PCs willlikely be required tosupport the currentstandard samplingrates between 8 and44.1KHZ and sup-port wavetable syn-thesis for MIDIplayback.

C o m m u n i c a -tion. With thehead-to-head capa-bilities of manygames on the mar-ket these days, theGPCC suggestedrequiring a 14.4KBmodem in a Game-P C - c o m p a t i b l emachine. Excel-lent—although a

28.8KB modem might have been better(oh well). I wonder if specifying accessto one of the major commercial onlineservices shouldn’t be a requirement of afuture GamePC specification. By allaccounts, CompuServe, AmericaOnline, Prodigy, and the MicrosoftNetwork are hot and heavy to promotea new generation of graphical gamesusing their online services as a back-bone. Another idea for future GamePCspecifications is a network card— noth-ing beats the speed of head-to-headplay when you’re connected to yourroommate’s computer with some coax!

System Software. No mention ofsystem software is made because allMPC specifications specify DOS and16-bit Windows. However, theGamePC ballot queries support forAutoPlay (or similar functionality),which implies support for Windows 95.The question of which operating systemto standardize on could confuse thespecification if it is not cleared up.Additionally, GPCC members such asIBM have made it clear that they’d likethe GPCC to come up with a specifica-tion that’s operating system neutral.This means that either the AutoPlayrequirement will have to be ditched,IBM will have to enable its own versionof AutoPlay in OS/2, or IBM is out ofluck.

The results of the balloting will beavailable by the time you read this.However, it’s still not clear when theGamePC specification will begin toappear on game boxes or hardware.Realistically, I wouldn’t expect it untilthe spring or summer of 1996. Yes,there are issues to be resolved regardingthe GamePC specification, but there’sno question that it’s a step forward foreveryone—developers and consumersalike. If you’d like to keep up to datewith what’s going on with the specifica-tion, or you’re interested in becoming amember of the GPCC, check out theirweb site at http://www.mmwire.com/gamepc/gpchome.html. ■

Alex Dunne is contributing editor toGame Developer magazine.

C R O S S F I R E

Let’s HearIt for the Boy

Nicole Claro

B I T B L A S T S

O.J.’s over, the World Seriesactually happened this year(with the Cleveland Indians,no less!), and my editor got torub shoulders with ourfavorite bottom-tattooed, for-mer child star. Judgment Dayhappens in less than a week,

but after that, things could start to getdull around here. Hey, Christmas, a bigseason for the game industry, is justaround the corner! Many of our readershave probably recently shipped projectsthey’d worked on diligently for monthsand are ready to spend some timeexploring each others work (not tomention the tools they each used onthat work). Enter hardware for theChristmas season—Virtual Boy fromNintendo.

Nintendo recently launched VirtualBoy to the tune of a $25-million mar-keting campaign. The VR headset is aRISC-based, 32-bit system using twohigh-resolution, mirror-scanning LEDdisplays, which immerses the player in afantastic world. The player controls theaction inside the lightweight headset(fitted with stereo sound) using the dou-ble-grip controller with six buttons andtwo plus-keys. Nintendo was responsiblefor the three-dimensional image immer-sion technology used in Virtual Boy,while the company has licensed the pro-prietary display technology from Reflec-tion Technology Inc., based inWaltham, Mass. Nintendo is currentlyworking with several companies onthird-party games designed specificallyfor the Virtual Boy headset, which willretail for $179.95. Gameboy, VirtualBoy, where does the boy go from here?

■ For more information contact:Nintendo of America4820 150th Avenue N.E.Redmond, Wash. 98052Tel: (206) 882-2040Fax: (206) 882-3585

Diamond on the EdgeVirtual Fighter, “Ready, Go!” Windows95-integrated video and audio hasreached new heights. Diamond Multi-media Systems Inc. has announced aline of integrated three-dimensionalmultimedia accelerators that lets usersplay a variety of high-powered gamesunder Windows 95.

The company believes its Dia-mond Edge 3D is the only single-boardaccelerator that features a digital game-port for precise joystick control and twovideo gameports that let you play spe-cialized, multiplayer titles. Severalgame companies are developing prod-ucts specifically to take advantage ofthe capabilities offered by Diamond’snew product. Papyrus’s Nascar Racingand Interplay’s Descent: DestinationSaturn are two games slotted to bebundled with the upcoming release ofDiamond Edge 3D. Retail price forDiamond Edge 3D will range from$249 to $299.■ For more information contact:

Diamond MultimediaSystems Inc.2880 Junction Ave.San Jose, Calif. 95134-1922Tel: (408) 325-7000Fax: (408) 325-7070

Crash, Bang, Boom!Positron Publishing has released theDynamic Motion Module, the first


Christmas is here,

and there are new

tools, new books,

new virtual headsets

for everyone! We‘ve

also got the scoop on

the results of the

GamePC

Consortium‘s vote on

specifications!

physics-based collision detection pro-gram for the PC. Designed as a plug-infor Autodesk 3D Studio, the DynamicMotion Module uses physics to createseries of keyframes more precisely thanyou could by hand. It lets animatorscombine objects that have beenassigned dynamic motion with otherobjects that rely upon key frame motionand detects the collision of objects(with a collision detection resolution ofup to 1/480th of a second), calculatingthe resulting motion response of theobjects. The module uses quaternions(complex algebraic structures) toimprove rotation and lets you apply fac-tors such as gravity, wind, acceleration,velocity, and drag to your objects. Fullycompatible with 3D Studio’s internalsplines, the Dynamic Motion Modulealso provides smooth-shaded previewimages as frames are generated.■ For more information contact:

Positron Publishing1915 N. 121st St.Ste. DOmaha, Neb. 68154Tel: (402) 493-6280Fax: (402) 493-6254

VB UndergroundThe Waite Group Press has releasedanother in its series of “Black Arts”books for programmers. Black Art ofVisual Basic Game Programming, byMark Pruett, is a guide to every aspectof building Windows games from theground up. Step-by-step tutorials clear-ly explain essentials like drawing theboundaries of the game playing field,using the Windows API to its fullest tocreate sprites and bitmap masks, and


It’s the moment we’ve all been waiting for...Just days ago (remember, it’s Decemberin Magazineland, but October everywhere else) the GamePC Consortium (GPCC)announced the results of its vote on standards for game specifications. For back-ground information on the debate, see Alex Dunne’s Crossfire column, on page 9 ofthis issue. Following are the standards the GPCC agreed on for the GamePC Level 1

Compatible System Specification. The specification covers five areas, systems, CD-ROMs,graphics, sound, and video. The GPCC also agreed on a Recommended System Specifica-tion, but due to its length, we couldn’t provide that data here. Go to our soon-to-be website (http://www.mfi.com/gdmag), though, and you can view it.

SYSTEM• Must Meet MPC level 2 minimum specifications • Base system must contain at least 8MB RAM• Must Support AutoPlay (or similar functionality)• Must be able to read 10MB data file from hard disk in 17 seconds (more than

600Kb per second).

CD-ROM • Must be able to read 10MB data file from CD in 30 seconds (300K/sec).

GRAPHICS:• Must run “Fox and Bear” benchmark (640x480x8) at a rate of 30 fps• Must implement local bus (VLB or PCI) graphics with total video RAM greater

than or equal to 2MB• Minimum total RAM (base system RAM+ video RAM) must be 9MB• Display and monitor must support the following display modes:

320 x 200 256 Colors (Mode 13 and Mode X)640 x 400 256 Colors (Mode 100h)640 x 480 256 Colors (Mode 101h)640 x 480 32K Colors (5:5:5) (Mode 110h)640 x 480 64K Colors (5:6:5) (Mode 111h)640 x 480 16.8M Colors (8:8:8) (Mode 112h)800 x 600 256 Colors (Mode 103h)

SOUND:• Must be able to play 4, 22KHz 16-bit wave buffers mixed, concurrently • Must support all sample rates between 8KHz and 44.1KHz, mono and stereo• Must support General MIDI compatible wave table synthesis.

VIDEO• Must be able to play a sample MPEG movie file from CD-ROM (accurate sound

synchronization with no audio breaks) • 352 x 240 window in display mode 640 x 480 x 8 must run at a rate of 15 fps• Must be OM-1 MPEG compliant.

Systems that the GamePC Consortium tests and verifies to conform to the above specifi-cations can earn the GamePC Level 1 Compatible certification mark.

H O T O F F T H E P R E S S !

monitoring object collisions. Every facetof game creation is covered here,including graphics, animation, sound-tracks, and increasingly difficult gamelevels.

The 600-page book comes with aCD-ROM with sample games thatdemonstrate smooth-scrolling back-grounds, using bitmap tiles to create amaze, and adding ray-traced graphics toyour gamescape. The CD-ROM alsoincludes 16- and 32-bit reusable VisualBasic code to plug into your own gamesand all the examples, graphics, andsound effects covered in the book. BlackArt of Visual Basic Game Programming:The Newest and Easiest Way to CreateGames with Visual Basic retails for$34.95.■ For more information contact:

Waite Group Press200 Tamal PlazaCorte Madera, Calif. 94925Tel: (415) 924-2575Fax: (415) 924-2576

Intel for EveryoneIntel has introduced Indeo VideoInteractive, a new wavelet-based codecthat enables real-time interaction andcontrol of video and graphics imageryin multimedia and game application forthe PC. It ups the ante on image quali-ty, offereing far better quality at lowerrates than possible before with IndeoVideo.

Indeo Video Interactive includesfeatures such as transparency supportfor interactive digital effect, which letsyou overlay arbitrarily shaped video orgraphics onto other video and graphics,for run-time interactive control; localwindow decode, with which you cancreate an indepentent video playbackwindow within a larger video playbackdisplay or graphics scene; randomkeyframe access; and a scalable qualityfeature that scales quality between sev-eral different quality levels, dependingon the PC’s CPU capability. IndeoVideo Interactive for Windows 95 andWindows 3.1 will initially be availablewithin an Intel SDK, with drivers forApple’s QuickTime 2.01 and 2.1 to

come in early 1996 (just about the timethis hits the stands).■ For more information contact:

Intel Corp.2200 Mission College Blvd.Santa Clara, Calif. 95954-1537Tel: (503) 264-6277

Nicole Claro is managing editor ofGame Developer magazine. Contact herat [email protected].

Stick it to Them...Microsoft beganshipping the Game Software Develop-ment Kit to developers at the beginning ofOctober. Some of us got betas at the Com-puter Game Developers’ Conference lastApril. The Gossip Lady has looked invain in her mailbox but perhaps a luckyreader will tell us what video cards are sup-ported. Since Microsoft’s standard answerto anyone with problems running gamesunder Win95 is, “Talk to your [video,sound, joystick, mouse] vendor” this is acrucial question. Oddly enough, Win95 hasproblems with some Logitech mice. DoesMicrosoft’s entry into the joystick marketmean that other joystick manufacturers aregoing to experience these unfortunate bugsalso?

A Learning Experience...Broderbund,always strong in edutainment, is going afterthat segment of the market in a big way.Not only did it purchase The LearningCompany but Broderbund has also start-ed a new line of curriculum-based gamesunder the Active Mind label.

Sony-Sega Title Bout...Someone atSony needs to give those PR people araise! Sega, probably after seeing thetremendous amount of ink that the SonyPlaystation is getting, lowered the priceon its Saturn in an attempt to stay competi-tive. Talk is that Sony’s only possible weakspot in its attempt to wrest the set-top mar-ket away from Nintendo and Sega is itslack of game design experience. With thehiring of Kelly Flock to head up the newlyrenamed Sony Computer Entertain-ment, this last is no longer a problem.Flock has the guts and the smarts to saywhat all of us developers have been mutter-ing ever since Hollywood mistook the“play” in “game play” as something thatyou go watch—not something you do.Flock says, “Anyone who talks about inter-active movies doesn’t know the first thingabout either.” Meanwhile, Sega announcedit will begin shipping titles for the PC.

Publishers Repel Pirates...Wonder whyyour royalty checks are low? Maybe it hassomething to do with all the pirate CD-ROMs. The Software PublishersAssoc. (SPA) just won injunctionsagainst E.V. International, M&SAssoc., Mr. CD-ROM, Softshoppe andStylin Multimedia, mostly for game pirat-ing. On another front, shareware authorshave involved the FBI and the RoyalCanadian Mounted Police in shuttingdown pirate shareware CD publishers.Rumor is that the shareware authors mayjoin up with SPA.

Talk to The Gossip Lady [email protected]

mo

oze

n

ew

s..

.S

ch

mo

oze

n

ew

s..

.


B I T B L A S T S

!U P G R A D E

YOURS!• RAD Software has released

version 2.0 of Smacker,which has over 100 new fea-tures. Smacker 2.0 has utili-ties up to 400% faster thanprevious versions and isavailable on CD-ROM. Theupgrade is $95 for currentSmacker users.

• Autodesk is at it again (theyput those upgrades out toofast for us to keep track!)with the recent release ofAnimator Studio 1.1. ThisWindows 95-compatible ver-sion of the two-dimensionalpaint and animation softwarefeatures many new plug-insand a digital clip library onCD-ROM. Current AnimatorPro users can migrate to thenewest version for $149; themigration will cost $199 forAnimator and MultimediaExplorer users. For newusers, Animator Studio 1.1will retail at around $295.

• Kai’s Power Tools 3 (KPT3)is the latest version of theimaging software availablefrom MetaTools (formerlyHSC Software). KPT3 is opti-mized for Power Macintoshand Windows NT and Win-dows 95 and features sever-al new tools and precisecontrols over imaging spe-cial effects. KPT3 will retailfor around $199, and regis-tered users of KPT2.1 canupgrade for $79.

Knowing, understanding, andfollowing through on yourgoals are key parts of soft-ware development. Often, I’llgo into a project with a per-fectly valid set of goals, onlyto get distracted along theway and produce something

that meets an entirely different set ofgoals, but completely misses my origi-nal ones. This phenomenon seems tobe pretty common in the game industryas well, where companies go into a pro-ject with the goal of creating a greatgame, but end up creating a nice pieceof technology with no game play.

Similarly, our goal during thisseries is not to produce a perspectivetexture mapper. Surprise! Our goal isactually to draw perspective-texture-mapped triangles on the screen quickly.A subtle but important difference existsbetween these two goals. As with mostthings in real-time PC graphics, theresult on the screen is the only thingthat matters, not how you got it there.We can exploit the difference betweenwhat looks right and what is right andget big speedups in our code.

In other words, if a beautifullywritten, mathematically perfect texturemapper and a total hacked piece of junkproduce the exact same results on thescreen (including avoiding jitter and allthe other things we’ve been learning),and the hack is 10 times faster, then thechoice is clear if you’re interested inspeed. It’s important to note that thisdoes not mean we’ve been wasting ourtime learning about “correct” perspec-tive texture mapping. In fact, it’s justthe opposite. Now that we intimately

understand how the math works, we’rein a much better position to throw it allout and cut corners.

In Our Last Episode...Let’s quickly summarize and tie up looseends from my last column in this series,“Perspective Texture Mapping, Part III:Endpoints and Mapping” (Behind theScreen, Aug./Sept. 1995). The summaryis pretty short: we’ve developed a com-plete, high-quality sub-pixel-accurateperspective texture mapper.

The only loose end we’ve got left(besides performance, which is themain subject of this article) concernsthe real-to-integer texture coordinatemapping. When we left off, we had abug in this mapping and we needed tochoose a rounding rule to get the cor-rect mapping. I hinted that we alreadyhad the information available to makethe decision on which rounding rule touse, but I didn’t give the answer. Asmany of you probably guessed, the gra-dients are the key to making this deci-sion (which implies you must switchbetween rounding rules at runtime—and this is indeed the case). Unfortu-nately, limited space keeps me fromgoing into the derivation of the solu-tion. If you’re interested, you can pickup the sample code I mention at theend of this column on the Game Devel-oper ftp site. You’ll find a big commentblock explaining things there.

Divided We FallFinally I’m ready to make good on thesecond half of my two-part promise:the first part of which was to developan easy-to-understand perspective cor-

TextureMapping Part IV:Approximations

So you thought we

were done with per-

spective texture map-

ping. Didn‘t you feel

something was miss-

ing? The penultimate

article in this series

helps shed some light

on the ins and outs of

approximations.

Chris Hecker

B E H I N D T H E S C R E E N


rect texture mapper, and the second tospeed it up to interactive performance.

In our efforts to speed up themapper the obvious question is ,“Where is the code currently spendingits time?” I ran a profiler on it andended up with what I like to call theperfect profile—almost all our time(96%) is spent in one function,DrawScanLine. The nice thing about aprofile like this is that your optimiza-tion work in that function, sometimescalled the hotspot, is very highly lever-aged. In other words, every little bityou speed up the hotspot increases theoverall performance by a lot. It’s notsurprising that DrawScanLine is the cul-prit because it contains the pixel loop,but it ’s always good to check ourassumptions and gather some real data.

Listing 1 gives us a closer look atDrawScanLine inner loop. In it, we seethat the function is doing a divide andtwo multiplies per pixel to figure outthe texture coordinates, a multiply tocalculate the texture offset, and a fewadds. The divide is probably the majorsink here. Divides are much slower thanmultiplies on most processors, and mul-

tiplies are generally slower than adds. Ifwe comment out the divide per pixeland do a linear interpolation betweenthe left and right edge, the mapper per-forms seven times faster in my test (andof course looks totally wrong becausethere’s no perspective correction).Obviously, getting rid of the dividehelps a lot. However, to get rid of thedivide and keep the same visual qualitywe need to know exactly what thedivide is doing there in the first place.

The divide is the crux of the per-spective texture mapper. It takes thelinear interpolations of 1/z, u/z, and v/zand turns them into the nonlinear curve

that samples pixels close together whenthe polygon is near the eyepoint andsamples farther apart when the polygonis distant. If the polygon is slanted sothat it’s close on one end and distant onthe other, the divide smoothly movesfrom close to separated samples. Figure1 shows a plot of screen x versus sam-pled u for a typical perspective mappedscanline. As x increases, u startsincreasing slowly and then grows muchquicker. Obviously, this data is from a

polygon that’s close at low values of xand distant at larger values.

This curve (it’s different for eachpolygon and scanline, in general) iswhat makes perspective mapping lookcorrect, so the trick is to approximatethe curve without using a divide andwithout adversely affecting our visualquality.

The Big ThreeWhen I say we want to approximate theperspective curve, I mean we want touse alternate equations that will pro-duce the same—or very close to thesame—output (the u value shown inFigure 1) for the same input (x, asshown in Figure 1), but hopefully willbe more efficient than our algorithmwith its divides.

Three approximations to the per-spective texture mapping equations arecommonly used: subdividing affine,quadratic, and lines-of-constant-z.

I’m going to talk about lines-of-constant-z first because it’s very differ-ent from the other two. First, “lines-of-constant-z” is an awkward name. Somepeople choose to call it “free-directiontexture mapping,” which is a bit easierto say but not quite as precise. Basically,a lines-of-constant-z rasterizer tries totake advantage of the neat fact thatthere are straight and parallel lines thathave a constant z through any planarpolygon. Imagine you’re sliding a planethat’s perpendicular to the z-axis backthrough your polygon. The plane willslice the polygon in a series of parallellines as it moves through the depthrange occupied by the polygon. All thepixels along one of these lines will havethe z value of the plane, so the line hasa “constant z.”

Now, if you look at the mathbehind our projection, when z is con-stant, our equation turns into a linearinterpolation (the perspective curvefrom one point on this line to the nextis a line itself), which is quick and easyto compute and has no divides in thepixel loop. The down side is that ingeneral you’ll be interpolating along adiagonal line in the destination insteadof across a nice horizontal scanline



Figure 1. The Perspective Curve

u

x

while(Width— > 0) {float Z = 1/OneOverZ;int U = UOverZ * Z + 0.5;int V = VOverZ * Z + 0.5;

*(pDestBits++) = *(pTextureBits + U + (V * TextureDeltaScan));

OneOverZ += Gradients.dOneOverZdX;UOverZ += Gradients.dUOverZdX;VOverZ += Gradients.dVOverZdX;

}

Listing 1. The Inner Loop

(walls and floors are special cases wherethe lines-of-constant-z are vertical andhorizontal, respectively).

This diagonal (or free-direction)interpolation causes three major prob-lems. First, if your diagonal lines don’tabut properly you’ll get dropouts andoverwrites inside your polygon. This issolvable if you’re careful.

Second, unless you obey a strict fillconvention, you’ll get the same kind ofdropouts and overwrites between poly-gons. This is much harder to fix thanthe intra-polygon problems, but it’s stillsolvable.

Finally, and this one is the kiss ofdeath as far as I’m concerned, it is total-ly impossible to achieve subpixel accu-racy with a lines-of-constant-z texturemapper. To achieve subpixel accuracywe must always sample the texture fromthe pixel centers of the destination butour arbitrary line-of-constant-z doesn’thit the pixel center in the destination.However, you can’t step off the line-of-constant-z to the pixel center or you’llneed to divide to take the nonconstant-z step into account. Damned if you do,damned if you don’t.

If you don’t care about subpixelaccuracy (insert flame about jitteringand sloppy textures here), the lines-of-constant-z technique might be for you.As an added bonus, you get depth cuingeffects like fog almost for free—youalready know the depth of the currentline, and the depth, by definition, isgoing to stay constant. So you can com-pute your fog value at the start and useit along the entire line instead of atevery pixel.

The next two techniques, subdivid-ing affine and quadratic, are based on amore straightforward approximation ofthe perspective curve. Both try to fiteasy-to-interpolate curves to the morecomplex perspective curve. Subdividingaffine does a piecewise linear approxima-tion, fitting a number of line segments tothe curve, and quadratic fits a quadraticcurve to the perspective curve.

We’re going to use a subdividingaffine curve for our approximation, sobefore going into detail on it I’ll go overthe quadratic technique.

QuadraticsMost people remember quadratic equa-tions as parabolas from algebra. A qua-dratic in x is:

This equation will graph a parabo-la or a line on the x and f(x) axes. Thecoefficients a, b, and c determine the

shape and position of the parabola onthe graph, and we use these three“degrees of freedom” to attempt to fit aparabola to the perspective curve. Weuse the normal perspective mapper tointerpolate down the edges of the poly-gon so they’ll be precise, and use thequadratic to interpolate across the scan-line (where we’re spending our time inDrawScanLine). At each pixel on thescanline, we want to be able to feed inour screen position, x, and the quadraticequation should produce our texturecoordinate as its value (f(x) in Equation

1). We need two quadratics—one toproduce the u texture coordinate fromx, and the other to produce the v coor-dinate from x.

Because we have three degrees offreedom, we can choose to match exact-ly any three characteristics of the per-spective curve, and approximate theother characteristics. For example, wemight choose to exactly interpolate thetwo endpoints, and spend our lastdegree of freedom on exactly matchingthe first derivative, or slope, of the per-spective curve as it enters or leaves oneof the endpoints—we can’t match bothderivatives because that would cost ustwo degrees of freedom, one more thanwe have left if we’re going to hit theendpoints exactly. We could even inter-polate one endpoint and exactly matchthe first and second derivative exactly atthat point. Or we might spend all threedegrees of freedom interpolating threepoints on the curve exactly, like the twoendpoints and the middle point. We’lldo the derivation for the latter approxi-mation to show how it’s done.

To figure out the quadratic curvethat interpolates the two endpoints andthe midpoint and produces the u texturecoordinate given x, we start by writingdown the equations we know. Weassume x goes from 0 to 1 for simplicity.We need to solve for u at x = 0, 0.5, and1 using the perspective divide to give usthree known values, u0, u1, and u2,respectively, so we can solve for a, b, andc, the three unknowns. We plug thesevalues into Equation 1 to give us threeequations in three unknowns:

and:

f u a b c

a b c

1 1 122( ) = = + +

= + +

f u a b c

a bc

1

2

1

2

1

2

4 2

1

2Ê

ËÁ

ˆ

¯˜ = =

Ê

ËÁ

ˆ

¯˜ + + =

+ +

f u a b c c0 0 002( ) = = + + =

f x ax bx c( ) ( )= + +2 1


If you don‘t care

about subpixel

accuracy, the

lines-of-con-

stant-z tech-

nique might be

for you.

We then solve the simultaneousequations for a, b, and c in terms of u0,u1, and u2, and after a bit of algebra weget:

and:

Now, if we wanted to, we could usethese coefficients and solve the quadraticdirectly at each point on the scanline(we’d actually do the math using x = 0, atx = width/2, and x = width so wewouldn’t have to scale our x valuesbetween 0 and 1), but that means we’dbe doing a bunch of multiplies perpixel—probably better than the dividewe’re currently doing, but not great.However, we can use forward differencesto solve the quadratic using only addi-tion and the solution for the previouspixel. Forward differences are covered inany good graphics or math textbook,but, simply stated, you take f(x+1)-f(x) tocalculate the function’s step based on itsprevious value. In the case of our qua-

c u= 0

b u u u= - + -3 40 1 2

a u u u= - +2 4 20 1 2



void DrawScanLine_suba( dib_info const &Dest,gradients_fx_fl_a const &Gradients,edge_fx_fl_a *pLeft, edge_fx_fl_a *pRight,dib_info const &Texture )

{int XStart = pLeft->X;int Width = pRight->X - XStart;

char unsigned *pDestBits = Dest.pBits;char unsigned * const pTextureBits = Texture.pBits;pDestBits += pLeft->Y * Dest.DeltaScan + XStart;long TextureDeltaScan = Texture.DeltaScan;

int const AffineLength = 8;

float OneOverZLeft = pLeft->OneOverZ;float UOverZLeft = pLeft->UOverZ;float VOverZLeft = pLeft->VOverZ;

float dOneOverZdXAff = Gradients.dOneOverZdX * AffineLength;float dUOverZdXAff = Gradients.dUOverZdX * AffineLength;float dVOverZdXAff = Gradients.dVOverZdX * AffineLength;

float OneOverZRight = OneOverZLeft + dOneOverZdXAff;float UOverZRight = UOverZLeft + dUOverZdXAff;float VOverZRight = VOverZLeft + dVOverZdXAff;

float ZLeft = 1/OneOverZLeft;float ULeft = ZLeft * UOverZLeft;float VLeft = ZLeft * VOverZLeft;

float ZRight, URight, VRight;fixed16_16 U, V, DeltaU, DeltaV;

if(Width > 0) {int Subdivisions = Width / AffineLength;int WidthModLength = Width % AffineLength;

if(!WidthModLength) {Subdivisions—;WidthModLength = AffineLength;

}

while(Subdivisions— > 0) {ZRight = 1/OneOverZRight;URight = ZRight * UOverZRight;VRight = ZRight * VOverZRight;

U = FloatToFixed16_16(ULeft) + Gradients.dUdXModifier;V = FloatToFixed16_16(VLeft) + Gradients.dVdXModifier;DeltaU =

FloatToFixed16_16(URight - ULeft)/AffineLength;DeltaV =

FloatToFixed16_16(VRight - VLeft)/AffineLength;

for(int Counter = 0;Counter < AffineLength;Counter++){int UInt = U>>16;int VInt = V>>16;

*(pDestBits++) = *(pTextureBits + UInt +(VInt * TextureDeltaScan));

U += DeltaU;V += DeltaV;

}

ZLeft = ZRight;ULeft = URight;VLeft = VRight;

Listing 2. The Subdividing Affine DrawScanLine (Continued on p. 24)

Figure 2. The Quadratic Curve

u

x

dratic, we need to do “second forwarddifferences,” where we calculate the for-ward difference of the function step. Inother words, we calculate the forwarddifference of the forward difference.

How does it look? Well, in Figure2, the blue curve is again the perspectivecurve, and the red curve is the quadraticinterpolating the start, middle, and end.This is a pretty bad case for the quadraticbecause the perspective warp is quitehigh. On less distorted views the singlequadratic would match up better. Youcan also subdivide into multiple quadrat-ics to better match the curve if you wantto spend the extra setup time. However, Ichose this view because it illustrates avery significant side effect of the quadrat-ic approximation—undershoot. If youlook very closely, you’ll see the red lineactually dips below u = 0, which means

we’d read off our texture map and possi-bly crash. You can figure out when thiswill happen and prevent it by subdivid-ing, but that means even more setup inaddition to setting up the quadratic equa-tion for both u and v for each scanline.

Overall, the quadratic approximationis very elegant conceptually, but the prob-lems of under- and overshoot and thesetup overhead of calculating the coeffi-cients seem to make it not worth thetrouble. You can also use higher ordercurves, like cubics, and the math we’velooked at extends easily. Perhaps we’llreturn to quadratics in a later column andsee what we can do with them, but fornow, we’ll move on to subdividing affine.

It’s Affine DayIt happens that the method we’ve cho-sen is also the simplest. You’ve probably

already guessed exactly how subdividingaffine texture mappers work from whatI’ve been describing.

Basically, you solve the real per-spective equation at a bunch of pointsalong the scanline, and do a linearinterpolation between those correctpoints (affine and linear are virtuallyinterchangeable in this context). Linearinterpolations are what we’ve beendoing all along with 1/z, u/z, and v/z,so I won’t go into detail here. Linearinterpolations are very fast, and thesetup isn’t too bad for each affine span.The only trick is to determine howoften to subdivide; the more you subdi-vide, the closer your piecewise linearcurve will match the real curve—but themore overhead you’ll have from dividesand per-span setup.

One simple way to subdivide is tojust break up the scanline into equisizedspans. You can also adaptively subdividebased on the amount of perspective warpon each span. This issue’s texture map-per will always subdivide to eight pixelspans, but we’ll look into adaptive subdi-vision next time. Figure 3 shows a subdi-viding affine approximation to our



Figure 3. The Subdivided Affine Curve

u

x

OneOverZRight += dOneOverZdXAff;UOverZRight += dUOverZdXAff;VOverZRight += dVOverZdXAff;

}

if(WidthModLength) {ZRight = 1/(pRight->OneOverZ - Gradients.dOneOverZdX);URight = ZRight *

(pRight->UOverZ - Gradients.dUOverZdX);VRight = ZRight *

(pRight->VOverZ - Gradients.dVOverZdX);

U = FloatToFixed16_16(ULeft) + Gradients.dUdXModifier;V = FloatToFixed16_16(VLeft) + Gradients.dVdXModifier;

if(—WidthModLength) {// guard against div-by-0 for 1 pixel linesDeltaU =

FloatToFixed16_16(URight - Uleft)/ WidthModLength;

DeltaV =FloatToFixed16_16(VRight - Vleft)/ WidthModLength;

}

for(int Counter = 0;Counter <= WidthModLength;Counter++) {int UInt = U>>16;int VInt = V>>16;

*(pDestBits++) = *(pTextureBits + UInt +(VInt * TextureDeltaScan));

U += DeltaU;V += DeltaV;

}}

}}

Listing 2. The Subdividing Affine DrawScanLine (Continued from p. 22)

favorite perspective curve, subdividingevery eight pixels in x.

There are a few nice things aboutsubdividing affine texture mappers.First, you can tune the performanceand quality by setting the subdivisionlevel. This lets you adjust your perfor-mance on demand (which you mightneed to do at runtime, depending onscene complexity).

Second, you can pretty easily fit allyour interpolants in registers for theaffine spans (a subject I’ll cover in moredepth in my next column).

Finally, unlike quadratic approxi-mation, you’ll never under- or over-shoot with subdividing affine becauselike the real perspective curve, the affinespans are monotonically increasing ordecreasing with the curve. In otherwords, depending on your subdivisiongranularity and the perspective warp,you’ll sometimes draw the wrong pixels,but you’ll never fetch outside the texturemap or even outside the extents of theoriginal correct span in texture space.

Sample CodeListing 2 shows the DrawScanLine func-tion modified to do subdividing affinetexture mapping. We’ll max this outnext time, but even unoptimized it out-performs the divide-per-pixel routine bytwo to four times. We must treat thelast span with care to ensure we interpo-late the rightmost pixel correctly. You’llremember from previous articles thatour right edge is actually the left edge ofthe next polygon over, so we need tosubtract one pixel from the right edge tofigure out the last pixel in our polygonand use it in the interpolation.

I’ve also finally written a texturemapping test bed so you can simplycompile and run the listings. You canfind it on ftp://ftp.mfi.com/gdmag.The test has all the texture mapperswe’ve written so far, so you can see thejitter from the integer mapper, themapping bug from the one we dis-cussed in the last installment, and soon. It’s a Windows program, but thecode for the texture mappers is

portable, and you’l l be able to seeexactly how they’re called. The test bedis easy to modify—see the readme.txtfile in the archive.

In parting, I want to mention afew tidbits. First, you might think youshould do an approximation down theedges as well, which is certainly possi-ble. However, your error can build uppretty quickly if you’re not careful.Also, Digital Image Warping by GeorgeWolberg (IEEE Computer Society,1990) is a pretty good reference for thissort of thing (including forward differ-ences). Finally, I’d like to thank ChrisGreen from Leaping Lizard Softwarefor opening my eyes up to the fact thata, b, and c really are three totally arbi-trary degrees of freedom. ■

By the time you read this, ChrisHecker will have quit working for the manand will be out on his own, finally payingfor his own beverages. You can recommendyour favorite drink at [email protected].


XSplatBreaks Out

X S P L A T B R E A K S O U T

In Writing Down the Bones, authorNatalie Goldberg describes how, at alocal fair, she set up a booth where shewrote and gave away five-minutepoems. Each poem represented amomentary thought, a unique idearecorded on paper and passed along onthe wind without a backwards glance.In a similar vein, John Carmack and

John Romero wrote games for SoftdiskPublishing, a service that sent new gamesto its subscribers every month, before start-ing id Software. Every 30 days, the pro-grammers had to come up with a completeand innovative concept, make it happen,release it, and move on.

I envy the experiences of Goldbergand the team at id, who learned to moveon, to avoid dwelling on mistakes. I’vealways found project ends to be painful,whether I’m finishing a chunk of code, apiece of writing, or a baked lasagna. The

moment you sign off and pass along some-thing personal, when you freeze it in timeand drop it into the hands of its con-sumers, you find yourself standing nakedin front of the world, wishing you couldtake it all back and do it right.

This is a roundabout way of sayingthat even as I introduced XSplat lastmonth and used it to create a simple cross-platform paint program, I knew it con-tained major mistakes. Unfortunately, Ihaven’t mastered the Zen of letting go, andthis is after all a series of articles. So we’regoing to make four quick evolutionaryswipes at XSplat before jumping into somereal game code.

You’ll find all the code included orreferred to in this article on the GameDeveloper ftp site, ftp.mfi.com, in the/gdmag/src/ directory.

Darwinism 101Previously, I briefly mentioned virtualizingthe CXSplatWindow member functions so wecould use polymorphism in C++ to providemultiple window types in a single applica-tion using a single mechanism. The baseCXSplatWindow class can provide a genericimplementation from which we can deriveany number of subclasses that can livetogether comfortably at run time. That’schange number one: virtualization of CXS-platWindow.

Change number two involves sneak-ing around the much-touted event-basednature of our target operating systems. Asit stands, XSplat also provides a strictlyevent-based system, meaning that it reactsto user input. However, a game must beproactive—the game should continue evenwhen the user does nothing. So let’s add afunction CXSplatWindow::Idle, which the


An XSplat Breakout game in progress on Windows 95. The same source code works equallywell on the Macintosh.

system calls on every iteration of the mainmessage loop, that we can use to processgame logic. Hence, change number two:Idle Events.

Windows 95 came, and there wasmuch rejoicing. The function provided byWinG under Windows 3.1 is now provid-ed by the CreateDIBSection API. ChrisHecker went out of his way to make theWinG API identical to the CreateDIBSec-tion API, so the two are nearly inter-changeable. If you want to require Win-dows 95 or NT 3.5 and do away withWinG installation, you can use CreateDIB-Section. That’s change number three:Enable CreateDIBSection. We may revisitthis later to detect the appropriate imple-mentation at run time.

Finally, XSplat as we have it nowlacks a useful keyboard interface, which weneed to create keyboard-based games.Sending KeyDown messages alone doesn’tquite cut it, so let’s refine CXSplatWin-dow::KeyDown to notify us only when a keygoes down (and not when a key auto-repeats) and add CXSplatWindow::

KeyUp to inform us when a key is released.That’s change Number Four: Better Key-board Events.

These quick tweaks prepare to movethe XSplat base beyond a novelty item andtowards a fully featured foundation forgames. This excludes the KeyDown and KeyUpevents, which require some explanation.

Tuning the KeyboardWith WM_KEYDOWN and WM_KEYUP messages,Windows passes a virtual key code indicat-ing the key that has been affected. Wereally want some more useful platform-independent key code, such as the ASCIIvalue produced by the key in question, so

we have to negotiate with Windowsthrough a sequence of calls involvingGetKeyboardState and ToAscii. If we suc-ceed in getting a single ASCII code for thekey, we can pass it on to the CXSplatWindowobject. This precludes the use of specialkeys such as Control or Shift in XSplatgames, but we’ll make do.

The new WM_KEYDOWN handler, whichreplaces the old WM_CHAR handler, is shownin Listing 1. The WM_KEYUP handler isalmost identical.

We also have to add some handlingto the Macintosh message loop to processkeyUp events. That’s very straightforward,except for a little trick that caught me. Thesystem engineers at Apple decided thatmost Macintosh applications don’t listento keyUp events and that they could cutsome corners by not sending them, so youhave to tell the Macintosh operating sys-tem explicitly to send keyUp events before itwill pass along a single one. Be a good citi-zen and turn off keyUp notification whenyour application exits, too. The followingcode will enable this:

// Tell the OS to give us keyUp events

short OldEventMask = LMGetSysEvtMask();

LMSetSysEvtMask(OldEventMask |

keyUpMask);

// Play the game!

XSplatMain();

// Restore the old system event mask

LMSetSysEvtMask(OldEventMask);

Palettes and Static ClingAnother essential issue still remainsuntouched by XSplat: palettes and colormanagement. In a multitasking, multiwin-dow environment, your application lives inharmony with many other applications

Before making XSplat

faster, the cross-

platform graphics

library needs a little

patching...

Jon Blossom provides

it in Part II of his

five-part series.

Jon Blossom


that require specific colors from the hard-ware, so both Macintosh and Windowsinclude resident Palette Managers to arbi-trate color requests. Understanding thePalette Managers will allow your XSplatapplications to share this color sandboxwith the other kids while still hoarding theresources you need.

On the Macintosh, you are entitledto explicitly program 254 of the 256 colorsavailable in 8-bit video modes, the onlymodes with which XSplat deals. In theearly days, all Macintosh systems hadblack-and-white monitors, so the originalMacintosh operating system used onlyblack and white for its user interface ele-ments, and now the operating system ishard coded to program color 0 to Whiteand color 255 to Black.

Giving two colors to the Macintoshsystem doesn’t seem too painful, especiallywhen most applications include black andwhite in their palettes anyway, so we won’tworry much about the Macintosh PaletteManager. Windows, however, abides bymuch stricter rules. Read Ron Gery’s verythorough online article “The Palette Man-ager: How and Why” (available onMSDN or through Microsoft DeveloperRelations group) for the full scoop. I’mgoing to give you the abridged version.

Back when VGA cards came ontothe scene, Windows made the switch tocolor. At 640-by-480 pixels, the standard

VGA allowed for 16 colors, which theWindows VGA driver programmed with16 specific colors. Then along came videocards with a 256-color palette, but much ofWindows had been coded assuming the 16VGA colors of Windows 3.0. If Windowsallowed programmers to tromp all over allthe hardware colors, the colors used forwindow borders, captions, and other userinterface elements could be replaced, and

Windows’s colorful user interface could bedestroyed.

Windows programmers made a pro-vision that would (under normal condi-tions) guarantee the availability of certaincolors to draw the user interface. Theytook the 16 standard VGA colors, threw ina few new ones to spice things up, and

came up with the “static colors” or the“cosmic colors,” as one friend of mine callsthem. The static colors are split betweenthe first and last 10 entries in the palette sothat a bitwise XOR of palette indices will alsoprovide an XOR of the colors. In Windows3.1, the values and number of static colorsreserved depended on the video driver, butWindows 95 has standardized on 20 spe-cific colors, listed in Table 1.

After the system claims its static col-ors, you usually have 246 left with which towork. You can tell the system to give upthe static colors, leaving it only color 0 asblack and color 255 as white, but I reallyrecommend that only for full-screen appli-cations that use none of the standard Win-dows user interface elements. In XSplat,we’ll leave the static colors intact.

In fact, we’ll go a step further. We’llactually include the Windows static colorsin our Macintosh palettes to ensure thatthe colors available to XSplat applicationswon’t depend on platform. The first andlast 10 colors passed to the CXSplatWindowconstructor will be always ignored, over-written by the static colors.

Color 0 on the Macintosh is alwayswhite, while on Windows it’s always black,no matter what we do. This “color zeroproblem” often shows up when artists

hard-code an image to the palette on onesystem, expecting to be able to display thesame image with the same 256-colorpalette on another system. When theybring the image from Macintosh to Win-dows, they find that all their whites havebecome black! Beware. An XSplat applica-tion should never use color 0 or color 255.



case WM_KEYDOWN:// Only send KeyDown if the key is just going down// (no auto repeat)if (!(lParam & 0x40000000)){

// We want the ASCII code of the key that’s going down// Begin with the key scan code, part of the virtual keyUINT ScanCode = (lParam & 0x00FF0000) >> 16;

// Wish we didn’t have to get all 256 entries, but...BYTE KeyState[256];GetKeyboardState(KeyState);

// Convert the scan code to 1 or 2 ASCII characterschar unsigned Key[2];int KeyCount =

ToAscii(wParam, ScanCode, KeyState, (LPWORD)&Key, 0);

// Only send the key if it translates to one ASCII charif (KeyCount == 1)

pXSplatWindow->KeyDown((char unsigned)Key[0]);}

Listing 1. Translating a WM_KEYDOWN Message

Index R-G-B Color Index R-G-B Color0 0x00 - 0x00 - 0x00 246 0XFF - 0xFB - 0xF01 0X80 - 0x00 - 0x00 247 0xA0 - 0xA0 - 0xA42 0x00 - 0x80 - 0x00 248 0x80 - 0x80 - 0x803 0x80 - 0x80 - 0x00 249 0xFF - 0x00 - 0x004 0x00 - 0x00 - 0x80 250 0x00 - 0xFF - 0x005 0x80 - 0x00 - 0x80 251 0xFF - 0xFF - 0x006 0x00 - 0x80 - 0x80 252 0x00 - 0x00 - 0xFF7 0xC0 - 0xC0 - 0xC0 253 0xFF - 0X00 - 0xFF8 0xC0 - 0xDC - 0xC0 254 0x00 - 0xFF - 0xFF9 0xA6 - 0xCA - 0xF0 255 0xFF - 0xFF - 0xFF

Table 1. The Windows Static Colors

Identity PalettesOur palette troubles aren’t over yet. Wemay have figured out what colors weneed in the palette, but there’s still noguarantee that they’ll appear in the sys-tem palette in the order we requestthem. Both operating systems gothrough complicated (read time-con-suming) mapping algorithms to ensurethat appropriate colors appear when youtransfer an image from memory to thescreen. If we manipulate the colors in thepalette so that they exactly match thecolors in the color tables of our offscreenimages, the system will skip that map-ping step, and copying an image to thescreen will become a direct transfer frommain memory to video memory, limitedalmost exclusively by the bandwidth ofthe bus between the two. We need tounderstand a few things before we cando this.

The Windows Palette Managermaintains a single system palette that holdsall the colors actually available in the hard-ware, and every palletized applicationkeeps a logical palette that represents thecolors it has requested. The Palette Man-ager handles the mappings between thetwo. Basically, it uses three techniques togive you the colors you request, a processcalled “realization” of the palette.

The first technique is to preventduplicate palette entries. If you request acolor N that’s already in the system paletteat entry M, Windows will “collapse” yourentry. When you request logical color N, itwill actually use system color M. If youmark one of your entries PC_NOCOLLAPSE andthe system palette isn’t full, you can avoidthis translation.

The second technique just serves yourrequest by entering a new entry in the sys-tem palette, as long as the system paletteisn’t full. If there are M entries in the sys-tem palette, a new entry M will be created,and when you request logical entry N,you’ll get system entry M.

The third technique is to map to theavailable colors. If you request a color Nthat’s not in the system palette and allavailable system palette entries have beenused, Windows will look for the color Min the system palette that best matches therequested color. If you mark a palette


// A dummy LOGPALETTE structurestruct{

WORD Version;WORD NumberOfEntries;PALETTEENTRY aEntries[256];

} LogPalette = { 0x300, 256 };

// Grab the current palette for the display and count the// number of static colors it’s usingHDC hdcScreen = GetDC(0);int StaticColorCount = 20;if (hdcScreen){

StaticColorCount = GetDeviceCaps(hdcScreen, NUMCOLORS);GetSystemPaletteEntries(hdcScreen, 0, 256, LogPalette.aEntries);ReleaseDC(hdcScreen, 0);

}

// We’ll create our palette from the static colors,// filling in whatever gaps are left with colors from// the requested colors, or a gray wash as before if// there are none.int i;for (i=0; i<StaticColorCount/2; ++i){

// Fill in the peFlags of the first static entriesLogPalette.aEntries[i].peFlags = 0;

}

if (Colors){

// Fill in the middle entries with the requested colors// Count tells us where to find the appropriate RGB// triplet in the requested color arrayint Count = i * 3;

for (; i<256 - StaticColorCount/2; ++i){

LogPalette.aEntries[i].peRed = Colors[Count++];LogPalette.aEntries[i].peGreen = Colors[Count++];LogPalette.aEntries[i].peBlue = Colors[Count++];

// Mark as PC_RESERVED to guarantee identity paletteLogPalette.aEntries[i].peFlags = PC_RESERVED;

}}else{

// Fill in the middle entries with a grey washfor (; i<256 - StaticColorCount/2; ++i){

LogPalette.aEntries[i].peRed =LogPalette.aEntries[i].peGreen =LogPalette.aEntries[i].peBlue = i;

LogPalette.aEntries[i].peFlags = PC_RESERVED;}

}

for (; i<256; ++i){

// Fill in the peFlags of the remaining static entriesLogPalette.aEntries[i].peFlags = 0;

}

// Finally, create the palette!Palette = CreatePalette((LOGPALETTE*)&LogPalette);

Listing 2. Windows Palette Creation

request PC_RESERVED, Windows will notmap subsequent color requests to thatentry.

We want to trick the Palette Manag-er into providing a one-to-one matchbetween the colors we request and the col-ors in the system palette. In other words,we don’t want our colors to be collapsedusing the first technique, and we don’twant any subsequent color requests to col-lapse into ours. Because PC_RESERVED is asuperset of PC_NOCOLLAPSE, marking everyone of our entries PC_RESERVED will do thisfor us.

So as long as we include the staticcolors and mark the rest PC_RESERVED, wecan guarantee a one-to-one match of col-ors, but we may not yet match indicesexactly. We’re forcing the Palette Managerto use the second mapping technique,which means creating a new entry for everycolor we request, but it won’t necessarilystart creating new entries at color zero. Ifanother application has requested paletteentries before ours, our palette will be real-ized beginning where the last applicationleft off, so M and N in the second tech-nique may not be equal.

To remedy this, the WinG SDKincluded a sample function called ClearSys-temPalette that forces the Palette Managerto realize a full palette of 256 PC_RESERVEDcolors, filling up the system palette so thatsubsequent palette mapping begins againat entry 0. Calling ClearSystemPalette inour XSplat WinMain and marking our logicalpalette entries PC_RESERVED will get us thepure identity mapping we want.

The Macintosh Palette Managerworks almost the same way, collapsingentries when it is able to serve colorrequests as best it can. The WindowsPC_NOCOLLAPSE corresponds loosely to theMacintosh pmExplicit flag, and the Win-dows PC_RESERVED corresponds to the Mac-intosh pmAnimated flag. To achieve an iden-tity palette on the Macintosh, then, we’llput white at color 0 and black at color 255,and mark all other entries as pmExplicit |pmAnimated. There’s no need for a ClearSys-temPalette equivalent.

Listing 2 shows the code snippet thatbuilds an identity palette as part of theWindows CXSplatWindow constructor. List-ing 3 shows the equivalent code for the



// Set up the palette from the given ColorsWinPalette = NewPalette(256, 0, pmExplicit | pmAnimated, 0);if (WinPalette){

// To maintain compatibility with our Windows cousin, we’ll include the Windows static colors // in the palette. Of course, color 0 must be white and color 255 blackchar unsigned const WindowsColorsLow[] =

{ 0xFF,0xFF,0xFF,0x80,0x00,0x00, 0x00,0x80,0x00, 0x80,0x80,0x00,0x00,0x00,0x80, 0x80,0x00,0x80, 0x00,0x80,0x80,0xC0,0xC0,0xC0, 0xC0,0xDC,0xC0, 0xA6,0xCA,0xF0 };

char unsigned const WindowsColorsHigh[] ={ 0xFF,0xFB,0xF0, 0xA0,0xA0,0xA4, 0x80,0x80,0x80,

0xFF,0x00,0x00, 0x00,0xFF,0x00, 0xFF,0xFF,0x00,0x00,0x00,0xFF, 0xFF,0x00,0xFF, 0x00,0xFF,0xFF,0x00,0x00,0x00 };

// We’ll create our palette from these “static” colors, filling in whatever gaps are left // with colors from the requested colors, or a gray wash as before if there are none// Count tells us where to find the appropriate RGB triplet in the requested color arrayint Count = 0;RGBColor rgb;int i;for (i=0; i<10; ++i){

// Fill in the first ten entriesrgb.red = (long)WindowsColorsLow[Count++] << 8;rgb.green = (long)WindowsColorsLow[Count++] << 8;rgb.blue = (long)WindowsColorsLow[Count++] << 8;

SetEntryColor(WinPalette, i, &rgb);}

if (Colors){

// Fill in the middle entries with the requested colorsfor (; i<246; ++i){

rgb.red = (long)Colors[Count++] << 8;rgb.green = (long)Colors[Count++] << 8;rgb.blue = (long)Colors[Count++] << 8;


}else{

// Fill in the middle entries with a grey washfor (; i<246; ++i){

rgb.red = rgb.green = rgb.blue = (long)i << 8;


}

Count = 0;for (; i<256; ++i){

// Fill in the remaining static entriesrgb.red = (long)WindowsColorsHigh[Count++] << 8;rgb.green = (long)WindowsColorsHigh[Count++] << 8;rgb.blue = (long)WindowsColorsHigh[Count++] << 8;

SetEntryColor(WinPalette, i, &rgb);}SetPalette(Window, WinPalette, FALSE);

}

Listing 3. Macintosh Palette Creation

Macintosh. The 20 static colors are hardcoded for the Macintosh, but they’re pulledout of the system palette under Windows.Also note the striking similarities betweenthe code for the two platforms...

Breaking OutEnough of that system stuff, let’s get to thereal point: building games. We’re going tobegin programming a cross-platform ver-sion of an old classic, Breakout. You allknow the game. A wall of bricks fills theupper half of the screen, and the playermoves a paddle back and forth at the bot-tom of the screen to keep a ball bouncinginto the bricks. Whenever the ball hits abrick, that brick goes away. The game endswhen all the bricks have been destroyed.

XSplat now has everything we needto implement this game in full color: aplace to create and display 256-colorgraphics (palletized CXSplatWindow andCOffscreenBuffer), time to process the flowof the game (Idle), and user input to con-trol the paddle (KeyDown and KeyUp). We canderive our game window, CBreakoutWindow,from the virtualized CXSplatWindow base andoverride the pieces we need to make thegame work.

A CBreakoutWindow also keeps track ofone complete game state. It stores thebrick wall as an array of bytes, correspond-ing to the wall of bricks on the screen, andany nonzero value in the array indicates abrick in that location. When the edge ofthe ball crosses a brick boundary, the cor-responding array entry is decremented. Fornow, CBreakoutWindow::Initialize initial-izes all entries with the value 1, so one hitof the ball will destroy a brick.

The ball and paddle both have posi-tion and velocities, also stored in theCBreakoutWindow object. The paddle is lim-ited to motion along the X-axis while theball can move along X and Y. On KeyDownand KeyUp events, we’ll adjust the speed ofthe paddle, moving it left as long as theplayer holds down the < key, and right aslong as the player holds down the > key.On Idle messages, the game logic kicks in,moving the ball and checking if it has hitanything important. Then Idle redraws thegame, using simple rectangle drawing codeI’ve described previously (see “XSplat: AFoundation for Cross-Platform Develop-

ment,” Oct./Nov. 1995), and copies it tothe screen.

Listing 4 shows the declaration ofCBreakoutWindow, and Listing 5 shows the


// Breakout Game Window// The Breakout window is a regular XSplat window with// most functions overridden. The game is played entirely// within this window, so the Breakout window includes// all state information necessary for the game.

class CBreakoutWindow : public CXSplatWindow{public:

// Game setup occurs during construction and on// InitGame callsCBreakoutWindow(unsigned char const *Colors=0);void InitGame(void);

// The destructor will clean up the gamevirtual ~CBreakoutWindow(void);

// All of the game logic takes place on Idlevirtual void Idle(void);

// This game cares about key statesvirtual void KeyDown(char unsigned Key);virtual void KeyUp(char unsigned Key);

protected:// This function will completely redraw the game statevoid DrawCompleteGameState(void);

// We’ll provide a ‘demo mode’ for the game to play itselfint IsDemoMode;

// Game Data// Game element position and speedint BallX, BallY;int BallXSpeed, BallYSpeed;int PaddleX;int PaddleXSpeed;

// Game fieldchar unsigned GameField[kWallWidthBricks * kWallHeightBricks];

inline char unsigned GetBrickState(int X, int Y){ return GameField[Y * kWallWidthBricks + X]; };

inline void SetBrickState(int X, int Y, char unsigned State){ GameField[Y * kWallWidthBricks + X] = State; };

inline char unsigned HitBrick(int X, int Y);};

inline char unsigned CBreakoutWindow::HitBrick(int X, int Y){

char unsigned ReturnState = 0;

if (X >= 0 && Y >= 0 &&X < kWallWidthBricks &&Y < kWallHeightBricks)

{int Index = Y * kWallWidthBricks + X;ReturnState = GameField[Index];if (ReturnState)

GameField[Index]—;}return ReturnState;

}

Listing 4. Breakout Declarations



int BounceX = 0;int BounceY = 0;

BallX += BallXSpeed;BallY += BallYSpeed;

if (BallX < kPlayAreaLeft){

BallX = kPlayAreaLeft + (kPlayAreaLeft - BallX);BounceX = 1;

}else if (BallX >= kPlayAreaRight - kBallSize){

BallX = 2*kPlayAreaRight - 2*kBallSize - BallX;BounceX = 1;

}

if (BallY < kPlayAreaTop){

BallY = kPlayAreaTop + (kPlayAreaTop - BallY);BounceY = 1;

}

//———————————————// Follow the ball with the paddle center when in demo mode,// allow the user to control the paddle in play mode

if (IsDemoMode){

if (PaddleX < BallX + kBallSize/2) ++PaddleX;else if (PaddleX > BallX + kBallSize/2) —PaddleX;

}else{

PaddleX += PaddleXSpeed;}

// Make sure the paddle doesn’t move out of the play area!if (PaddleX < kPlayAreaLeft + kPaddleWidth/2)

PaddleX = kPlayAreaLeft + kPaddleWidth/2;else if (PaddleX > kPlayAreaRight - kPaddleWidth/2)

PaddleX = kPlayAreaRight - kPaddleWidth/2;

//———————————————// Bounce the ball

if (BallY + kBallSize >= kWallTop && BallY < kWallBottom){

// Ball is within the brick field.// Calculate ball bounces off bricksint BrickLeft = (BallX - kWallLeft) / kBrickWidth;int BrickTop = (BallY - kWallTop) / kBrickHeight;int BrickRight = (BallX + kBallSize - kWallLeft) / kBrickWidth;int BrickBottom = (BallY + kBallSize - kWallTop) / kBrickHeight;

// Look to the sides of the ballif (BallXSpeed > 0 &&

((BallX + kBallSize - kWallLeft) % kBrickWidth) == 0){

if (HitBrick(BrickRight, BrickTop))BounceX = 1;

if (BrickTop != BrickBottom &&HitBrick(BrickRight, BrickBottom))BounceX = 1;

}else if (BallXSpeed < 0 &&

((BallX - kWallLeft) % kBrickWidth) == kBrickWidth-1)

void CBreakoutWindow::KeyDown(char unsigned Key){

if (!IsDemoMode){

// Get the paddle movingswitch (Key){

case ‘,’:case ‘<’:

PaddleXSpeed -= 2;break;

case ‘.’:case ‘>’:

PaddleXSpeed += 2;break;

case ‘d’:case ‘D’:

// Switch to demo modeIsDemoMode = 1;break;

default:break;

}}else if (Key == ‘P’ || Key == ‘p’){

// Switch to player controlIsDemoMode = 0;

}}

void CBreakoutWindow::KeyUp(char unsigned Key){

if (!IsDemoMode){

// Reverse the motion of the paddleswitch (Key){

case ‘,’:case ‘<’:

PaddleXSpeed += 2;break;

case ‘.’:case ‘>’:

PaddleXSpeed -= 2;break;

default:break;

}}

}

//———————————————// Game logic is processed while the game is idle

void CBreakoutWindow::Idle(void){

// Don’t do anything while backgroundedif (!IsActiveFlag)

return;

//———————————————// Move the ball and calculate a bounce off any walls

Listing 5. Breakout Game Implementation (Continued on p. 33)

implementation of relevant CBreakoutWindowfunctions. Many of these functions useconstants (beginning with a “k”) thatshould be self-explanatory. Notice thatthere’s absolutely nothing platform-specificin the game code; it’s all built on XSplatand compiles for Windows and Macintoshwithout change.

Again, I encourage you to grab thecomplete source code and compiled XSplatBreakout applications from the GameDeveloper ftp site.

Next TimeWhile the version of Breakout built in thisarticle works and is even fun to play forabout a minute, it certainly has a long wayto go. For one thing, it’s running flat outall the time, and it hugs a root even on myPentium 90. Perhaps that has somethingto do with the fact that we’re redrawingthe entire screen every frame?

In my next article, we’ll streamlinethe Breakout rendering by adding aSwapRect function to COffscreenBuffer, and

we’ll take a look some platform-indepen-dent timing functions that will allow us tocontrol the final speed of the game. And,of course, we’ll start spicing up game playwith some extra colors, increasing speed,and increasing difficulty levels.

Until then, have fun! ■

You can reach Jon Blossom via e-mail [email protected] or through GameDeveloper magazine.


{if (HitBrick(BrickLeft, BrickTop))

BounceX = 1;

if (BrickTop != BrickBottom &&HitBrick(BrickLeft, BrickBottom))BounceX = 1;

}

// Look to the top and bottom of the ballif (BallYSpeed > 0 &&

((BallY + kBallSize - kWallTop) % kBrickHeight) == 0){

if (HitBrick(BrickLeft, BrickBottom))BounceY = 1;

if (BrickLeft != BrickRight &&HitBrick(BrickRight, BrickBottom))BounceY = 1;

}else if (BallYSpeed < 0 &&

((BallY - kWallTop) % kBrickHeight) == kBrickHeight-1){

if (HitBrick(BrickLeft, BrickTop))BounceY = 1;

if (BrickLeft != BrickRight &&HitBrick(BrickRight, BrickTop))BounceY = 1;

}}else if (BallY == kPlayAreaBottom - kPaddleHeight - kBallSize){

// The ball is at the correct height to bounce off the paddleif (BallX + kBallSize > PaddleX - kPaddleWidth/2 &&

BallX <= PaddleX + kPaddleWidth/2){

// The ball hit the paddle, so it’s going to bounce back upBounceY = 1;

// Divide the paddle into five sections and determine which// contains the ballint BallXCenter = BallX + kBallSize/2;int PaddleLeft = PaddleX - kPaddleWidth/2;int PaddleSection = (BallXCenter - PaddleLeft)

/ (kPaddleWidth / 5);

if (BallXSpeed == 0 && PaddleSection != 2){

// If the ball isn’t moving in X and it hits outside of// the paddle center, it should bounce to the sideif (PaddleSection < 2)

BallXSpeed = -1;else

BallXSpeed = 1;}else if (PaddleSection == 0 && BallXSpeed > 0){

// The ball is striking the leftmost section ofthe paddle

// from the left. Bounce it back.BounceX = 1;

}else if (PaddleSection == 4 && BallXSpeed < 0){

// The ball is striking the rightmost section ofthe paddle

// from the right. Bounce it back.BounceX = 1;

}else if (PaddleSection == 2){

// When it hits in the very center section, theball

// bounces straight up.BallXSpeed = 0;

}}

}else if (BallY == kPlayAreaBottom - kBallSize){

// TODO: Lose ball!BounceY = 1;

}

//———————————————// Perform any velocity changes due to bounces

if (BounceX) BallXSpeed = -BallXSpeed;if (BounceY) BallYSpeed = -BallYSpeed;

//———————————————// Display the new frame and return

COffscreenBuffer* pBuffer = GetOffscreenBuffer();if (pBuffer){

pBuffer->Lock();DrawCompleteGameState();pBuffer->SwapBuffer();pBuffer->Unlock();

}}

Listing 5. Breakout Game Implementation (Continued from p. 32)

Under theRainbow

C O L O R Q U A N T I Z A T I O N

Pick a color, any color. When Iwas younger, my brother, whoenjoyed magic and card tricks,would frequently use me tobeta test his sleight of hand,and he had a wisecracking wayof saying, “Pick a card, anycard.” Of course, all cards were

not created equal, and I always tried toguess which card would throw a monkeywrench into his trick, as brothers arewont to do. Now after working onimage processing products for my start-up company, I’m faced with similarchoices in color quantization algorithms.

I can already hear some of you say-ing, “Wait a second, didn’t we do this ayear ago?” In a word, yes we did (“AFew Good Colors,” December 1994).

So why are we revisiting this process?The answer’s simple: There is a newerand better algorithm available calledvariance minimization. More specifical-ly, I want to present to you an imple-mentation of this algorithm that is fast,practical, and produces visibly betterresults in circumstances common ingame development.

This article has two sections. First,we are going to discuss how to managecolors and graphics in the game devel-opment process and look at issues ingetting artwork into your program.Once we have examined the situationswhere quantization is needed, we aregoing to get down to the nuts and boltsof variance minimization, and explainwhy it gets results that are superior tothe commonly used Heckbert statisticaland popularity methods.

Color Usage in GamesFirst, I asked the question “Does colorquantization have a place in game devel-opment?” I found that until about six orseven years ago the answer was, “Notreally.” Since then, it’s quickly gonefrom “Not really” to “Oh, yes.” Theadvent of 256-color graphics modes onPCs and Macintoshes spurred thischange of tone. Prior to that, colorswere so limited that game developers gottheir graphics from skilled artists whohand-drew each image. At the time, nopopular display could show more than16 of 512 set colors, and PCs were lim-ited to 64 possible colors at best. Withthe shift from digital to analog colormonitors came video cards that coulddisplay 256 simultaneous colors, whichwas a great improvement. More impor-

Two examples of color quantization in action. On the left, the cover of a magazine you mightrecognize, scanned at 16 million colors. On the right, the original scan reduced to 20 colorswith full variance minimization.


tantly, these video cards were capable ofdrawing those colors from a range of aquarter million to 16 million colors—and for the first time the cards couldrespectably display photographic orvideo images.

Color and PaletteManagement IssuesLet’s talk about artwork and graphics fora minute. The graphics for a typicalgame can come from any combinationof the following (each of which raisesissues that can affect the quality of thefinished product):• Traditional drawn images, which are

scanned.• Images drawn with a computer paint

program.• Computer-generated images such as

raytraced images.• Images created with a video camera

and video capture board.Having an artist paint or draw

images to be scanned is best suited forlarger images, such as backgrounds, orsmall images with a photographic look,such as faces of characters. Getting theartwork into the program involves scan-ning, resampling (resizing), quantiza-tion, and possibly dithering. Ideally, youwant to make this a one-step process.Whenever an intermediate image fileexists, some visual information will belost.

To get the best final results, followtwo steps. Scan the image at the highestphysical (not interpolated) resolutionand store it in a lossless true color (24-bit) format such as TIFF. Check thescanned image at this point to see if thecolor and contrast closely match the

image and adjust and rescan until youare satisfied. You now have the elec-tronic equivalent of a photograph nega-tive. From this file you can produce thegraphics that will actually go into yourprogram. If you make changes to thenumber of colors used or want to makederivative images (tinted, inverted,brightened, and so on), going back tothe original scan file lets you maintainthe highest quality.

Drawing images with a computerpaint program has some benefits, butprovides some new wrinkles. With apaint program, you can eliminate theneed to resize an image. If a graphicneeds to be a specific size, the artist justsets the work area to that size andbegins drawing. Because the artist drawswith pixels instead of pen or brush, heor she has precise control of the finalresult. So the artist can draw lines per-fectly straight, make distances betweenobjects precise, and make color gradi-ents perfectly uniform. When it comesto small images or objects, a paint pro-gram is often the way to go.

Artists often use video captureequipment when they want multipleangles or positions of the same scene orobject. Video data usually uses the YUVor HSV (Hue, Saturation and Bright-ness) color model and is converted bythe hardware or driver software intoRGB colors.

The Palette is a ResourceAnother issue in game development isallocating your colors for each screen orsituation. Imagine that you are produc-ing a fighting game for the PC, muchlike the “Super Mortal Killer Turbo

Game graphics are

nothing without true,

vibrant color that

doesn‘t sap memory.

Try the high-speed

algorithm offered

here and you‘ll

optimize color

quantization in your

game design.

Matt Pritchard andRich Geldreich Jr.


Dragon II” games you see in thearcades. At any given time, you haveseveral independent images on thescreen—the background, the players,and their weapons. As the game pro-gresses, these images are constantlyreplaced with different images. Odds arethat all those graphics started out assome sort of true color image and werequantized to use a small number of dis-crete colors. Think about what is goingon with the palette in such a game.There are two basic ways to handle thepalette.

First, the game might use a global,fixed palette that multiple images drawfrom. This lets each image use a largernumber of different colors, but becausethey must be shared with all othergraphics, the quantization error—thedegree to which the displayed color dif-fers from the original color—will tendto be much greater.

The other approach is to use a seg-mented palette, where each object getsan exclusive portion of the palette for itsown use. This gives the object fewer col-ors to use, but allows the quantizationerror to be kept to a minimum. Thismethod allows for a much larger totalnumber of colors to be used.

It turns out that selecting colorsspecifically for an image (quantizing forthat image alone) usually more thanmakes up for the reduction in availablecolors. It also turns out that the furtheryou reduce the number of colors, themore impact the quantization algorithmhas. (Dithering also has a place here, butthat is a topic for a separate article.)

Two more palette managementissues often show up in game develop-ment—palette effects and shading.Palette effects are just that: specialeffects, usually in the form of cycling,pulsating or flashing colors. No big deal,except that when you add palette effects,you usually have to reserve specific por-tions of the palette for them. Shading,on the other hand, often involves split-ting the palette up into sections for eachbrightness level.

So where are we going with all thistalk about color, artwork, and graphicsissues? This is simply an illustration of

all the ways and situations in which youneed to quantize images to an arbitrarynumber (usually a small one) of colorsbefore they go into your final product.

SupportingMultiple PlatformsI want to mention one more situation:porting your game and graphics to mul-tiple platforms. On a PC, under DOSyou have full control of all 256 entries inthe palette. But what if you are doing aWindows version? If you have neverprogrammed for Windows before, youare in for a rude surprise. In 256-colormodes, Windows reserves 20 colors forits own use. It is possible to get 18 ofthose back, but only at the cost ofscrewing up all the colors in the desk-top. The new Microsoft Game SDKprovides support for taking over thescreen, but what if your program needsbe windowable on the desktop? You arelooking at a practical maximum of 236colors and you have two choices.

You can let Windows manage thecolors for you, and it will translate someof your graphics colors into other colorsat the expense of speed and image quali-ty. If you use 256-color images for yourwallpaper, you’ve probably already seenthis in action. When a program needssome additional colors, parts of thewallpaper flash for an instant beforethey are replaced with what Windowsconsiders the most similar colors that itcan spare. A better option is to redoyour 256-color program to work with236 (or fewer) colors.

But why stop with Windows?What about OS/2 or the Macintosh?And if your product is a successfulgame, you could wind up porting it todedicated game systems such as Sony,Nintendo, Atari, or Sega, each with dif-ferent color systems.

The ExampleProgram and SourceNow that I’ve built the case for quanti-zation, it is time to deliver the goods.Taking code directly from our PC imageviewer, PowerView, we have created aprogram that takes the raw output ofPicLab, a public domain image process-

ing Program by Lee Daniel Crocker,and quantizes it to an arbitrary numberof colors from 2 to 256. Unfortunately,the 50K of Watcom C source code istoo cumbersome to list completely here.However, the complete source, com-piled program, and example files arefreely available on the Game Developerftp site, ftp.mfi.com, and in our Com-puServe library (GO SDFORUM), inthe archive file Dec95.zip, subfileVARMINCQ.zip. You can also accessthe shareware version of PowerViewhere, in the archive file PVIEW100.zip

The Quantization ProcessFrom here on, we are going to assumesome familiarity with other quantizationmethods that use cube splitting. Vari-ance minimization is also a cube-split-ting process, but it differs from the morecommon Heckbert method in severalimportant ways.

So far, the only published informa-tion on variance minimization is a paperby Xiaolin Wu, (“Efficient StatisticalComputations for Optimal ColorQuantization,”Graphics Gems II, Acade-mic Press Inc., 1991). Upon examina-tion, we found the source code Wu pre-sented with his paper was not practicalon a PC class system. So we threw outhis source and developed our own highlyefficient implementation, which we pre-sent here. Wu’s paper is a very academicread and will send average programmersscrambling for their college calculusbooks. So, we’ll focus on the actualimplementation and how it differs fromother quantization methods. If you’reinterested in the theory and math, by allmeans check out Wu’s paper.

For those not familiar with howcomputers process color, here’s a quickexplanation. Every dot of color thatappears on your monitor is built fromthree separate component colors, red,green, and blue. Each component has abrightness value that can range fromnone (black) to the maximum intensityof the display device. Your computer’svideo card uses a numerical value to rep-resent the brightness of each color com-ponent.

The computer industry has settled



on 8-bit (one-byte) numbers, whichallows for 256 possible settings betweenblack and maximum intensity for eachcolor component. With three compo-nents, the number of possible colors is256 by 256 by 256 or 16.8 million.That’s a lot of colors! It also gives us away to compare colors. We can create athree-dimensional cube, and let eachaxis (X,Y, and Z) represent one of thecolor components (R, G, and B). Thisway, each color can be mapped to apoint inside the cube by using its RGBvalues as the X,Y, and Z coordinates ofthe color point. Now that we can repre-sent each color as a point in three-dimensional space, we can use simplegeometry to compute how close togetherany two colors are. Using thePythagorean theorem, we define thedistance between color 1 (r1,g1,b1) andcolor 2 (r2,b2,g2) as the square root of(r1-r2)2 + (g1-g2)2 + (b1-b2)2. Figure 1illustrates the RGB three-dimensionalcolor space cube and how to locate aspecific RGB color in it.

Quantization is the process ofreplacing one color with another color;usually from a smaller selection of colorpoints. The distance between the twocolors is called the quantization error.

Our process starts with a color his-togram of the image to be quantized.For those not familiar with the term, acolor histogram is a three-dimensionalarray of the RGB colors used. The valueof a specific element is the number oftimes the color with that element’s RGBcoordinates appears in the image. Typi-cally, most elements in the histogramwill be unused or zero. Almost every

quantization routine I have ever seenreduces a 24-bit color to 15 bits whenbuilding the histogram, due to memoryconsiderations.

Using short integers, a 15-bit his-togram takes 64K of memory, while a24-bit histogram would require 32megabytes. This reduction (typicallytruncation of the low bits) is in itself aform of quantization that is actuallynoticeable. If you have ever seen animage of a blue sky that has curvedbands as it approaches the horizon,you’ve seen the effects of this truncation.With the advent of 32-bit compilers, Ihave found it practical to use a 6-bitRGB histogram, which takes 512K ofmemory and produces superior resultscompared to the 5-bit histogram. (Weare using two bytes per entry, whilemany implementations use four bytesper entry. With two bytes, rememberyou need to take precautions to keepfrom overflowing the histogram count.)

Once we have this three-dimen-sional color histogram, we put a boxaround it. The box structure is shown in

Listing 1. Then, we shrink the box tothe smallest possible box that can con-tain all of the used points within. Infact, every time we create or split a box,we shrink it immediately. Shrinking thebox is an important optimization used inmost quantization processes. It can cre-ate empty regions in the histogram thatare not contained in any box and mustbe accounted for when building theinverse color map.

Now we get to the question, “Whatexactly is variance?” Consider that all

the colors in a given box are going to berepresented by a color point, also knownas the “representative” color. Every usedcolor in that box is going to be replacedby the representative color, and somedegree of quantization error is going tobe introduced into the image whenthose pixels are replaced with the quan-tized color. Variance in this case meansthe total quantization error of all theused points in the box, weighted by theusage count of each point.

The goal of variance minimizationis just what the name implies; to pick arepresentative color that results in thelowest possible total variance for thatbox. If you think about it, that’s the goalof quantization as well—to make thecolor change in each pixel, (that is, thequantization error), as small as possible.The smaller the variance, the lesschange to the image. I’ve shown ourvariance calculation in Listing 2.

In this algorithm, we define therepresentative color as the “center ofcolor gravity” for the box—that is, the(Continued on p. 40)


static uint variance(uint tw, uint tt_sum,uint t_ur, uint t_ug, uint t_ub)

{double temp;

temp = (double)t_ur * (double)t_ur;temp += (double)t_ug * (double)t_ug;temp += (double)t_ub * (double)t_ub;temp /= (double)tw;

return ((uint)((double)tt_sum - temp));}

Listing 2. The Weighted Variance Calculation

typedef struct{uint variance; /* weighted variance */

uint total_weight; /* total weight */uint tt_sum; /* tt_sum += r*r+g*g+b*b*weight over entire box */

uint t_ur; /* t_ur += r*weight over entire box */uint t_ug; /* t_ug += g*weight over entire box */uint t_ub; /* t_ub += b*weight over entire box */

int ir, ig, ib; /* upper and lower bounds */int jr, jg, jb;

} box;

Listing 1. Structure Used for a Colorspace Box



/*————————————————————*//* Splits box along the axis which will/* minimize the two new box’s overall/* variance. A brute force search is used/* to locate the optimum split point. *//*————————————————————*/static void split_box(box *old_box){

int i, j;box *new_box;

uint total_weight;uint tt_sum, t_ur, t_ug, t_ub;int ir, ig, ib, jr, jg, jb;

uint total_weight1;uint tt_sum1, t_ur1, t_ug1, t_ub1;int ir1, ig1, ib1, jr1, jg1, jb1;

uint total_weight2;uint tt_sum2, t_ur2, t_ug2, t_ub2;int ir2, ig2, ib2, jr2, jg2, jb2;

uint total_weight3;uint tt_sum3, t_ur3, t_ug3, t_ub3;

uint lowest_variance, variance_r, variance_g, variance_b;int pick_r, pick_g, pick_b;

new_box = boxes + num_boxes;num_boxes++;

total_weight = old_box->total_weight;tt_sum = old_box->tt_sum;t_ur = old_box->t_ur;t_ug = old_box->t_ug;t_ub = old_box->t_ub;ir = old_box->ir;ig = old_box->ig;ib = old_box->ib;jr = old_box->jr;jg = old_box->jg;jb = old_box->jb;

/* left box’s initial statistics */

total_weight1 = 0;tt_sum1 = 0;t_ur1 = 0;t_ug1 = 0;t_ub1 = 0;

/* right box’s initial statistics */

total_weight2 = total_weight;tt_sum2 = tt_sum;t_ur2 = t_ur;t_ug2 = t_ug;t_ub2 = t_ub;

/* locate optimum split point on red axis */

variance_r = 0xFFFFFFFF;

for (i = ir; i < jr; i++){

uint total_variance;

/* calculate the statistics for the area being taken

* away from the right box and given to the left box*/

sum(i, ig, ib, i, jg, jb,&total_weight3, &tt_sum3, &t_ur3, &t_ug3, &t_ub3);

#ifdef DEBUGGINGif (total_weight3 > total_weight)

ASSERT(TRUE)#endif

/* update left and right box’s statistics */

total_weight1 += total_weight3;tt_sum1 += tt_sum3;t_ur1 += t_ur3;t_ug1 += t_ug3;t_ub1 += t_ub3;

total_weight2 -= total_weight3;tt_sum2 -= tt_sum3;t_ur2 -= t_ur3;t_ug2 -= t_ug3;t_ub2 -= t_ub3;

#ifdef DEBUGGINGif ((total_weight1 + total_weight2) != total_weight)

ASSERT(TRUE)#endif

/* calculate left and right box’s overall variance */

total_variance = variance(total_weight1, tt_sum1, t_ur1, t_ug1, t_ub1) +variance(total_weight2, tt_sum2, t_ur2, t_ug2, t_ub2);

/* found better split point? if so, remember it */

if (total_variance < variance_r){

variance_r = total_variance;pick_r = i;

}}





/* locate optimum split point on green axis */

variance_g = 0xFFFFFFFF;

for (i = ig; i < jg; i++){


/* calculate the statistics for the area being taken

Listing 3. Splitting a Colorspace Box (Continued on p. 39)


* away from the right box and given to the left box*/

sum(ir, i, ib, jr, i, jb,&total_weight3, &tt_sum3, &t_ur3, &t_ug3, &t_ub3);


ASSERT(TRUE)#endif





ASSERT(TRUE)#endif


total_variance = variance(total_weight1, tt_sum1,

t_ur1, t_ug1, t_ub1) +variance(total_weight2, tt_sum2,

t_ur2, t_ug2, t_ub2);


if (total_variance < variance_g){

variance_g = total_variance;pick_g = i;

}}





variance_b = 0xFFFFFFFF;

/* locate optimum split point on blue axis */

for (i = ib; i < jb; i++){


/* calculate the statistics for the area being taken* away from the right box and given to the left box*/

sum(ir, ig, i, jr, jg, i,&total_weight3, &tt_sum3, &t_ur3, &t_ug3, &t_ub3);


ASSERT(TRUE)#endif





ASSERT(TRUE)#endif


total_variance = variance(total_weight1, tt_sum1,

t_ur1, t_ug1, t_ub1) +variance(total_weight2, tt_sum2,

t_ur2, t_ug2, t_ub2);


if (total_variance < variance_b){

variance_b = total_variance;pick_b = i;

}}

/* now find out which axis should be split */

lowest_variance = variance_r;i = 0;

if (variance_g < lowest_variance){

lowest_variance = variance_g;i = 1;

}

if (variance_b < lowest_variance){

lowest_variance = variance_b;i = 2;

}

/* split the selected axis into two new boxes */

Listing 3. Splitting a Colorspace Box (Continued on p. 40)

(Continued from p. 37)statistical center of all the points in thebox, taking their usage into account.

A Better SplitI think of Heckbert’s statistical andmedian cut methods as naive. When

they split a box into two smaller boxes,their criteria doesn’t directly result inreduced color error in the new boxes;sometimes it does a good job, some-times it does a not so good job. TheHeckbert methods either split along thelargest axis (making the boxes as square

as possible) or distribute the number ofused color points evenly, without regardto how close they are to the representa-tive color. Other variations on the split-ting criteria exist, but they do notimprove the overall result.

In variance minimization, the goal



ir1 = ir; ig1 = ig; ib1 = ib;jr2 = jr; jg2 = jg; jb2 = jb;

switch (i){

case 0:{

jr1 = pick_r + 0; jg1 = jg; jb1 = jb;ir2 = pick_r + 1; ig2 = ig; ib2 = ib;break;

}case 1:{

jr1 = jr; jg1 = pick_g + 0; jb1 = jb;ir2 = ir; ig2 = pick_g + 1; ib2 = ib;break;

}case 2:{

jr1 = jr; jg1 = jg; jb1 = pick_b + 0;ir2 = ir; ig2 = ig; ib2 = pick_b + 1;break;

}}

/* shrink the new boxes to their minimum possible sizes */

shrink_box(ir1, ig1, ib1, jr1, jg1, jb1,&ir1, &ig1, &ib1, &jr1, &jg1, &jb1);

shrink_box(ir2, ig2, ib2, jr2, jg2, jb2,&ir2, &ig2, &ib2, &jr2, &jg2, &jb2);

/* update statistics */

sum(ir1, ig1, ib1, jr1, jg1, jb1,&total_weight1, &tt_sum1, &t_ur1, &t_ug1, &t_ub1);

total_weight2 = total_weight - total_weight1;tt_sum2 = tt_sum - tt_sum1;t_ur2 = t_ur - t_ur1;t_ug2 = t_ug - t_ug1;t_ub2 = t_ub - t_ub1;

/* create the new boxes */

old_box->variance = variance(total_weight1, tt_sum1, t_ur1,t_ug1, t_ub1);

old_box->total_weight = total_weight1;old_box->tt_sum = tt_sum1;old_box->t_ur = t_ur1;old_box->t_ug = t_ug1;old_box->t_ub = t_ub1;old_box->ir = ir1;old_box->ig = ig1;old_box->ib = ib1;old_box->jr = jr1;old_box->jg = jg1;old_box->jb = jb1;

new_box->variance = variance(total_weight2, tt_sum2, t_ur2,t_ug2, t_ub2);

new_box->total_weight = total_weight2;new_box->tt_sum = tt_sum2;new_box->t_ur = t_ur2;new_box->t_ug = t_ug2;new_box->t_ub = t_ub2;new_box->ir = ir2;new_box->ig = ig2;new_box->ib = ib2;new_box->jr = jr2;new_box->jg = jg2;new_box->jb = jb2;

/* enter all splittable boxes into the priory queue */

i = 0;if ((jr1 - ir1) + (jg1 - ig1) + (jb1 - ib1)) i = 2;if ((jr2 - ir2) + (jg2 - ig2) + (jb2 - ib2)) i++;

switch (i){

case 0:{

heap[1] = heap[heap_size];

heap_size—;

if (heap_size)down_heap();

break;}case 1:{

heap[1] = new_box;

down_heap();

break;}case 2:{

down_heap();

break;}case 3:{

down_heap();

insert_heap(new_box);

break;}

}}

Listing 3. Splitting a Colorspace Box (Continued from p. 39)

is to split the boxes in such a way that ifyou added up the variance of bothboxes, it would be the smallest numberpossible. Wu used summed area tables,but we simply used brute force, whichturned out to be quite fast and efficient.This function, split_box, is shown inListing 3.

Starting with the box to the split, aplane is passed through the box alongone axis and used to divide the box intwo. The variance of each box is calcu-lated and the plane’s position is toremember if the total variance of bothboxes is the smallest yet encountered.As the plane makes its way through thebox, individual points are moved fromone box to the other by subtracting andadding their values which simplifies andoptimizes the process of keeping thevariance calculations up to date. Thefunction we used to get statistics foreach box is shown in Listing 4.

Once done, another plane is passedthrough the box along the two remain-ing axes, resulting in the evaluation ofevery possible way to split the box. Thebox is then split along the plane thatresulted in the smallest total variances,and both new boxes are placed in a pri-ority list according to their individualvariances.

Now, we must choose another boxto split. This is where another importantdifference occurs with variance mini-mization. Heckbert’s method will selectthe next box based on which box is

largest, which box has the most pixels init, or some combination of the two. Invariance minimization, the box with thehighest variance, that is, the one thatneeds the most work to reduce quanti-

zation error, is chosen next, and in ourimplementation it just happens to be thebox at the top of the priority list. Theprocess is repeated until the number ofboxes created equals the number of col-ors desired.

An interesting side effect of thisalgorithm is that you can easily computehow well the image has been quantizedat any time by summing up the varianceof each box created so far. An interest-ing variation would be to keep splittingboxes until the total variance falls belowa set threshold. This would let you com-pute how many colors are needed toquantize an image and get a certainquality level.

The Inverse Color MapOnce we have finished splitting cubesand determining representative colors,the new palette is built by putting eachbox’s representative color into a list. Toget from the original 24-bit color to theproper palette entry, a structure com-monly known as an inverse color map iscreated. This is a three-dimensional cubethe size of the histogram where each

point in the cube contains the paletteentry number for the color at those coor-dinates to be transformed into. In manyimplementations, the inverse color mapis built by filling in each box’s area with


Figure 2. Filling in the Histogram Boxes

Representative colorpoints for each box

This pointis closer to the repre-

sentative color of a different box

Figure 1. The RGB Colorspace Cube

Cyan

Green

Color atpoint(R,G,B)

X-Axis(Red)

Z-Axis(Blue)

Y-Axis(Green)

White

Magenta

Red

Yellow

Black GR

B

that box’s representative color number.That is not the way to do it. (I pull myhair out every time I see that.)

Consider the situation shown inFigure 2. You have a large box and asmall box, which are touching each other.Both have representative colors locatedapproximately in the center of the boxes.In the large box, a point exists right nextto the edge where the small box is. Eventhough it is in the large box, it is muchcloser in the color space to the small box’srepresentative color. By just filling in theboxes, the pixels of that color will not betranslated into the best available color.

There are ways to build the inversecolor map so that each coordinate ismapped to the nearest representativecolor, regardless of what box it is in. Wehave chosen the method published bySpencer W. Thomas (“Efficient InverseColor Map Computation,” GraphicsGems II, Academic Press Inc., 1991). Hiscode is included in the example programavailable on the Game Developer ftp site.

PerformanceIn terms of color quality, what is seen bythe human eye matters the most. Whatappears to be a strength of this algo-rithm is the results it produces whenquantizing to small number of colors.For statistical results, Xiaolin Wureported that the mean quantizationerror of variance minimization was one-third to one-ninth that of the olderalgorithms. Our own experiments yieldsimilar results. The difference in resultsgets greater as the number of colors getssmaller. For a game where only a por-tion of the palette can be spared for agraphic, this is good news indeed.

What about speed? In his paper,Xiaolin Wu was able to quantize a 256-by-256 image in 10 seconds on a Sunworkstation, using five bits of color. Inour PowerView program, we can quantizean 800-by-600 Targa file in about onesecond on a 486/66 in real mode. Theresults get even better in protected mode,where it is practical to use six bits of color.

The Final CurtainImage processing is a complex subject,and we had to leave out some issues to

avoid turning this into a book. It’s prettyclear that a large and growing amount ofgame graphics are coming from video,scans and other true color sources. Withthat, there is no reason not to use thevery best methods available to get theminto games and other programs, as longas they are practical methods. We hopethat by presenting a programmers-eyeview, and some practical working codewe’ll speed that process up and maybe

even help some of next year’s gameslook a little more vivid and stunning.Until next time, happy hacking. ■

Matt Pritchard and Rich Geldreich Jr.work together at Innovatix, a small soft-ware company in Garland, Texas. You cancontact them via e-mail at [email protected], [email protected], or throughGame Developer magazine.



/*——————————————————————————————————————*//* Calculate statistics over the specified box. *//*——————————————————————————————————————*/static void sum(int ir, int ig, int ib,

int jr, int jg, int jb,uint *total_weight,uint *tt_sum, uint *t_ur, uint *t_ug, uint *t_ub)

{int i, j, r, g, b;uint rs, ts;uint w, tr, tg, tb;uint *rp, *gp, *bp;

j = 0;

tr = tg = tb = i = 0;

rp = hist + ((ir * R_STRIDE) + (ig * G_STRIDE) + ib);

for (r = ir; r <= jr; r++){

rs = r * r;gp = rp;

for (g = ig; g <= jg; g++){

ts = rs + (g * g);bp = gp;

for (b = ib; b <= jb; b++)if (*bp++) /* was this cell used at all? */{

w = *(bp - 1);j += w;tr += r * w;tg += g * w;tb += b * w;i += (ts + b * b) * w;

}

gp += G_STRIDE;}

rp += R_STRIDE;}

*total_weight = j;*tt_sum = i;*t_ur = tr;*t_ug = tg;*t_ub = tb;

}

Listing 4. Gathering Statistics for a Colorspace Box

The Top 10Design Sins

T O P 1 0 D E S I G N S I N S

To learn how not to make a game,play at least part of a new oneevery day. Every week, play oneall the way through. I did thatfor more than 15 months forSega of America’s third-partylicensing department, part ofwhose charter is to play, evalu-

ate, beat, and, if possible, crash everygame from every publisher for every sin-gle Sega platform. And when a gamewas technically sound, but experientiallydeficient (that is, not fun), we had tohave at least 10 suggestions for improve-ment. As they say, someone had to do it.

We saw the same mistakes beingmade across game categories and plat-forms (yes, we looked at titles for SuperNES, 3DO, Jaguar, Duo, PlayStation,PC, and Macintosh, too) by publishersand developers. Each title could havebeen a better game, often withoutrequiring any more memory; usually itwould have cost only another week ortwo of design time. Following are thetop 10 design sins—ones my colleaguesand I saw over and over again—thatmade us shake our heads and ask, “Whatwere they thinking?”

1. Boring LevelsA dumbfoundingly oft-forgotten ingredient ofgame design is the veryworld a player stepsinto. Its particulars are

frequently assigned to the most juniordesigners. “Interactive scripting” boilsdown to “level layout.” For that matter,both are direct descendants of the “mis-sion and scenario design” that has beendone for boardgames since the 70s, whenAvalon Hill and Simulations Publica-tions Inc. (SPI) popularized historicallyaccurate—yet playable—war games.• The same enemies occur over and

over. There are no surprises.• Games are too linear and provide only

one way through.• Progress through the game does not

teach or require a growing repertoireof skills.

Designer Paul O’Connor, ofAlexandria Inc., advances a push andpull theory of level design, where playersare simultaneously pushed by enemiesand pulled by the allure of power-upsthroughout a level.

An action game without good levelsis just a bad action game. However, goodlevels without action still make for agood puzzle game.

2. The Sin ofRepetition

In theater they saythere is only oneunpardonable sin,“Thou shalt not bore.”

Level design is only one way to committhis offense.

For action games:


An expert i s someone who knowsAn expert i s someone who knows

not only the r ight way to solve anot only the r ight way to solve a

problem but lo ts of wrong ways.problem but lo ts of wrong ways.

— M a r v i n M i n s k y— M a r v i n M i n s k y

Z Z

ZZ

ZZ

• Background graphics and obstaclesare recycled from level to level withlittle or no change.

• The same attacks work over and over.No new weapons, or abilities, or sto-ryline advances occur as playeradvance through levels. Players do notget (or are not required) to mix uptheir behavior patterns.

• Mid-level “continue” markers arescarce or missing altogether, imposingtoo much time catching up to the dif-ficult parts after every “death.”

For strategy and role-playing games:• Menu structures are too deep. Players

find themselves playing with the cur-sor more than the game. This mostoften strikes video game ports ofcomputer games, when insufficientthought (or none at all) has gone intoreworking the user interface for a joy-pad instead of a mouse.

• The same maintenance tasks must berepeated incessantly. In 1978, a boardgame designer named Jim “Bear”Peters coined the term “grocerygame.” It applies all too well today toany game that forces players intorepeated back-and-forth tasks.

Designers should let the computerdo the drudgery; the player’s inputshould be the spark that drives theenterprise.

3. NotEntertaining(Enough)

Not boring is notenough. Sid Meier ofMicroProse put it this

way, “Who has the most fun in a game:the player, the computer, or the design-

er?” The designer did if the game istricky in a cheap way. The computerdoes if too much happens offscreen. • The game does nothing new or unseen

in other games already or fails other-wise to stand out in its genre. Knownas the shovelware syndrome, this situa-tion finds players asking, “Is this reallyany better than the 16-bit version?”

• The range of player actions is too lim-ited. Action games must deliveraction. If you can do only one thing,it’s called a “reaction game,” and thatgenre’s time is long past.

• “When you win, you still don’t win.”These games have cheese screens (vic-tory screens that appear when you’vewon) that are disappointing or miss-ing. Often, there is insufficient story-line reinforcement of success.

4. ProductionValue (OrFlat BellsAnd Whistles)

A pet peeve amongprofessional game ana-

lysts is CD-game music that could aseasily have come from a cartridge.Another gripe is presentationalsequences that clearly outweigh the restof the game in budget and productioneffort (which only conjures images ofThe Emporer’s New Clothes). You donot want people to say, “Great explosiongraphics, how come there’s no sound?”or “Where’s the music?” Players don’tcare if your budget ran out before youcould address these problems.• Sound effects are sampled at too low a

rate.• Sound is repetitive and annoying.

You dreamed last

night you got on the

boat to heaven, and

by some chance

had your PC by

your side...

To achieve the

sanctity of a perfect

game, avoid these

sinful situations.

Jim Cooper


Music loops are too short or the samevoice bites are cued over and over.

• Video sequences are offensive, usuallybecause nonprofessional actors areused, for example, members of thedevelopment team.

5. ConflictingAspects ofProduction

Surprisingly, uniformi-ty is more importantthan level of quality.

No game is expected to depict reality(yet); all a player asks is not to be jarredout of a willing suspension of disbelief byincongruities. • Music is inappropriate to the mood,

action, or audience.• Artwork does not match the target

audience.• Sound effects do not match the

graphic quality or standard level ofquality in the game’s genre.

6. Licenses LeftUnfulfilled

Hits-driven or not, ourindustry increasinglyrelies on licenses—leveraging proven or

expected consumer entertainment utilitysuch as sports, popular books and movies,cartoons and comic books, even packagedgoods like brand-name soft drinks. Mak-ing a sports game may seem like a fairlyintuitive proposition; turning movies intogames takes far greater care. It is notenough to punctuate action sequenceswith outtakes from the licensed product.On the other hand, don’t assume thatbecause comics and cartoons lend them-selves so easily to video game translationthe work is already largely done. It can bean advantage to have to face the chal-lenge of making a simple inanimateobject interactive.• Signature voices and phrases are not

included.• The design does not explore elements

of its license’s appeal.• The game could just as easily have

had a totally different title or maincharacter.

This final point is the acid test of

any licensed game, and one that everylicenser should answer for itself beforeauthorizing any licensee’s release.

7. Counter-IntuitiveWeapons andSpecial Moves

These errors exemplifythe difference between

showing and telling, between a gloss ondesign and the kind of gut gameplayplayers dream about.

• Powerful attacks are too similar ineffect or gameplay.

• Such powerful attacks are too rare orcommon or too hard or easy to execute.

• Special moves or weapons are illogicalin their comparative effectiveness.

Calling a magic spell a “Mega-Bloodcurdling-Turbo-Lightning-Suck-ing-Farfak-Zapster” only goes so far.The spectacle onscreen and aurally whenit’s loosed must be impressive and

uniquely appropriate. The joypad ormouse button combination to unleash itought to be demanding, yet intuitive.The effect in game terms should be dev-astating, but balanced by design ele-ments to preserve it from trivialization,such as scarcity of vital ingredients orlimited circumstances during which it ispossible.

8. DifficultyProperly setting agame’s challenge is athorny challenge itself.If a game is too easyoverall, it’s boring. But

so is infinite incrementing of difficulty;nobody plays a computerized game as aduel to beat a machine. That’s nineteenth-century (and early 1980s) thinking.• Optimal strategies exist and are obvi-

ous. The AI is weak or does notrespond to player actions at all.

• Ramping is uneven or flat. The flowof difficulty is uneven—it is too easyand then too hard, too hard and thendisappointingly easy, or never changesat all.

• Bosses—arch-villains to providefinal challenges at the ends of lev-els—are missing, too easy, or toohard. Only one or two tactics areneeded against bosses. Enemies orbosses don’t take damage like theplayer does.

Beware of creating pseudodifficulty,however, such as “mandatory hits,” ordamage that cannot be escaped at any skilllevel, even if nonfatal. Trying to lull theplayer into a false sense of insecurity is ano-no.

9. ExecutionA major game designsin is allowing thechallenge to arise morefrom navigating agame’s interface than

negotiating its story elements. Program-mers and designers are most prone tothis mistake; they cannot help but thinklearning and doing things the hard wayis fun. It is not. It’s work, the kind theyare paid to perform for the players.• Collision detection is too loose or



12345

Making a sports

game may seem

like a fairly intu-

itive proposition.

Turning movies

into games takes

far greater care.

tight. For example, when collisiondetection is too loose, players experi-ence fighting game “hits” that shouldor shouldn’t have landed. When it istoo tight, players must position aclimbing or jumping character’s spriteat precisely the correct pixel.

• Animations of actions are poorlytimed or have insufficient frames.Games simply lack state-of-the-artgraphics and sound.

• Basic character movement physics arelax. These physics include jumpingrange (which might be too far or tooshort), hang time (anything outside arange between apparent earth stan-dard and moon gravity needs justifica-tion), speed of motion, and acceler-o-meter functionality (after a half-sec-ond moving in the same direction, acharacter or onscreen mouse arrowshould speed up.).

If you aren’t able to create the nextnew technology, you should at least beable to execute the current standard well.

10. LowReplay Value

Games differ frombooks and movies inthe number of timesthey are consumed.

Games with linear levels give players noreason (or opportunity) to revisit scenesfrom new angles. The investment in theaverage game’s technical developmentcould stand to be exploited even more.And no matter what your graphics andsound budget was, after players see andhear those jewels a few times, the onlything they want to wrestle with is whatyou worked on for just two months outof the development cycle—the game.• Variable difficulty settings are missing.• High scores or low times are not

recorded, robbing players of the chal-lenge to try and beat them.

• Players don’t have a selection ofplayable characters to choose from.

• Insufficient “player-override” func-tionality. Players cannot skip cinemat-ic scenes and special effects.

This last is a cardinal sin all itsown; by unnecessarily fatiguing players,it mortally wounds replay value.

Always, always remember the experi-ence you offer will be consumed itera-tively, that is, over and over again.Make maximum user configurabilityyour friend.

Dos for each Don’tFortunately, where I come from, youdon’t complain about problems with-out offering solutions. Here are anumber of ways to avoid the 10 sinsI’ve outlined:

1. Boring Levels• Make demands on players. You must

know their capabilities, which isadmittedly not always easy.

2. Repetitiveness• Don’t stint on the preparation of a

great storyline. Treat the game moreas a novel than a short story repeatedover and over—or as a movie, not amusic video. If everyone thinks he orshe can make a video game, showwhy they are wrong.

3. Entertainment• Give good value.• Dare.• Lead, as opposed to manage.

4. Production Value• Have a production concept that

somehow fits on the back of your

Everyone participating in the design process can help avoid the 10 sins of game design.The burden should not fall on the developer alone.

Designer• You are not just designing a game, you’re crafting game elements to survive the mael-

strom of producer, marketer, and licenser reviews. Stick to your guns and learn to cre-atively outfox upper management. It may seem like a game unto itself, but you mustplay for you and your game to succeed.

Producer• Do your job. It’s not just spreadsheeting, or phone-mongering, or lunching. It’s oversee-

ing and delivering the game from the designer to the distribution channel.

Marketer• A high-variance strategy is actually your best career bet when dealing with games. At

early concept meetings, champion the designer. If it pans out, you can say you pushedfor it. If it doesn’t, you tried to talk market sense into them. When the game is almostready to launch, you must look beyond feature lists at tactical marketing meetings. It’syour job to figure out how to bring the game alive. Have the producer explain what’sunique about the game. It will take more than a few screen shots to communicate thatto potential players.

CFO• Quality sells. Much has been made of the unique marketing behind Doom and Descent.

Don’t forget—there was unprecedented quality in each game. So why not put thatincremental product development money your producer is begging for into next quar-ter’s marketing budget, under word-of-mouth advertising expense?

President• To get the best out of your people, give them the best of yourself. Are you duty-bound

to maximizing return on investment or increasing shareholder value? Your franchise asa publisher depends only on a reputation for quality product. Believe it or not, SpectrumHoloByte’s stock rose the last time it announced another delay in getting out its firstStar Trek: The Next Generation CD-ROM game. Perhaps this unexpected reaction fromthe “smart money” had something to do with the lesson the entire industry learnedwhen another publisher’s bug-riddled graphical adventure CD, The Lion King, experi-enced retail return rates rumored to have exceeded 50% of sales.

G O , A N D S I N N O M O R E


business card and still serves as a yard-stick against which every developmentdecision can be measured.

5. Production Coherence• Manage the development process,

that is, its participants. All are neces-sary, none is sufficient alone. Whenappropriate, tell them so.

6. Licensing• Build a game from the license up;

don’t just plug and ship your game (orlet your licensees do it for you).

• Know, define, and insist on makingcentral to gameplay the specific appealof your licensed property. If thelicense has any value at all, playing toits strengths is a recipe for success.

7. Special Moves• Extend the metaphors in your game.

You cannot tell players they are havingfun. They have fun by being fullyengaged. They will only be fullyengaged if they acknowledge andaccommodate differences you define.Make the player’s input and the result-ing game outputs consequential whileinternally consistent or the whole houseof cards comes tumbling down.

• The soul of video gaming is theepiphany of acts of desperation thatbecome intention. In a fighting game,it’s that joystick-slap or button-slamcombination—born of a split second’sagonized frustration—that miracu-lously looses the perfect mid-aircounter-throw. Like math, it makes“of course” sense after you’ve done it.

8. Difficulty• Defy passivity at every turn.• Surprise, but play fair.

9. Execution• Optimize the inevitable compromises

feature for feature by weighing benefitagainst benefit in play value. Use mar-keting for focus groups and user test-ing throughout the project.

10. Replay Value• Roll at least three games (if not five, or

17) into one. Star Trek and Star Wars

appealed to children, teens, and adultsthrough spectacle, action, and ethicalcomponents. Three types of peoplecould enjoy them, and anyone can stillenjoy them on three or more levels.

The Eleventh SinThe 11th sin is failing to realize these arenot design sins, but management sins. Nocompetent game designers willingly com-mit them—their masters do. As Gordon

Walton says, “Everything in this businessconspires against good games.”

The platform wars among 32-bitconsoles have already spread to the PC.It happened when Windows 95 beganpromising true plug-and-play ease of use.Race your products to market, but avoidthese simple errors. It’s worth it to takean extra three weeks design time up frontand tack another two to three weeks ontothe end of the cycle for polishing.

Marketing myopia is the technicalterm for the flip side of the “not inventedhere” coin. So you have the technology.Your game can do what has never beendone before or something wildly betterthan has ever been done. That’s not whypeople buy it. They will buy it—and con-tinue buying it—because it’s fun. ■

Jim Cooper, a gamer with an MBA,has founded software and game companies,consulted to money managers, and taughtmarketing. He is the founding editor of TheCGDA Report, and can be reached [email protected].



Grateful acknowledgment is made toSteve Ackrich, group director, Sega of

America Third Party Licensing andAcquisitions, for permission to print thisarticle based on materials I preparedand delivered with him at the SegaDevelopers Conference, March 1995. I’dalso like to thank him for admission togameplay bootcamp. And to Gary Barth,my drill instructor, now at Sony Comput-er Entertainment of America and theproducer of Battle Arena Toshinden.

A C K N O W L E D G E M E N T S

The Play’sThe Thing

I N T E R A C T I V E S T O R Y T E L L I N G

How do you keep a game inter-active and also weave in agood story? This question isbecoming more important inthe gaming world. It’s possi-ble now to make storiessomewhat variable and inter-active and to make great

game experiences more dramatic andcharacter oriented. But the possibility oftruly merging the interactivity of gamesand the suspension of disbelief of dramais the carrot dangling before many mul-timedia professionals today. Yet, is thismerger possible? “It seems like the term

‘interactive story’ is an oxymoron,” saysJonathan Knight, a producer with Via-com. “It seems like you can’t have oneand the other. It’s one or the other.”

Still, the possibility is too cool toignore, and so game developers contin-ue to search for ways to marry the twoart forms. They’ve come up with manyapproaches, some more successful thanothers. “We don’t have the polish of thethousands of years of work that hasgone into regular stories,” saysLawrence Schick, managing director ofthe interactive story and strategy groupat Magnet Interactive. “In comparisonto what a playwright or screenwriterdoes, the stuff we do is awkward andunpolished, and it isn’t as satisfying.”

People working with interactivestorytelling in any form it may take—beit within the confines of a shoot-em-upaction game or a puzzle-oriented mys-tery game—face many challenges asthey search for the key to a successfulinteractive experience. Here are a fewthings they’re wrestling with.

The Illusionof Player’s ChoiceMany interactive story games have theultimate goal of giving the player thefeeling that his or her decisions areactually affecting the story. “That’s theholy grail,” says Schick. “Obviously,within very strict limitations, you wantthe player to write the story by the deci-sions they make.” This has been a toughgoal to reach, so far. Branching plotstories, in which a story unfolds as theplayers make various decisions, are oneapproach to interactive stories, but thestory must be limited or the decision

Hounds and Jacyls: Integrating puzzles into a story adventure without disrupting the player’ssuspension of disbelief is one of the biggest challenges of interactive stories. InHyperquest’s new title, Archeologica, the game puzzles not only move the story forward ,they give the player a deeper connection to a central character in the game.


Kri

s K

ila

yk

o

tree becomes astronomical. Graphicadventures, where a story is revealed tothe players as they succeed in solvingpuzzles or winning battles, are anotherapproach. This genre, which includesthe Kings Quest Series and WingCommander III, offers gameplay andstory together, but you have story seg-ments followed by gameplay segments.The two aren’t integrated.

Computer role-playing gamesbased on building up skill levels andpossessions, such as Sword of theSamurai, let you model a limited set ofa character ’s personality traits—abstracts such as a character’s aggres-siveness, hostility toward the player,and honor—and manipulate the num-bers with algorithms and routines thatgive the impression the characters arereacting to events in the game.

You can also incorporate a dramati-cally correct story into the process bysubmitting plot elements to the samequantification. You can set up algorithmsthat weight a character’s options to mir-ror another character’s (so it appears thatone character is following another), holdback options for dramatic effect (onlyafter your player’s character marries thevillain’s love can the villain have theoption to send assassins after you). Thispresents the illusion of an unfolding storybased on the actions the player takes—the characters appear to react to what theplayer does. But you usually have a limit-ed number of generic and repetitive dra-matic pieces to work with. “The problemis creating something that apparentlystitches itself into a movie, withoutrepeating, and without having to be 10CD-ROMS.” says Schick.

Player as HeroViacom’s Jonathan Knight looks at the“holy grail” a little differently. To him,the key to a successful interactive storygame is aligning the player with thehero’s objective. It’s all about makingsure the player and the hero want thesame thing. “That’s the way moderndrama has always worked,” explainsKnight. “Stanislavsky felt that everystory ever written hinges on the objec-tive of the hero. Whatever the herowants out of the story will drive thatstory to its conclusion.”

It’s this element that Knight feelsmakes highly interactive games likeAsteroids and Doom, and even morepuzzle-oriented games like Myst, sosuccessful. “Every game back to Aster-oids is really an interactive story,” saysKnight. “In Asteroids you have a hero(the little ship), you have antagonists(the rocks), there’s setting (space), youhave rising action (more rocks comingat you), and there’s climax—it alwaysends tragically with the ship gettingblown up.” The objective is clear to theplayer immediately, and there’s no con-flict between what the player wants andwhat the hero wants.

But Knight says this element islost in many interactive stories. Sure,it’s easy to align yourself with a ship indanger—that’s based on “sweaty palm”emotions, fear and survival instinct. Butwhat about objectives that are morecomplex: something like Hamlet’sdilemma, for example, in which ourhero’s objective is to avenge his father’sdeath. We might be drawn to thisobjective deeply enough to observe pas-sively at a Shakespeare festival, but are

All the rock ‘em-

sock ‘em graphics in

the world won‘t

make up for a bland

story. Today‘s

designers are rising

to the challenge and

creating meaningful

plot lines as well as

beautiful visuals.

Barbara Hanscome


we involved enough to play “HamletInteractive?” Plus, the story is alreadywritten, how can we really affect theoutcome?

Games that are structured so thatthe core objective is achieved through avariety of sub-objectives work well tokeep the player moving along on theright path.

For example, if you were creatingthe “The Fugitive Interactive,” the hero,Richard Kimball’s, main objective is toprove his innocence in the murder ofhis wife. But in Act 1, his mini-objec-tive is to escape incarceration. In thefilm, he achieves this objective by jump-ing out of a bus, disguising himself as adoctor, stealing an ambulance, hiding ina sewer system, and jumping off the topof a dam. “We can offer five more, or10 more, to the player, so that they’renot forced down the path the film fol-lows,” explains Knight. “These differentactions could suit a whole range of per-sonalities, and yet, sort of unknowinglyto the player, the character is stil lachieving the objective that we have setfor him.

But that doesn’t completely solvethe problem of merging the hero’sobjective with the player’s objective.There will always be options the playerwill want to take that aren’t optionspresented in the game. What Knightsuspects might be the key is simple,Pavlovian condition/response. “Becausestories are so psychologically complex,and the distance between what the heroand the players want is so great, I thinkwe need to use animal conditioning onour players, and basically reward andpunish them psychologically, right inline with the objectives of the story forcertain behaviors.” He admits it soundskind of diabolical, but it happens all thetime in games. “If you think back toAsteroids, if you didn’t destroy therocks like you were supposed to, if youjust sat there and cruised around anddidn’t go after the objective, then theystarted playing this music. It makes youreally nervous and you get really scared.And if you go after the rocks, it stops.They’re conditioning you.”

But, how does Pavlovian condi-

tioning fit into a complex story withcharacters, dialogue, and plot? “If you’rereally going to condition someone, youcan’t be too obvious about it. You don’twant to kill them if they walk thoughthe wrong door, for example. That’s notconditioning, that’s just irritating,” saysKnight. The goal is to reach the playerat a deeper level. “You don’t want toreward and punish actions as much aswant to reward and punish emotionalresponses. Emotion is what is deepdown and subtle, and that’s what theplayer is not going to be conscious of.”

Making FeedbackWork for YouKnight admits he’s still working onexactly how to create this subtle emo-tional conditioning. He thinks feedbackfrom supporting characters might beone solution. “Other characters canwork to goad the hero in certain ways.In the Interactive Fugitive, for example,where the goal of the hero is to provehis innocence in the murder of his wife,if a guy came up to Richard Kimballand said, ‘You’re a murderer. You killedyour wife,’ and then the player decidesRichard Kimball can beat the crap outof the guy, that behavior—even thoughit’s violent—is conducive to the objec-tive. And we want to reward the playerfor that.”

Feedback is also crucial to tell theplayer that his or her decision made adifference to the story. “Feedback isalmost the hardest thing to do,” saysSchick. “Letting the player know whatdifference he or she made in a storyimplies a couple of things. First itimplies tipping your hand as to whatwould happen if the player didn’t makea decision, and second, it implies thatyou have to somehow, in some brutalway, tell the player what difference thismade to the other characters, which iswhat matters in the story. It can feelcontrived, but you’ve got to have it. Inan interactive story the players are mak-ing the decisions and you have to setthings up carefully so that they see theimplications and results of their owndecisions.”

Schick points to the game Johnny

Mnemonic as an example of a gamethat successfully melds action and story,however the feedback is missing. Thegame is a linear movie in full-screenMPEG until the player has the optionto interact, then the screen moves toletterbox. “In Johnny Mnemonic youget to make several kinds of decisions.The hard part is knowing what kind ofdecision you get to make at any givenmoment. They don’t give you a cue asto what kind of choice you’re making: Isit a movement choice, should I go leftor right? Should I pick something up orput it down? Is it a fighting optionwhere I should kick and punch orblock?” explains Schick. The playershave a limited time before the moviegoes back to full screen. “When youmake your decision matters as much aswhat you decide to do.” says Schick. “Ifyou don’t do anything, it often goesinto a bad end, you didn’t act fastenough and the bad guys blow youaway.”

Feedback is also necessary to avoidone of the most basic trouble spots ofinteractive stories: bottlenecks, in whicha player cannot move forward until heor she solves a puzzle. Bottlenecksdestroy suspension of disbelief and arejust plain frustrating for the player. Inhis games Castle of Dr. Brain andQuest for Glory IV, David Cole pro-vides a help mechanism to avoid thisproblem. “I tell the player up front thatif you click on this button five times,the first four clicks will give you a hint,and the fifth click will solve the puzzlefor you.” To keep it challenging for theplayer, the fifth click doesn’t reveal thesolution to the puzzle, but it moves theplayer forward.

“They did the same thing in the7th Guest,” explains Cole. “In eachgame puzzle you can go down to thelibrary and there’s a hint book that tellsyou a little bit about each game puzzle.And if you consult the book severaltimes in a row, eventually it says, ‘oh,okay, you solved the thing.’”

But providing help isn’t goodenough, you have to let the player knowhelp is available. “In 7th Guest, I didn’tknow that you could get past the puz-



zles by using a hint book until I did itby accident,” says Cole. “It’s a trickytask, because on one level you want theplayer to be totally immersed in thefantasy of the game and not thinkingabout the computer. On the otherhand, if you’ve got these helpful thingsbuilt in, it’s nice to make that obviousto the player that those things arethere.”

Integration ofPuzzles and StoryGames such as Wing Commander IIIand Daedelus Encounter come close tomerging the excitement of game playwith strong characters and storylines.However, it’s not really a mix. Thestory happens, then the fighting hap-

pens, and when you’re not fightingyou’re stuck watching a very set scriptthat you cannot control. Integratingpuzzles and story is even more challeng-ing for edutainment designers, who relyon puzzles to teach subject matter andtest knowledge. How do you makethese a seamless part of the experience?

Game producer Julia Mair and herteam from HyperQuest wrestled withthis problem in their two educationaltitles, Astronomica and Archeologica,which not only mix gameplay and story,but education as well. In Astronomica,the player learns about astronomy byhelping a teenage heroine named Sarasave her dad from captivity in an obser-vatory. The player navigates through aphotorealistic three-dimensional envi-

ronment, similar to Myst, and musthelp Sara reset each exhibit in theobservatory to get the computer systemup and running. Each exhibit involvesan educational game or puzzle to solve.Mair felt the game was successful formany reasons, but the puzzle and storymix didn’t hit the mark. “We felt thatwhat was happening was that we wereforcing the player to stop the action.We wanted the player to move throughthe dramatic structure and never, orvery infrequently suspend their disbeliefto play the games. Many of the gamesare challenging and fun and interesting,but you still have to stop, you have toplay the game, you have to get it, andthen you move on.”

In Archeologica, the learningaspect is still dependent on puzzles andgames, but Mair and her team thinkthey integrated them more successfully.They set up a main objective for theplayer similar to the one that exists inAstronomica: the player must help twocharacters, Sara and Elija, find and res-cue a character trapped within an envi-ronment. In this case, the character isElija’s mother, an archeologist trappedsomewhere within an archeological digsite. The games and puzzles are layeredwithin the experience. For example, theplayers don’t just passively hear aboutthe Egyptian Book of the Dead afterpressing a button, they also travelthrough spaces in the dig that representpassages of the book itself. They don’tjust learn the significance of the SolarBoat to the Egyptians, they maneuverone through a secret passageway. Someof the games are the same gamesEgyptian children played, and certainplot twists are revealed to the playeronly by using knowledge they’ve accu-mulated in the game, such as decipher-ing hieroglyphs or using tools archeolo-gists use.

Then they took it one step further.“We didn’t want the player to feel thathe or she was pitted against how cleverthe developer can be or grounded in atwitch arcade element only,” says Mair.To avoid this, they created anothercharacter, an archeologist named Bur-ton who once inhabited the dig site



Combining an interactive story with a challenging objective requires vision—liter-ally. Here are a couple of tools that can help you visualize the twists and turns ofyour game’s structure from plot line to character development. Use these tools todiagram, outline, and brainstorm projects, and you will begin to understand theart of telling an interactive story.

StoryVision, by the company of the same name, is an organizational tool for interactivegaming used to visually diagram plot structure and characterization. Analogous to adetailed blueprint of an interactive script, this tool allows you to map out the “game plan”through the use of bubbles and lines, similar to a flow chart format. Once the scene bub-bles are created, you can attach text to the bubbles in any word format. CD Noir’s DaveDengler, who has used StoryVision says, “It’s also great for brainstorming.” Used by writ-ers, producers, and developers, this program links with any word processing program andcan organize the text in a screenplay style. Although the program does not include its owntext editor, user Chris Taylor of Interplay Productions says, “I like the program’s simplici-ty. It is quick, easy to use, and makes changes rapidly.” For more information contact Sto-ryVision at (310) 392-5090.

Inspiration, a diagramming and outlining tool by Inspiration Software Inc., can be used asa brainstorming tool and a diagramming tool. With a choice of over 500 symbols includingthe full ANSI flow charting symbol set, and color, shape, and size capabilities, this toolmakes it easy for you to differentiate between visually linked ideas. If you still haven’tfound the perfect symbol for your idea, Inspiration lets you import your own graphics. Thediagram view also lets you create smaller diagrams that connect to parent diagrams. LynnPierson, product specialist, says, “There are hundreds of levels of diagrams. Each diagramhas the capability of connecting to a child diagram.” Each symbol in the diagram has alinked Notes Window allowing unlimited pages of text, and the multiple zoom featureoffers a variety of perspectives to help map out your game’s intricate structure. Togglingfrom the diagram to the outline allows you to view your plot structure or characterizationin a text format. Complete with its own text editor, Inspiration can revise, edit, and formatin the outline view. For more information contact call Inspiration Software Inc. at (503)245-9011.

—Deborah Sommers

T O O L B O X

where the game is set. He has set up thepuzzles and traps to protect the trea-sures he’s discovered throughout hislife. The player discovers various aspectsof Burton’s personality through theintricate, Rube Goldberg-like gamesand puzzles he has created, and fallsinto a sort of love-hate relationshipwith him. Instead of interrupting thestory with a puzzle, and frustrating theplayer with a game created by someoneelse, the puzzles take the player deeperinto another layer of the story.

Of course, veterans of role-playinggames, mystery games, and adventuregames are old hands at this. This iswhat their games are all about. “There’sa misconception in the adventure gamefield that the puzzles are arbitrarilypasted in. A lot of our puzzles are aboutrelationships,” explains Corey Cole.“Figuring out how to interact with dif-ferent people, how to interact with thebartender, how to meet someone, howto get them to join your party, basicallyhow to help them so they will help you.That makes the game world feel a lotmore real. Look at movies, they’re allabout character relationships, and thathasn’t been done very much in gamesthus far. We’re trying to bring muchmore of that in.”

Living, BreathingCharactersBut how do you make those charactersinteresting enough for your player towant to interact with them? How doyou telegraph a character’s personalityand motives and communicate thesetraits clearly and quickly to the player?HyperQuest’s Mair says it comes downto trading off when stereotypes willwork for you and when they will not.

In Astronomica, Mair and her teamreally wanted to create a strong femaleheroine, but one that was also a regularkid. “In the first scene, we wanted it tobe clear to the player that Sara was aleader, we wanted to show a young girlwith a problem who is strong enough totackle it.” In the first scene, Sara makes adecision that will guide the entire game(she must reset each exhibit in the labo-ratory to bring the computer system back

online). This is the main objective thatdrives the game, so the player needs totrust that her decision is right. TheHyperQuest team worked hard on thefiner details of the character, choreo-graphing her movements, her tone ofvoice, and her physical posture so thather personality and situation wouldcome across loud and clear.

When it came to supporting char-acters, such as Sara’s father, an eccentricscientist with less time on screen, theylet stereotypes work to their advantage.“We wanted to telegraph his passion,that he’s committed to what he does,and that he’s more than capable of

putting his shoes in the refrigerator.We tried to choose where stereotypingworked for us, because we wanted tocue into a whole set of basic culturalIDs.”

In games and film you can stillleave out a lot of information becausethe player will fill it in. “It doesn’t takemuch to create a relationship between

the player and a character in a story,”says Lori Cole, who wrote the Questfor Glory series with husband CoreyCole. “The player will put the imagina-tion into the character if the game has abase for them to build upon.” Herfavorite anecdote to support this theoryhas to do with the game Wing Com-mander I. When players got to thescene in the game where one of thesupporting characters died, BBSes werefilled with posts from people lamentingthe character’s death. “People postedthings like ‘She was my love! We had arelationship!’ They really didn’t have alot of interaction with this character,but that didn’t matter.”

Chris Thompson, an interactivescript writer agrees. In his article “Inter-active Drama, the Rules of Storytelling”(Morph’s Outpost, May 1995), he writes,“Developers shouldn’t be afraid to with-hold information. If a user is interestedin a character or situation, there’salmost no limit to the amount of‘unknowns’ that he or she will tolerate.In fact, unknowns generate intrigue,suspense and mystery.”

What’s Next?Where is the industry going with inter-active storytelling? Some say multime-dia is waiting for someone like StephenSpielberg (or Einstein) to come solve allthe problems. Some are waiting for the“film/game genre” to die so they can getback to true game experiences. Somesay it’s going to depend on motion cap-ture technology and artificial intelli-gence before we’ll be able to realize thetrue integration of interactivity andstory. “We’re really wrestling with stuffno one has wrestled with before, and forfairly high stakes,” says Schick. “Sopeople get either desperate about it, orthey basically want to fall back on whatthey know will work. The only reasonwhy any of it works at all is because theconcept of actually experiencing a storyrather than watching it is so compellingthat people are engaged, despite theembryonic form of the art.” ■

Barbara Hanscome is managing edi-tor of Software Development magazine.


Astronomica and

Archeologica, two

titles from Hyper-

Quest, not

only mix gameplay

and story, but

education as well.

Artist’s View remains prettymuch confined to graphicsissues. However, as digitalentertainment has matured—has begun to mature—itsometimes happens that theborders separating visual con-siderations from other game

elements become blurred. When, youmight reasonably ask, are game graphicsanything more than just that? Theanswer: when they are an integral part ofthe design process of the game as awhole, interwoven from the earliest con-

ceptual considerations with the overallfabric of the game, inseparable from anydiscussion of the title’s creation or itseffectiveness. Such is the case withBuried in Time, sequel to the Journey-man Project, labored on for two years byPresto Studios and released this summerby Sanctuary Woods.

Many companies pay lip service toan integrated approach to design, yet,while ever-greater importance is certain-ly being placed on quality graphical con-tent, in most instances game visuals stilloccupy a largely decorative role. With

Creationof a FantasticWorld

Nothing brings a game

to life so much as

realistically rendered

detail, no matter how

minute. This month,

David Sieks turns an

artist‘s eye to Buried

in Time, the new time

travel game from

Sanctuary Woods.

David Sieks

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


Though a picturesque ruin is all that remains today of Richard the Lionheart's 13th centurycastle, Presto artists turned to contemporary sources to recreate it in stunning detail forBuried In Time.

Buried in Time, graphics do not serve asmere adornment, however. Nor for thatmatter is another important creative ele-ment—story—just a weak scarecrowframe on which to hang gameplay.While Presto’s ultimate objective was afun, playable computer game, there wasalso a desire to create a deeper and richerexperience than the typical adventuretitle. Presto’s president and Buried inTime producer Michel Kripilani, writerDave Flanagan, and creative directorPhil Saunders spent more than fivemonths assembling the skeleton of agame to realize that ambition, all beforeeven going into preproduction. From the

very start, visuals, gameplay, and storywent hand-in-hand, and that integratedapproach is apparent in the way thegame works so successfully to draw theplayer into its world—or rather, worlds.

Setting the SceneIn Buried in Time, the player assumesthe role of a time-travel agent wronglyaccused of tampering with the past. Tovindicate yourself, you must escapehouse arrest and journey through timeand space to the several zones in ques-tion in search of clues to the identity ofthe true culprit (solid adventure gamestuff, but still a welcome change fromthe onus of saving the universe yetagain). During the early design process,the team at Presto considered manytime-travel destinations. One chief crite-rion was visual appeal; Saunders wantedperiods and places that would lendthemselves to the lush three-dimensionalgraphics he had in mind. Freshness wasalso a factor (Egyptian pyramids failed

that cut), and of course each destinationhad to offer gameplay potential.

The Presto game design team fur-ther complicated their task by opting forhistorical accuracy, despite the fantasticalplot. This meant exhaustive research, notonly for visual and descriptive referenceson which to base designs, but also forconvenient gaps in known history thatprovided opportunity for embellishment.Eventually, along with several futuristicenvironments, three historical settingswere chosen: the medieval castle ofRichard the Lionheart, a Renaissance eraworkshop of Leonardo da Vinci, and aMayan ziggurat.

The first two proved especially fer-tile subjects for Saunders and supportingconceptual designer Victor Navone tobuild upon. Little remains today ofRichard’s Normandy castle, ChatteauGaillard, which fell in the early 13thcentury, but Saunders used contempo-rary sketches and descriptions to fill inmany of the gaps, and was able toextrapolate the rest to recreate a whollyconvincing environment. On the otherhand, despite its impressive architecturaldetail, the da Vinci workshop is pureinvention, hypothesizing the great man’swhereabouts and activities during ashadowy period in his history. Again,due to meticulous attention to knowndetails—and equally meticulous fudgingof the rest—the setting attains an eeriedegree of authenticity.

Throughout the two years it took tocomplete Buried in Time, environmentdesign, story, and gameplay elementsadvanced apace. From the early plot andenvironment decisions, Saunders movedon to conceptual sketches, Flanagan

continued to flesh out the story, andKripilani began to assemble the produc-tion team. Much back and forth wasinvolved, and many changes were madealong the way, but the basic frameworkthat had resulted from those first monthsof brainstorming remained in place tohold the project together through itsgrowth. Though time-consuming, suchan integrated approach helped to create acohesive and balanced game, with a storythat carries you along while the detailedenvironments draw you in.

Designing for ImmersionThe game’s graphics feature rendered,point-of-view interaction spots linked byfull motion sequences. The level of visualdetail in Buried in Time is astonishingand, combined with excellent soundeffects and an atmospheric score, con-tributes to an environment thatenvelopes the player like a warm bath.Drawing the player deep into the gameworld was the goal, and no effort wasspared to accomplish this end. At times,this was a grueling commitment to standbehind, as so much of the detail is extra-neous to actual gameplay. But the Prestophilosophy is that detail is what con-vinces the player to suspend disbelief andenter the illusion, and when it comes toillusion there’s no such thing as beingtoo convincing. Its 40 minutely detailedenvironments contain roughly 10,000three-dimensional objects. By the end ofthe project, Presto artists had more than40GB of visual data online.

One reason all these details achievesuch a convincing effect is likely Saun-ders’ background as an industrial design-er (he’s still one of the lead car designers



Presto designers did their homework to ensure the several historical settings were accurate andconvincing in their detail, even for places that never existed, like this cloistered garden path fora palatial workshop Leonardo DaVinci might have had in Milan— but didn't.

All the painstaking research and carefuldesign is brought to life by artistic use oftextures and lighting.

at Nissan). Even fantastic science-fic-tional settings are grounded by his prac-tical form-follows-function approach.He also has an obvious flair for the dra-matic (before automobiles, he designedtheme park rides) and these strengthsprovided the guiding vision for thePresto art team, a vision Saunders com-municated by multitudinous sketches,marker comps, and lots of arm waving.

Though their creative director knewwhat he wanted to see and provided astrong conceptual starting point, theteam delegated completion of the art-work to various departments, where thevisual guidelines were fleshed out and

further details added. Conceptualsketches were turned into three-dimen-sional models using Form-Z, fromAutodessys Inc. Three-dimensionalartists Jose Albanil and Leif Einarssonfound Form-Z an excellent and veryrobust program, and as one of the first tooffer Boolean operations on the Macin-tosh, this tool allowed rapid creation ofthe many complex objects in the game.The three-dimensional models werethen passed to E.J. Dixon III and Frank

Vitale for texture mapping. Rather thansimple nontiling textures, materials andrelief maps were created in Photoshop(Adobe) that exactly fit each object.

Finally, the completed three-dimensional environments were lit, ani-mated and rendered with Electric Image(Electric Image Inc.), which Kripilaniunreservedly describes as “hands-downthe best 3D animation package availablefor the Macintosh. Nothing else evencomes close.” An optimized Phong ren-derer obviated the need for time-con-suming ray tracing, allowing animatorsShadi Almassizadeh, Eric Hook, andEric Fernandes to complete renders in a

fraction of the time while maintaining ahigh level of quality.

Though a different departmenthandled each stage of the production,there was much communicationbetween the various artists involved.Often, pieces had to be sent back up thechain when a texture didn’t work quiteright or an animation required an objectto be articulated differently. The guid-ing dictum was that it wasn’t done untilit was right. Shepherding it all along

was project manager and vice presidentFarshid Almassizadeh (yes, they’rebrothers), whose job it was to see thatboth schedule and high standards weremaintained.

All the graphics for Buried in Timewere generated on Macintosh comput-ers, mostly PowerMacs, with PowerMac8100/100 systems sporting 140 MBRAM and 2GB hard drive space as ren-der servers. As Kripilani explains, thebest graphic creation tools are availablefirst for the Macintosh platform. “Whenyou are on the bleeding edge, like we are,you need the best tools as soon as theyare available.”

The Well-Dressed Time TravelerWith such photorealistic detail going intothe environments, the team decided touse live action for the occasional humanpresence. Even the best attempt at a vir-tual actor would not be realistic enough,they felt, and would fracture the illusionSaunders and the Presto artists hadworked so hard to create. But incorporat-ing live action presented its own problemsand proved a complicated process.



The decision to incorporate live action video rather than graphically rendered computer 'actors' drove the design of the time-travelling biosuit, whichwas transformed into an actual costume by a Hollywood special effects company.

The first step was finding an actualvideo camera lens that would match theperspective of the rendered environ-ments. This done, Saunders was able todesign ahead of time the environmentsin which the digitized actors wouldappear. On the set, marks were placed toguide the actors through the virtual ter-rain, and lights were situated to replicatethe lighting effects that would appear inthe rendered environment. For example,a yellow light connected to a flicker boxcreated the effect of torchlight for thecastle scenes. Composited into the ren-dered scene (with Aldus/Adobe AfterEffects), the digitized actor looks moreconvincingly a part of the picture thanprevious experience of composited videoand computer graphics might have ledyou to expect.

The decision to use live action gen-erated another issue: creation of the “bio-suit,” a bulky, armored personal time-machine worn by the hero and his fellowtemporal agents. Further, the fact thatthis item would have to be a real object,worn by a live actor, forced certain designconsiderations. The original plan hadbeen for a suit composed of large, highlyreflective metal plates. First, the largeplates had to be segmented to allowmovement. Then the reflective surfaces

had to be changed to a very matted metalto avoid picking up reflections of the bluescreen in front of which the video was tobe shot. In its final state, the design forthe biosuit looked like a cross between anold-fashioned deep-sea suit and the robotfrom Lost In Space.

The actual suit was constructed byAll Effects Company in Hollywood,Calif., using a complicated process inwhich each section of the suit was carvedfrom foam, following Saunders’s designspecifications. A mold was then pulledfrom the foam carving, a plaster castpulled from the mold, and finally a vacu-form plastic piece pulled from the plastercast. The pieces were sewn onto a foambodyform to give the suit bulk withoutundue weight (though the final productstill weighed in excess of 40 pounds).Special removable identification markingswere used, so that during the game several


The wealth of detail in Buried In Time called for designs running the gamut from a sprawlingspace station all the way down to this surprisingly useful handheld cheese food dispenser.

Death scenes, painted in loving detail by Gary Glover, accompany a description of the agent'signominious demise (in this case, lactose intolerance).

agents could be shown suited-up, thoughonly one costume had been built. Beforeyou rush to order yours for next Hal-loween, you should know that the gang atPresto considered this suit a deal at$25,000. (For that price, you could buyyourself a nice Nissan.)

Besides being a neat costume, thebiosuit also provided a logical game-

world excuse for the interface. Becauseyou, the time-traveling player, are con-stantly sealed within this futuristicMichelin Man getup, your view onto theworld is through the suit’s video displaycamera, which is fed to a smallish screenin the center of the interface, surroundedby inventory and other controls. Thesecontrols are simple, straightforward, and

work so well that they quickly become allbut invisible to the player, who is bythen engrossed in the beautifully ren-dered scenes in the view window. To theuser, this interface is so deceptively sim-ple that if you’ve never attempted todesign one yourself, you might nevercredit that it was the result of threemonths of teamwork.

In almost no other regard, however,does Buried in Time appear to be a gamethat was easy to make. If you can stepback from the illusion long enough toadmire the depth of detail evident at alllevels of this game, you realize that it hasgut-busting effort written all over it: “It’samazing how draining these projects canbe,” says Kripilani. “We are still trying tobring our brains back from jello-land.” ■

David Sieks is a contributing editor toGame Developer. You can contact him viae-mail at [email protected] orthrough Game Developer magazine.



The settings in Buried in Time are so richand compelling that you are prone to for-get your objective and simply explore ingape-jawed wonder.

Item Number

Design documentation and script 300 pagesEnvironments, rooms 40Preproduction sketches 1,000Individual three-dimensional objects 10,000Total number of polygons 10,000,000Textures 6,000Animation, frames 30,000Visual data in final game 25GBAll-nighters 100

Table 1. Buried in Time Statistics (Figures are Approximate)

Documents

december/january 1995twvideo01.ubm-us.net/.../GDM_DecJan_1995.pdf · 2 GAME DEVELOPER • DECEMBER/JANUARY 1995 GGAMEAEM Editor Larry O’Brien [email protected] Senior Editor Nicole