art of quake 2

company) because we work together sowell as a team. Sure, we each have ourparticular strengths and weaknesses,but in the end, any of us can do anyaspect of the art needed for the game.The strength of the three-man artdepartment at id comes from experi-ence, hard work, and talent. AdrianCarmack, Kevin Cloud, and I createdthe art for QUAKE 2 (and the upcomingmission pack), and this article revealshow it all came together.

Production Design

O ur team begins the art processwith a solid production design

and tons of sketches. This is the basisupon which we build models, createmap textures, or skin characters. Wecontracted a very good productiondesign artist to help with the environ-ment concepts for QUAKE 2, but for themost part, conceptual art and produc-tion design comes from one of thethree artists here at id. Although we

had to design the art based on our gamedesign ideas, our main goal was simple:“Make it cool.” That pretty muchsummed up our design philosophy.

Our team went for a grungy, sci-fi lookfor QUAKE 2, so the enemies are barbaricraces of miscreants sporting an array ofcybernetic prostheses. The rationalebehind this design was that the inhabi-tants of Stroggos (the planet where thegame takes place) aren’t much into aes-thetics and are purely a warlike, spartanrace. The good guys were designed witha futuristic military look. Weapons,armor, and other aspects of the TerranCoalition of Man are easily recognizableand not too far removed from contem-porary military and weapon design. Our

intention was to spare the player theeffort of stretching his or her imagina-tion too far in pondering the purpose ofan object. Is this a weapon in my hand,or is it a bread-maker?

Noticeably missing from QUAKE 2’sproduction design was any form ofdemonic symbology. This wasn’t due toany political or publisher-induced cor-porate pressure; it was because it didn’tfit the theme of the game. If the Strogghad developed into a magical/nether-world-dependent race of conquerors,we would have had plenty of demonsrunning around doing demon-typeactivities. QUAKE 2 is about kickingsome alien butt on their turf and ensur-ing mankind’s future survival.

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

36

A R TQ U A K E

The Art of QUAKE 2b y P a u l S t e e d

s in nearly all aspects of the company, the art

department at id Software runs on pure synergy.

That is, no real distinct lines of responsibility

exist among us three artists (other than the fact

that fellow artists Kevin Cloud and Adrian

Carmack — along with programmer John

Carmack — also happen to own theAAAfter attending 22 different public schools spanning five states, serving his countryfor six years, and bouncing around Europe for three more, Paul Steed taught himselfhow to create art on a computer at the University of Origin (Austin branch). Afteralmost finishing up a 4-year degree in low-polygon model creation and animationand cinematic techniques, he spent time at Iguana Entertainment and VirginInteractive Entertainment before being recruited to the Mt. Olympus of PC softwaredevelopment, id Software. He doesn’t plan on going anywhere else anytime soon.

Level Texture Maps

A lthough technically there are onlythree artists at id, an argument can

be made for including the level design-ers in the pool of pixel and vertex push-ers. The designers make maps, and inorder for them to build the world, theyneed plenty of building material. Weused an in-house editor (designed byJohn Carmack), which allowed leveldesigners to take our textures and turnthem into geometric shapes. The leveldesigners then used these shapes to fillin the architecture (Figure 1). We callthese shapes “brushes.”

Typically, the process of handing thelevel designers the textures that theyneeded for a map went like this. First,we artists created a series of “base” tex-tures — generic textures with a certain

look that could be reused throughoutdifferent areas of the game. We also cre-ated textures specific to certain areas asdictated by the design document, suchas the “mines” texture set or the “facto-ry” texture set. All textures wererequired to be sized in a power-of-two(for example, 8 pixels × 8 pixels, 16×16,32×32, 32×64, 128×128, 128×64, and soon) (Figure 2).

All of the in-game textures inQUAKE 2 were created using ElectronicArts’ venerable Deluxe Paint, and forsome animations we also usedKinetix’s Animator Pro. You maychuckle at our choice of Deluxe Paint,as the program has been around forages. But for static manipulation ofpixels using a 256-color palette, therereally is no substitute. Sure,Photoshop and other programs

designed to work in true color can beused to do 256-color tweaks, butDeluxe Paint is a worthy tool.

The reason QUAKE 2’s texturesturned out so well is due to our hand-drawn approach to creating them.Using what’s called “nearest pixel”methodology, we ensured the integrityof each texture by paying specialattention to the proper amount ofantialiasing. Sometimes, a stippled ordithered effect is appropriate, but sim-ply rendering a scene in a 3D packageand slapping it into a game withoutmodifying the image will often resultin “pixel swim.” While massaging animage pixel by pixel is painful andtime-consuming, it’s a necessaryprocess. However, as 3D acceleratorcards become more popular (and insome cases, mandatory), bitmap inter-polation will address the problemsassociated with pixel swim.

Skinning Characters

T o skin our characters (skins aretextures that are projected linear-

ly onto a character’s model), we hadto warp the models’ base frames inorder to get the maximum amount ofcoverage (a base frame being a refer-ence-only state of deformation for thegeneration of the texture map)(Figures 3a and 3b).

To help us artists skin characters,John Carmack wrote a tool (in a week-end, no less) called Texpaint, which

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

37

F I G U R E 1 . id’s in-house level editor.

F I G U R E 2 . One of QUAKE 2’s .LBM

texture files, created in Deluxe Paint.

F I G U R E 3 a . A character skin texture

map.

F I G U R E 3 b . And the skinned charac-

ter.

allowed us to paint directlyonto a mesh, much like thecommercially available toolPositron’s MeshPaint. Texpaintproved to be invaluable.Though fairly simple, the toolnevertheless featured unlimit-ed undo capability, showedmodel and texture lines, andlet us select any pixel resolu-tion for the texture sheet. Italso gave us the ability to gen-erate a triangle-unique multi-colored “start” skin for clarityand identification of possibleproblem areas (Figure 4a).

Using Texpaint to create askin was a simple affair. First,we’d load up the base frameand click the New Skin menuitem, which generated an.LBM (Deluxe Paint’s nativefile format) for the character on whichwe wanted to paint — the .LBM’s reso-lution was based on the mapping coor-dinates of the loaded object. Then,we’d bring in any other non-baseframe’s object file from the object’sdirectory, retaining the previously gen-erated base texture (Figure 4b).Texpaint would then help us take themodel from its deformed base framestate to a polished, finished object(Figure 4c).

As we’d draw on the .LBM object, thechanges to the skin appeared simulta-neously on both the texture page andthe skinned object itself. This methodworked especially well when we used

Texpaint and Deluxe Paint in conjunc-tion with Animator Pro. Our processconsisted of marking out certain areason the skin, using either Deluxe Paintor Animator Pro to refine these areas,and then reloading the skin intoTexpaint for further refinement. All ofthe artists on our team had at least twocomputers (a Windows NT system anda Windows 95 system), so using theWindows NT-based Texpaint and theDOS-based Deluxe Paint in tandemwasn’t really a problem because wecould rely on our network to transferthe files and our twin 21-inch monitorsfor instant feedback. Once textureswere completed, they were handed off

to the programmers, who con-verted them from .LBM to.PCX format for better con-sumption by the game engine.

Inanimate game objects,including the view-modelweapon that characters used,required only one skin sincethese objects didn’t changestates during the game. (View-model weapons are those thatyou see in your hands whileplaying the game, and world-model weapons are those thatyou run over to add to yourinventory.) The monsters andplayer characters, however,required an additional “pain”skin to convey that the crea-ture or player was hurt. Thisdifferent texture wasn’t sector-based in any way. We merely

switched out entire skins when a char-acter’s hit points reached a critical level.

View Screens, Option Screens

The look for the main-view andoption screens in QUAKE 2 were

designed to fit the basic militaristictheme of the game. We chose a cleanand uncluttered look for the status barfor simplicity’s sake. When we releasedQ2test (the public beta version ofQUAKE 2) on the Internet, we featured aface at the bottom left of the screen(likely familiar to QUAKE and DOOM

players) that reflected the damage state


38

Q U A K E A R T

F I G U R E 4 a . John Carmack’s character skinning utility,

Texpaint.

F I G U R E 4 b . Bringing a non-base frame’s object file into

Texpaint.

F I G U R E 4 c . The skinned character after refinement in

Texpaint.

of the character and even indicatedfrom which direction the player wasbeing hit. Unfortunately, since playerscan choose from about 30 differentdeathmatch characters, we decidedthat implementing an animated facefor each deathmatch character wouldbe too time-consuming — we decidedto use the universal red cross on awhite background instead (Figure 5).

Although no faces are displayed onthe status bar during game play, theplayer does get a snapshot of the cho-sen character in the multiplayer setupmenu (Figure 6). A rotating model ofthe chosen character also allows casu-al perusal of the model and skin.While we would have liked to use thesesame snapshots in the status bar duringgame play, it wasn’t possible due totheir resolution. The portraits of thecharacters in the multiplayer setupmenu are 32×32 pixels; the highest pos-sible resolution for any graphic in thestatus bar was 24×24. It all came downto the fact that the 32×32 versions weredone first, we didn’t have time to dosecondary versions of them, and wedidn’t feel that 24×24 was enough pix-els to do justice to the different faces.So we opted for the red cross.

QUAKE 2’S view and option screenswere created last and constructed withfunctionality and practicality in mind.We were constrained to these screensby code that was already in place fromthe previous game. In addition, whilewe would have loved to have had allkinds of tricky animated buttons in thefront-end menus, why make the playerrun through a maze of information justto change an option? Time and func-tionality concerns dictated QUAKE 2’sspartan interface.

Modeling

B asically, two types of modelsexist in QUAKE 2: Alias models

and B-models. Alias models were cre-ated using Alias|Wavefront’sPowerAnimator on an SGI (an Indigo2 Extreme with 256MB RAM). B-mod-els are “brush models” created bylevel designers from the previouslymentioned textures. Another waythat we gave the designers workingmaterial for their level creation was inthe form of an internally-developedtool called 3DS2MAP. This little utili-

ty took nonconvex shapes built inKinetix’s 3D Studio R4 and convertedthem into brush models that could beused in either QUAKE or QUAKE 2 levels.3DS2MAP helped overcome some ofthe deficiencies of the designers’ in-house development tool (the QUAKE

Editor), such as its inability to createperfect spheres, domes, or weird geo-morphic shapes such as boulders orrocks. Tim Willits, the lead designer onQUAKE 2, gave me the strangest lookwhen I made him a half-dozen rocksone time in about five minutes; he saidit would have taken him days to dothat in their editor.

Alias models were used for charactersand objects in the game as well as theview model and world-model weapons.We also used Alias models for miscella-neous map-specific objects, such as radardishes and the ships that fly by occasion-ally. We used 3D Studio R4 for the bulkof the character modeling because oncethe normals are reversed, 3D Studio filescan be exported as .DXF files (the

AutoCAD file format) and easilyimported into PowerAnimator.

If you’re wondering why we didn’tjust use PowerAnimator’s modelingcapabilities for every object, theanswer is me. Kevin Cloud actuallydid use PowerAnimator exclusively.However, I was responsible for mostof the models and I used the productthat I know best: 3D Studio R4.Simply put, I don’t care forPowerAnimator’s modeler. I know3DS4 like the back of my hand andtreat it as my 3D sketchbook. I cancomplete a model in about the sametime that it takes to work up the samedesign on paper.Objects’ face counts were dictated by

the “less is best” doctrine (that is, be aseconomical as possible with modelpolygon counts). The creation of allthe models was, however, an iterativeprocess, and optimizing them was anart form unto itself. For example,Figure 7 shows a high-resolution ver-sion of the gunner that I created for anAustralian magazine cover, along withthe version of the same character as itappeared in the game.CHARACTERS. Our goal was to keep basicenemy characters to 600 faces or less,although some reached as many as 700.Most were in the 400 to 500 range. Bosscharacters, due to their uniqueness andthe fact that they were often alone ontheir level, ranged from a hefty 1,500faces to a whopping 2,500 faces for thefinal boss Makron (astride his mount,Jorg). The player character was exactly600 faces, but because we did theweapon as an overlay, you could actual-ly say the male and female player char-acters were around 750 faces each.

VIEW-MODEL WEAPONS. When you playQUAKE 2, the weapon model that yousee in your hands is slightly to theright or left. This is because of theway that we optimized the view-model weapons (Figures 8A and 8B).The view-model weapons are themost optimized models in the gamedue to their visually restricted andvisually predictable nature. Whatyou’d see if the weapons were slidover to the middle would be hardlyrecognizable as a weapon, because theside view shows more of the texturemapping details. Keeping theweapons (and the hands holdingthem) under 400 faces was no easytask. Not only did the weapon and


40

Q U A K E A R T

F I G U R E 5 . id’s artists chose to represent

health as a simple red cross.

F I G U R E 6 . The multiplayer setup screen

gives players a rotating view of their cho-

sen character.

hands have to look realistic, but inmost cases, had to animate as well.

Creating the view model so that itappeared correctly in the world was sortof tricky. Because the game engine givesyou a ninety-degree field of view (FOV),objects that are close up are severelyskewed and seem stretched out. Toadapt to this FOV limitation, we createdthe weapon models and then viewedthem in a camera window approximat-

ing the same view of the game. Themodels also had to be squashed some-what to compensate for the stretchingeffects on nearby objects in the FOV.Only after quite a bit of tweaking didwe achieve the correct results. Once wewere satisfied that the weapon lookedgood from the proper angle, that ver-sion was saved and the arduous task ofoptimizing it down to more digestiblemeasurements began. In my opinion,

the weapon view models were probablythe most challenging and most satisfy-ing of the models done for QUAKE 2.GENERAL OBJECTS. General objects suchas ammo boxes, armor, weapons, oranything that you can you pick upwere also created with the “less isbest” philosophy (Figure 9). Theseobjects rarely surpassed 200 faces. Thesubtle pulsing glow around the objectsis for the gaming aspect of the artifactand is understandably necessary toensure its visibility.

The modeling in QUAKE 2 was donewith the same attention to detail as allother parts of the game. We wanted tomake visually interesting charactersand objects that fit within the plot anddesign of the game. We put as manycharacters and objects into the game asthe single CD and time would permit.The characters and objects that didn’tmake it into QUAKE 2 will most likelyrear their low-polygon, ugly heads inthe upcoming mission pack that we’reworking on.

Animation

A ll of the in-game, nonrenderedanimations in QUAKE 2 were done

in PowerAnimator. We feel Power-Animator is simply the best programfor character animation available. Thestrength of PowerAnimator for doingcharacter animation lies in the amountof control you have over each vertex. Atool that provides subtle degrees ofinfluence over individual verticesmakes a big difference in the realism ofa bicep or elbow joint that maintainsits integrity as it flexes. If your programdoesn’t allow you to control elementsat the vertex level (as opposed to a toolthat merely assigns influence to an areaof vertices), you’ll run into problemssooner or later.CHARACTERS. The following is QUAKE 2’sgeneral character animation process:• Create the character or import it from

3DS4 into PowerAnimator.• Build a skeleton inside the mesh to

support its animation.• Attach the mesh to the skeleton and

name the clusters accordingly.• Assign an appropriate amount of

influence over the vertices or groupsof vertices (clusters).

• Flip any edges that have to bechanged in order to better support


43

Q U A K E A R T

F I G U R E 7. The low-polygon version of the gunner (right-hand side) weighs in at

around 620 faces. The high-resolution version (left-hand side) is about 20,000

faces. When optimizing, Paul Steed used an external plug-in for 3D Studio R4

called Optimize, which gave him a head start on a super-dense mesh. Once he’d

reduced a model down to about 1,000 faces, he would finish the optimization by

hand. Nearly all tools of this kind simply smooth off and merge faces based on

their relational or incidental angles, and often some manual work is required by

the modeler to polish off the job.

the animation (especially around thehips or shoulders), thus avoiding anyunwanted “crimps” or other uglydeformations.

• Create any applicable inverse kine-matic (IK) chains (I only used IK forlegs or arms if the creature used themin locomotion).

• Make a copy of the character’s feetand save them as templates for futurereference. Setting up a skeleton and mesh so

that they would work well togetherusually took about a day and was thesingle most time-consuming and ardu-ous part of the character animationprocess. Associating over 300 verticesinto groups, naming them, and makingsure that they were linked to the rightjoint made me sometimes wish we hadan intern. If the process isn’t done per-fectly, you’ll regret it later. One of theproblems we faced — even with Power-Animator — was that even though youcan set a keyframe for an IK handle andmake the body sway or lead over time,the feet at the bottom of the IK chainwill turn and twist. That’s why I alwaysmade copies of the character’s feet andsaved them as templates. These guidesensured that there was no skatingeffect by characters as they walked.

The actual animation process is myfavorite part of my job. Early on in theproject, we debated whether to animateat 10 frames or 20 frames per second.John Carmack had linear interpolationworking within the engine from DayOne, so we knew that the fastermachines would make our animationsas smooth as silk regardless of the framerate. We ended up going with a 10 FPSbase for several reasons. First, it meantless data storage because we weren’tgoing to use an in-game skeletal anima-tion system. Instead, we used the QUAKE

method, which tracks the vertex posi-tion based on differencing the positionof the vertices frame by frame. The sec-ond reason was that even our slowesttarget machine could play back the ani-mations at 10 FPS without a problem.

Because we went with 10 FPS insteadof 20 FPS, we never even consideredusing motion capture to animate ourcharacters. There was no point — whatgood animator can’t animate at 10 FPS?Just as all the textures and skins arehand drawn, the animations were also

created by hand with-out secondary data.When we dive intodeveloping Trinity,however, we definite-ly will explore thebenefits of motioncapture.

The basic anima-tion set of the charac-ters generally consist-ed of an idleanimation, an idleanimation in whichthe character didsomething interestingat random intervals(such as scratching acertain anatomicalpart), a walk, a run,

several attacks, several expressions ofpain, several deaths, a duck or crouch,and a blocking animation (which did-n’t make the final cut). This is a verygeneralized list, though, and anima-tions sometimes varied drastically fromcharacter to character. Typical charac-ters had between 250 and 500 framesof animation total.

One regret we had with regard to ouranimations was not putting all of theanimations for a given character intoone file. When you have a run anima-


44

Q U A K E A R T

F I G U R E 8 A . The view-model mesh of

a machine gun.

F I G U R E 8 b . Several orthographic views of the same

view-model mesh.

F I G U R E 9 . Random objects in QUAKE 2 were created with the same care as the

main characters.

tion, a stand animation and three painanimations saved as different files,making changes to a character’s mainmesh necessitates changing a sequenceof files, rather than just one. For exam-ple, adding the flag for the capture-the-flag multiplayer mode would havebeen much easier with this method.Instead, the flag had to be grouped toeach of the subsequent character ani-mations, making the job take aboutone-and-a-half times longer that itshould have.

Once a character’s animation suitewas complete, the arduous process ofsaving the frames began. Each frame ofanimation had to be saved as a .TRI filein order for the mesh to be added tothe game. We would go through eachanimation file (in this case, for a char-acter’s pain animation) and saveframes as a sequence of files such asPAIN101.TRI, PAIN102.TRI, and so on.Each character had its own directory,so we used the same naming conven-tion for all characters. A spreadsheetcontaining all of the salient data abouta character’s animation set (file names,offsets, and general action description)

was also maintained by the art team.This proved extremely helpful downthe stretch when the animations wereconverted to .DLLs, and on those occa-sions when programming data mysteri-ously “disappeared.” VIEW-MODEL WEAPONS. Animating theview-model weapons was a lot trickierthan the animations for the characters.The models were so optimized that agreat deal of care had to be taken toanimate them. Early on, the weaponswere higher in view space to show offmore geometry. This approach blockedtoo much of the player’s view, so welowered the weapon, which revealedeven less of it and allowed us to opti-mize the models even more. For exam-ple, initially the chain gun had a baseand some trigger buttons on top thatcorresponded to the world chain gunmodel. These features disappeared afterwe lowered the weapon and pulled itcloser to the player’s view.

Making the weapon appear as if itwas being drawn and adding idle or fid-get states to the weapons models wasprimarily John Carmack’s idea. Hewanted a little more realism in the

weapon switching and weapon anima-tions (as opposed to the instantweapon switch trick used in QUAKE), sowe added finger taps and weapon re-adjustment animations .

We tried to add muzzle flashes butthey didn’t quite work out, so theydidn’t make the final cut. Although I’mpersonally dubious as to the effective-ness of any type of polygonal represen-tation of fire, smoke, or any other sortof incendiary effect, Kevin and Adrianpulled off these effects very convinc-ingly. Given more time, I’m sure wewould have found some way to make aconvincing flash effect or shell ejectinganimation for the weapons. I guesswe’ll have to wait for Trinity.

As in all things id-like, an attempt wasmade to infuse attitude into all the ani-mations to give an identity to the char-acters and weapons. Small details suchas painful deaths, humorous taunts, andtapping fingers are examples of gameelements that we wracked our brainsover. I believe that our meticulousapproach made the animations morememorable and resulted in a moreenjoyable game playing experience. ■


45

art of quake 2

Documents