Postmortems From Game Developers

POSTMORTEMSFROMAustin Grossman,editorSan Francisco, CA • New York, NY • Lawrence, KS

Published by CMP Booksan imprint of CMP Media LLCMain office: 600 Harrison Street, San Francisco, CA 94107 USATel: 415-947-6615; fax: 415-947-6015Editorial office: 1601 West 23rd Street, Suite 200, Lawrence, KS 66046 USAwww.cmpbooks.comemail: books@cmp.comDesignations used by companies to distinguish their products are often claimed as trademarks. In allinstances where CMP is aware of a trademark claim, the product name appears in initial capital letters,in all capital letters, or in accordance with the vendor’s capitalization preference. Readers should contactthe appropriate companies for more complete information on trademarks and trademark registrations.All trademarks and registered trademarks in this book are the property of their respective holders.Copyright © 2003 by CMP Media LLC, except where noted otherwise. Published by CMP Books, CMPMedia LLC. All rights reserved. Printed in the United States of America. No part of this publication maybe reproduced or distributed in any form or by any means, or stored in a database or retrieval system,without the prior written permission of the publisher; with the exception that the program listings maybe entered, stored, and executed in a computer system, but they may not be reproduced for publication.The publisher does not offer any warranties and does not guarantee the accuracy, adequacy, or completenessof any information herein and is not responsible for any errors or omissions. The publisher assumesno liability for damages resulting from the use of the information in this book or for any infringement ofthe intellectual property rights of third parties that would result from the use of this information.Acquisitions editor:Managing editor:Copyeditor:Layout design:Cover design:Dorothy CoxMichelle O’NealMadeleine Reardon DimondJustin FulmerDamien CastanedaDistributed to the book trade in the U.S. by:Distributed in Canada by:Publishers Group WestJaguar Book Group1700 Fourth Street 100 Armstrong AvenueBerkeley, CA 94710Georgetown, Ontario M6K 3E7 Canada1-800-788-3123 905-877-4483For individual orders and for information on special discounts for quantity orders, please contact:CMP Books Distribution Center, 6600 Silacci Way, Gilroy, CA 95020Tel: 1-800-500-6875 or 408-848-3854; fax: 408-848-5784email: cmp@rushorder.com; Web: www.cmpbooks.comPrinted in the United States of America03 04 05 06 07 5 4 3 2 1ISBN: 1-57820-214-0

TABLE OF CONTENTSiiiIntroduction: Tales from the Front Line . . . . . . . . . . . . . . . .ixSECTION I STARTUPS . . . . . . . . . . . . . . . 1Irrational Games’ SYSTEM SHOCK 2 . . . . . . . . . . . . . . . . . . . 5by jonathan cheyIt’s the Engine, Stupid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Bohemia Interactive Studios’ OPERATION FLASHPOINT . . . . . . . 19by marek spanel and ondrej spanelWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Future Dreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Surreal Software’s DRAKAN: ORDER OF THE FLAME . . . . . . . . . 29by stuart denmanOrigins of the Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Origins of the Beast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Onward to the Next Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Pseudo Interactive’s CEL DAMAGE . . . . . . . . . . . . . . . . . . . 41by kevin barrett, john harley, rich hilmer, daniel posner, gary snyder, and david wuWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Damage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

ivTable of ContentsNihilistic Software’s VAMPIRE: THE MASQUERADE—REDEMPTION .51by robert huebnerWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58At Last, Redemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Ensemble’s AGE OF EMPIRES . . . . . . . . . . . . . . . . . . . . . . . 63by matt pritchardDesigning the Past Perfect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Blazing the Multiplayer Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65Painting the Scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Going for Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Things That Worked Out (S)well . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68Things That Went Wrong Or We Could Have Done Better . . . . . . . . . . . . . . . . . .70Patching It All Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73SECTION IISEQUELS AND SOPHOMOREOUTINGS . . . . . . . . . . . . . . . . . . . . . 75Blizzard Entertainment’s DIABLO II . . . . . . . . . . . . . . . . . . . 79by erich schaeferWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86The Final Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90Epic Games’ UNREAL TOURNAMENT . . . . . . . . . . . . . . . . . . . 91by brandon reinhartEarly Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91A Game Takes Shape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92New Code, New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94In the End, It All Worked Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100Where We Go from Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102

Table of ContentsvWestwood Studios’ TIBERIAN SUN . . . . . . . . . . . . . . . . . . .103by rade stojsavljevicWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Overall Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Ensemble Studios’ AGE OF EMPIRES II: THE AGE OF KINGS . . .115by matt pritchardCatching Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Designing a Sequel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121The Show Goes On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Presto Studios’ MYST III: EXILE . . . . . . . . . . . . . . . . . . . . .127by greg uhlerWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Closing Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Poptop Software’s TROPICO . . . . . . . . . . . . . . . . . . . . . . . .137by brent smithWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141In Hindsight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146SECTION III MANAGING INNOVATION . . . . 147Lionhead Studios’ BLACK & WHITE . . . . . . . . . . . . . . . . . . .151by peter molyneuxWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156“Just More” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

viTable of ContentsBungie Software’s MYTH: THE FALLEN LORDS . . . . . . . . . . . . 161by jason regierThe Making of a Legend, er, Myth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165Post-Release Reactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168Looking Glass’s THIEF: THE DARK PROJECT . . . . . . . . . . . . . 171by tom leonardThe Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178Stepping Back from the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181DreamWorks Interactive’s TRESPASSER . . . . . . . . . . . . . . . . 183by richard wyckoffAn Ambitious Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183The Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193Ion Storm’s DEUS EX . . . . . . . . . . . . . . . . . . . . . . . . . . . 195by warren spectorWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202The Bottom Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207Naughty Dog’s JAK & DAXTER: THE PRECURSOR LEGACY . . . . . 209by stephen whiteWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214The Legacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217

Table of ContentsSECTION IV BUILDING ON A LICENSE . . . . 219viiLucasArts’ STAR WARS STARFIGHTER . . . . . . . . . . . . . . . .223by chris corryWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Back to Earth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Raven Software’s STAR TREK: VOYAGER—ELITE FORCE . . . . .237by brian pelletier, michael gummelt, and james monroeWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Red Storm Entertainment’s RAINBOW SIX . . . . . . . . . . . . . .251by brian uptonThe Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251The Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257In the End… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Raven Software’s SOLDIER OF FORTUNE . . . . . . . . . . . . . . . .259by eric biessman & rick johnsonWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265A Direct Hit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270SECTION V THE ONLINE FRONTIER . . . . . 273Mythic Entertainment’s DARK AGE OF CAMELOT . . . . . . . . . . .277by matt firorWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283For the Ages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

viiiTable of ContentsMultitude’s FIRETEAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 287by art minBrief History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288FIRETEAM’s Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289Who Worked on FIRETEAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289What Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293Evolving Right Along . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297Turbine’s ASHERON’S CALL . . . . . . . . . . . . . . . . . . . . . . . . 299by toby ragainiWhat Went Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301What Went Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306A Unique Company Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309Afterword Independent Game Development . . . . . . . . . . .310Appendix A Game Development Team Roles . . . . . . . . . .313Artist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314Producer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315Programmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317Index of Game Titles & Developers . . . . . . . . . . . . . . . . .319Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323

ixINTRODUCTIONTales from the Front LineWe are only beginning to understand how tomake video games.A couple of years ago I was working at a computergame company in Los Angeles, and oneafternoon I took a walk through Universal Studios’nearby lot. I was new to the West Coast, soit was a big thrill knowing that I was standing atthe physical place where movies were made. Iroamed around and peered in open doorways atthe cavernous sound stages stacked with pipesand lumber.I had no idea what any of it was, but two thingswere immediately clear: (a) whatever they weredoing was enormously complicated and expensive,and (b) they knew exactly how to do it.Universal Studios was founded in 1912, andafter 90 years of filmmaking, they have it downto something like a science. Every single item,down to the orange cones, had a name or numberstenciled onto it. Somewhere someone witha clipboard knew what everyone on the projectwas doing that day and every day until the redcarpetpremiere, and how much every minutewas costing the studio. If the movie runs overtime and budget, they know it and they knowwhat to do to minimize losses and get it in thecan and out the door. They have put their productiontechniques through more-than-completeshakedown.Compare this to making a video game. This isanother enormously complicated and expensiveenterprise, but one much less clearly understood.Schedules, staffing, and budget are routinelyinaccurate, if not vastly overoptimistic.Projects routinely run months and millions ofdollars over what was initially projected. Jobdescriptions are vague and changeable. No universalvocabulary of design and production terminologiesexists. Individual jargons are ad-hocinventions, varying from company to companyand project to project.Every year new technologies for both productionand display are introduced, and every yearaudience expectations change and the scale ofthe enterprise goes up. During the two years aproject is in production, the whole mediumevolves. The product quality in the game industryis immensely variable. Only a relativelysmall percentage of video and computer games

xSection I: STARTUPSxare substantially profitable and many losemoney. What’s going on?The game industry is in its shakedown phase.We have a loose set of procedures, methodologies,heuristics, and advice about how to makegames, but judging by the rate at which projectsgo seriously off-track, it’s not enough.One reason for this is that the medium itself isstill changing rapidly—in form, in content, andin scale. Computer games began as one-personprojects, a single person doing code, design, art,and possibly marketing and distribution. Thewhole thing could be around 100 kilobytes,something like 50 typewritten pages of data. Inthe year 2000, an average game published by amajor game publisher cost $5–10 million todevelop, required 1–3 years in development timeand a team of 10–50 developers and artists producing500 megabytes of data, comparable to a10-volume encyclopedia set.Organizing the creation of this much data isdaunting, to say nothing of shaping it into afunctional software application that producesthe delicate, ephemeral quantity known as“fun.” To compound this, we have the industry’scollective lack of experience. The entireindustry is only 25–30 years old, and for thefirst 20 years of that it was relatively tiny.According to a survey by the IDSA, the averagegame programmer has 1–2 years experience;other game development staff, including technicaldirectors, lead artists, and designers have onaverage 3–5 years’ experience. So only half ofthe people in the industry have been there longenough to have shipped more than 2.5 games.Our collective inability to complete projectssmoothly is damaging on a number of fronts.Budget overruns and delayed product releasesare obviously costly and make it much harderfor companies to stay in business. This has indirecteffects as well, as small companies withoutfinancial resources can go under even if theyhave strong, original game ideas. It suppressescreativity—with smaller profit margins and tightschedules, there is increased pressure to stick toproven formulae and reliable money-makers,rather than to experiment.Too many games are released before they areactually complete, because they have to beshipped in order to balance the quarterly budget.The pressure to sign off on a game is enormous.This is clear from the number of gamesthat require patches, meaning that they weren’tready to ship at all. Game companies operate soclose to the margin that almost no one has theluxury of shipping a game “when it’s ready.”When projects go bad, the first casualty is qualityof life. Many products are shipped only at agrueling cost of lost sleep, strained relationships,weekends away from family and friends. Thereis such a thing as hard-core dedication, whereyou work long hours for the tremendous thrillof getting paid for what you love, of staying upuntil 3 A.M. to get a key feature up and running,and watching the game come alive beforeyour eyes. But too many of us have experiencedthe agony of being stuck in a morass of aproject, missing milestone after milestone withno end in sight, flinching and growling wheninnocent bystanders ask us how “that gamething is going.” This has become an accepted

INTRODUCTIONxipart of the industry, rather than a symptom ofproject mismanagement.As an industry, we are gradually becomingaware of this. Grim experience tells us that nomatter how good your idea or how brilliant anddedicated your team, project mismanagementcan wreck things. Project management is a complexsubject worth studying—a collection ofskills and knowledge as difficult and importantto game production as art, programming, anddesign. While it is generally becoming acceptedthat the simple “waterfall” model of softwaredevelopment isn’t enough, flexible developmentmodels are harder to implement than they look,and require daily courage, patience, and goodjudgment.What this book hopes to do is speed up thegame industry’s shakedown process. The postmortemsin this book are the next best thing toactual game development experience. They followprojects from start to finish, talking aboutmistakes as well as good decisions, giving candidaccounts, rather than just trying to abstractgeneral guidelines. They record the experiencesof average game developers as well as highrankingproducers.Each article is written in the same simple format.A member of the development team writesdown how the game got made, starting from theinitial vision and the starting goals, what kind ofcompany and project team was involved, whattools were used, and any major events along theway. The author then lists five successes, fivethings that Went Right and conspicuously contributedto the project’s success. This is followedby What Went Wrong, a list of five misjudgments,failures, or missed opportunities.The postmortems in this book are grouped intofive sections:• Startups,• Sequels and Sophomore Outings,• Managing Innovation,• Building on a License, and• The Online Frontier.These categories are designed to group games byfactors relevant to production, rather than (forinstance) gameplay or technology issues. Theydon’t function with true Aristotelian purity,however, so some of the postmortems concerngames that belong to more than one category—someof the online games were also madeby startup companies, and so on.The Game Developer postmortems have graduallybecome an industry institution, and deservedlyso. The honesty, thoroughness, andspecificity of these accounts make them a uniqueresource. One of the great strengths of the gameindustry is its ethic of cooperation and communication,and the belief that our identity as acommunity of passionate creators is moreimportant than edging each other out for moremoney. This has created an atmosphere wherewe can share information about our successesand failures and help each other make bettergames.This is part of the reason that games as amedium has come so far, so fast. This book will,I hope, be a part of that process, the candidexchange of experiences as we all struggle upthe learning curve together.

1SECTION IStartupsThe startup company is truly the heroic myth ofthe game industry. It’s the young success story ofa new generation, like a garage band getting abig record contract, or a goateed 22-year-oldwriting the latest Great American Novel. Weknow it by heart already: a collection of dedicatedtwentysomethings (the genius hacker, thevisionary designer, the gifted artist), college buddiesor the remnants of someone’s high schoolD&D campaign; the brilliant concept, the nextDOOM or TETRIS, neon lightning caught in abottle; the cluster of PCs set up in low-rentoffice space or someone’s living room; the latenights, the pizza boxes, the copy of BusinessPlans for Dummies. And of course the happyending: killer demo for an industry publisher, adistribution deal, internet buzz, and the privatedream is now a number-one seller. Fame andfortune, not to mention royalties and stockoptions, ensue. And above all, a true passion forthe work, the holy fire.And it happens, too. Look at the game industry’spremier development houses, and you’ll seegarage companies started by hobbyists and amateurswho worked out a way to package and sellwhat they love. Even as the industry matures,there is still a niche for startups, as larger companiessometimes fail to keep pace with streetlevelinnovation.The realities of the startup company are oftenhard work, long odds, endless delays and hassleand frustration. The postmortems collected hereare the rare success stories—we don’t chroniclethe hundreds (thousands?) of startup efforts thatbroke apart when money ran out, enthusiasmflagged, schedules slipped, or law school beckoned.Startup companies tank far more oftenthan they succeed, and in the end the dealdoesn’t get made, the product never ships, andpeople go their separate ways. What makes thedifference?The postmortems in this section were all writtenby developers who succeeded. They all shippedgreat games their first time out, and were willingto share what went right and what went wrong.If you’re working on a startup game company,none of their situations will be exactly the sameas yours, but chances are much of it will have afamiliar ring.

Section I: STARTUPS 2Startups typically have a few enormous advantages,which we’ll see repeated in the pages tocome:Youth. Young, enthusiastic teams, willing towork long hours for low salaries.No bureaucracy. When the whole companyfits into one office and your CEO is alsoyour lead programmer, communicationhappens faster.Low overhead. Lean and mean companieshave a low burn rate, especially when you’reworking out of someone’s parents’ livingroom.Freedom. Until you’ve made a distributiondeal, you call the shots—you can make thegame you want to make, not the one you gothanded because upper managementmanaged to score the interactive licensingrights to a 70s TV show.New company culture. It’s a chance to formyour own company culture and try out newmodels of game development, instead ofinheriting them from an older company’sbureaucracy. You design the work pipeline,organizational chart, greenlight processyourself, and change them right away if theydon’t work out.There are also some perilous downsides:Rookie management. Software development isan enormously complex task, almost adiscipline in itself. Screwing it up can havegrievous costs in time, money, and quality.No money. Unless you have a sweetheart dealfrom the start, you’ll be running on ashoestring budget, conceivably angstingabout making payroll.Overtasking. Everyone seems to be inagreement that small teams work better formany projects, but this can mean teammembers wear multiple hats. The problem iscompounded when the same people arerunning the business and administration of asmall company.Overambition. Sometimes total freedom canbe too much of a good thing. Big-companystructures that force you to make milestonesand ship product can be necessary discipline,ensuring that you cut unnecessary featuresand that someday you actually put theproduct in a box and ship it.New company culture. A project being run atan existing firm already has guidelines andan outline of how to build a game. Thesecan be a hindrance, but they can also be theroad map that gets you through unknownterritory.Here are a few of the lessons that can be drawnfrom them:• There’s more than one way to form astartup.Bohemia Interactive and Surreal Softwareboth took the traditional garage-band route,but there are other models. Some developmenthouses start small, just doing ports ofexisting games, or add-on packs—you don’tnecessarily have to reinvent the wheel. Maybesomeone has a gee-whiz piece of technologythat needs a game built around it. Maybe aproject team detaches from an existing company,then contracts with the parent

3Section I: STARTUPSfirm—this is a model that gives you some ofthe freedom of a startup, but with an experiencedteam and a useful relationship to alarger company.• Publishers aren’t necessarily the enemy.It’s easy to adopt a siege mentality when you’rea small developer: your publisher is The Man,and he’s going to stifle your creativity, makeyou jump through bureaucratic hoops, andthen take the lion’s share of the profits. Occasionallythere’s a grain of truth to this picture…but it’s also possible for the publisher tobe a partner. A truthful, realistic relationshipmay serve both parties better than the usualadversarial one—the publisher is putting upthe money, and if they understand what theproduct is and when it’s actually shipping, theycan market it more effectively and everyonecan benefit. If they’re an established game publisher,they may actually be able to help managethe project or put you in touch withreliable contractors to help finish the game ontime.• Perseverance counts.None of these projects shipped without difficulties,and part of the reason they did ship isthat the developers didn’t give up, even whenthey lost their publisher, or key technologiesdidn’t work out, or they ran years longer thanthey had expected, or they had to slash keyfeatures to keep their budget and schedulerealistic. It was hard, but there isn’t muchglory in the making the Greatest Game ThatNever Shipped.• Hire the right people.Startups are almost always small operations,which means every employee has to be someoneyou can work with and rely upon, and agood team dynamic is absolutely essential.Also, in a small company you probably won’thave every single one of the skill-sets neededto make a game, so very likely you’ll have tocontract out certain elements of the game,like animation or some modular part of theengine. This means finding reliable contractorsand managing them carefully, givingthem a clear idea of how their work fits intothe game you’re making.The grand tradition of the garage startup companyis changing. Over the last decade there hasbeen a trend toward consolidation, larger companiesbuying up smaller development houses,companies with deep pockets that could survivelean fiscal quarters while smaller companieswent bankrupt. It’s a high-risk industry, anddiversified product lines mean you don’t have tocraft a hit every time out, especially if you havea few regular sellers to keep you in the black.The scale of game production is also changing—consumersare expecting higher and higherproduction values, up-to-date technology, andHollywood-quality art and animation. Theseare things that require multimillion-dollar budgetsand bigger teams. It may become harderand harder to write a hit game with five peopleand a brilliant idea.There may be a valid analogy with the film ormusic industry, with the way independent filmand grassroots music movements feed their

Section I: STARTUPS 4influences in to the more commercial scene. Asid Software’s Jay Wilbur once told Wired magazine,“People ask me who I fear, which of ourcompetition—LucasArts, Microsoft, any of thebig companies. They don’t frighten me. WhatI’m afraid of is two guys in a garage, working intotal obscurity. That’s where the heart and soulof this business is at. Those are the guys who aregoing to come up with the stuff that blows usout of the water.”

5Irrational Games’SYSTEM SHOCK 2by jonathan cheyThis is the story of a young and inexperiencedcompany that was given the chance to developthe sequel to one of the top ten games of alltime. The sequel was allotted roughly one yearof development with its full team. To make upfor the short development cycle and correspondinglysmall budget, the project was supposed toreuse technology. Not technology in the sense ofa stand-alone engine from another game, butindividual components that were spun off fromyet another game, THIEF: THE DARK PROJECT.The THIEF technology was still under developmentand months away from completion whenour team started working with it. To cap everythingoff, the project was a collaborative effortbetween two companies based on a contractthat only loosely defined the responsibilities ofeach organization.Add to these gloomy initial conditions the factthat the game from which our sharedtechnology was derived slipped more than sixmonths from the initially estimated date, thatseveral developers quit during the project, thatwe didn’t bring the full team up to strength untilsix months from the final ship date, and that westruggled with financial and business problemsduring the entire project. Having learned this,you might anticipate the worst. Strangely,Back-StorySYSTEM SHOCK 2 came out in 1999, as the sequel to SYS-TEM SHOCK, the critically acclaimed action/role-playinggame released in 1994 by Looking Glass Studios. Likeits predecessor, SYSTEM SHOCK 2 is an action gameshown in first-person perspective but with a richer narrativeand game-system than most shooters—playerscould hack into computers and access psychic abilities.It also tells a complex story—the player explores a derelictspacecraft after something has gone wrong withhumankind's first interstellar colony mission. These elementsblend in a marriage of design and technology—therich level design and complex charactercreationnever get in the way of the storytelling and suspensefulaction gameplay. SYSTEM SHOCK 2 is part of awave of deeper, more story-oriented action games thatbegan appearing in the late 90s (starting with UNREALand HALF-LIFE), a change from the stripped-down, allactionapproach of DOOM and QUAKE.SYSTEM SHOCK 2 shipped within two months ofits targeted date and will, I hope, be recognizedas a sequel worthy of its esteemed ancestor.Let’s step back and trace the origins of the companiesand the project. Looking Glass Studios isfamiliar to many as the creator of a series ofhighly innovative titles including the originalSYSTEM SHOCK, the ULTIMA UNDERWORLDseries, the FLIGHT UNLIMITED line and TERRA

Irrational Games’ SYSTEM SHOCK 2 6NOVA, among others. Three years ago, KenLevine, Rob Fermier and I were developers atLooking Glass, struggling with the aftermath ofVOYAGER, an aborted Star Trek: Voyager–licensed project. At the time, Looking Glass wasin financial and creative disarray after a series oftitles that, though critically acclaimed, hadGame DataRelease date: August 1999Publisher: Electronic ArtsGenre: 1 st -person science fiction action-adventureIntended platform: Windows 95/98Project budget: $1.7 millionProject length: 18 monthsTeam size: 15 full-time developers, 10–15 part-timedevelopersCritical development hardware: Pentium IImachines, 200MHz to 450MHz with 64MB to 128MBRAM, Nvidia Riva 128, Voodoo, Voodoo 2, TNT cards,Creative Labs’ sound cards, Wacom tablets, Windows95/98. Also used SGI Indigo workstations.Critical development software: Microsoft Visual C++5.0, Opus Make, 3D Studio Max, Adobe Photoshop,Alias|Wavefront Power Animator, DeBabelizer Pro,RCS, Filemaker Pro, and Adaptive Optics motioncapture software.failed to meet sales expectations, the latest beingTERRA NOVA and BRITISH OPEN CHAMPIONSHIPGOLF.Frustration with the 18 months wasted on VOY-AGER and a certain amount of hubris promptedthree of us to strike out on our own to test ourgame design and management ideas. We wantedto nail down a rigorous and technologically feasibledesign, focus on gameplay, and force ourselvesto make decisions rather than allowourselves to stagnate in indecision. We wantedto run a project. So we formed IrrationalGames.After some misadventures with other developmentcontracts, we unexpectedly found ourselvesback at work with Looking Glass as acompany rather than as employees. Initially, ourbrief was to prepare a prototype based on thestill-in-development THIEF technology recast asa science-fiction game. The scope of the projectwas very wide, but we quickly decided to followin the footsteps of the original SYSTEM SHOCK.Our initial design problem was how to constructsuch a game without the luxury of theactual SYSTEM SHOCK license, since no publisherhad yet been signed.Our initial prototype was developed by thethree of us working with a series of contract artists.Our focus was on the core game-play elements:an object-rich world containing lots ofinteractive items, a story conveyed throughrecorded logs (not interaction with livingNPCs), and gameplay realized through simple,reusable elements. This focus enticed ElectronicArts into signing on as our publisher early in1998—a fantastic break for us. It meant wecould now utilize the real SYSTEM SHOCK nameand characters.Immediately, we went back to our originaldesign, threw away some of the crazier ideasthat had been percolating and began integratingmore of the rich SYSTEM SHOCK universe into

7Section I: STARTUPS7the title. That was the point at which the realdevelopment began.It’s the Engine, StupidNothing impacted the development of SYSTEMSHOCK as much as the existing technology wegot from Looking Glass. This fact cannot beclassified monolithically under the heading of“what went wrong” or “what went right,”however, because it went both wrong and right.The technology we used was the so-called“Dark Engine,” which was essentially technologydeveloped as a result of Looking Glass’sTHIEF: THE DARK PROJECT (for more about itsdevelopment, see “Looking Glass’s THIEF: THEDARK PROJECT,” Postmortem on page 171).The THIEF technology was developed with aneye toward reuse, and I will refer to it in thisarticle as an “engine.” However, it is not anengine in the same sense as QUAKE’s, UNREAL’s,and LithTech. The Dark Engine was never deliveredto the SYSTEM SHOCK team as a finishedpiece of code, nor were we ever presented with afinal set of APIs that the engine was to implement.Instead, we worked with the same codebase as the THIEF team for most of the project(excluding a brief window of time when wemade a copy of the source code while the THIEFteam prepared to ship the game). Remarkably, itis still possible to compile a hybrid executableout of this tree that can play both THIEF andSYSTEM SHOCK 2 based on a variable in a configurationfile.This intimate sharing of code both helped andhurt us. We had direct access to the ongoingbug-fixes and engine enhancements flowingfrom the THIEF team. It exposed us to bugs thatthe THIEF team introduced, but it also gave usthe ability to fix bugs and add new features tothe engine. Because we had this power, we weresometimes expected to fix engine problems ourselvesrather than turning them over to LookingGlass programmers, which wasn’t always to ourbenefit. At times we longed for a finished andfrozen engine with an unalterable API that wasrigidly defined and implemented—the perfectblack box. But being able to tamper with theengine allowed us to change it to support SYS-TEM SHOCK–specific features in ways that a generalengine never could.What Went Right1. The irrational developmentmodelIn our hubris after leaving Looking Glass, weformulated several informal approaches todevelopment that we intended to test out on ourprojects. Most of these approaches proved to besuccessful and, I think, formed the basis of ourability to complete the project to our satisfaction.First, we designed to our technology rather thanbuilding technology to fit our design. Under thismodel, we first analyzed our technological capabilitiesand then decided on a design that wouldwork with it. This process is almost mandatorywhen reusing an engine. Sometimes it can be difficultto stick with this when a great design idea

Irrational Games’ SYSTEM SHOCK 2 8doesn’t fit the technology, but we applied theprincipal pretty ruthlessly. And many of thetimes when we did deviate, we had problems.Another feature of our development philosophyis that everyone participates in game design.Why? Because all three of the Irrationalfounders wanted to set the design direction ofour products, programmers were able to resolvedesign issues without having to stick to a designspec, and we strongly emphasized game designskills when hiring all of our employees and contractors.In all our interviews, one of our mostpressing questions to ourselves was “Does thisperson get games?” Failure to “get” them was adefinite strike against any prospective employee.Ultimately, the team’s passion for and understandingof games was a major contributor tothe design of the final product.The final goal of our development process wasto make decisions and hit deadlines. We focusedon moving forward, and we didn’t allow ourselvesto be bogged down. We desperatelywanted to ship a game and believed that the disciplineimposed by the rule of forward motionwould ultimately pay off in terms of the finalproduct quality as well as delivery date. Whilethere are features in SYSTEM SHOCK 2 that couldhave been better if we had not rushed them (thecharacter portraits for example), we still firmlybelieve that the game as a whole was made betterby our resolve to finish it on time.2. Use of simple, reusablegame-play elementsThe field of companies developing first-personshooters like id and Valve, among others, isimpressive. It would be a futile attempt to createscarier monsters, bigger guns, or higher-polygonenvironments. Additionally, we realized that ourdesign time and budget were very tight and thatwe would not have time to carefully hand-scriptcomplicated game-play sequences in the engine.Xerxes, central computer of the Von Braun.Cold comfort in Hydroponics.

9Section I: STARTUPS9Instead, in an attempt to shift the battlefield, wechose to focus on simple, reusable game-playelements. The success of HALF-LIFE, whichlaunched while we were in the middle of SYS-TEM SHOCK 2 confirmed our intuitions in thisrespect. We simply didn’t have the time,resources or technology to develop the scriptedcinematic sequences used by HALF-LIFE. We consoledourselves with the knowledge that wewere not even trying to do so. This strategymelded very well with our acquisition of theSYSTEM SHOCK license, as the original SYSTEMSHOCK had already been down this road. Wedecided to expand on elements that we liked inSYSTEM SHOCK and then add similar new systems.Each such new system was evaluated rigorouslyin terms of game-play benefits,underlying technology, and design-time requirements.Concept Sketch and game version of the Psi Reaver.For example, take the ship’s security system.Early on we decided that we wanted to continuethe surveillance theme from SYSTEM SHOCK,which we could leverage throughout the gameto provide lots of gameplay for very little implementationcost. We realized that security cameraswould be trivial to implement usingexisting AI systems (they are just AIs pruned ofmany of their normal abilities) and that once wehad cameras that could spot and track theplayer, we would be able to build several gameplayelements out of them. Cameras could summonmonsters to the player, so much of thegameplay consisted of avoiding detection bysecurity cameras and destroying cameras beforeyou were seen. Because cameras scan fixed arcs,the player can utilize timing to sneak by cameras,pop out and shoot them at the rightmoment, or get underneath them and bash themwith a melee weapon. Once a player is spotted,monsters flood the area until the player is ableto shut off the security system somehow or thesystem times out. This introduces the need todeactivate security systems via security computersthat are scattered throughout the level.This type of system was technologically simpleto implement and required minimal designeffort. While not completely formulaic, the basicprocedure to set up a camera and security systemcould be shown to designers quickly using afew simple rules. From this one system and acouple of associated subsystems, we derived alarge amount of gameplay without havingdesigners create and implement complicatedscripted sequences and story elements. Whenyou throw together many such systems (as wedid), you end up with a lot of gameplay.

Irrational Games’ SYSTEM SHOCK 2 103. Cooperative developmentSYSTEM SHOCK 2 was truly a cooperative developmentbetween Irrational and Looking Glass.Looking Glass provided the engine and a lot ofinfrastructure support (such as quality assurance),while Irrational handled the design,project leadership, and the responsibility formarshaling resources into the final product.Both entities contributed personnel to the developmentteam. Inevitably, some friction arosefrom this process while we sorted out who wasresponsible for what. However, this cooperationwas ultimately successful because both sideswere interested in developing a great product,and we were able to compromise on most issues.(On the most mundane level, Irrational endedup providing late-night, weekend meals for itsdevelopment team and for Looking Glass onsome days during the week.) Our cooperativearrangement was founded on a contractualagreement, but we avoided falling back on thiscontract in most cases. We preferred to resolveissues through informal discussions. Conceptually,Irrational was to be responsible for thedevelopment of the product and Looking Glasswas to provide A/V content and quality assuranceservices.During the early stages of the project, a deal wasworked out whereby a small number of LookingGlass personnel were subcontracted to Irrationalwhen it was determined that Irrational’sdevelopment budget could not cover all the SYS-TEM SHOCK 2 development costs, and as compensationfor the late delivery of the THIEFtechnology. Unfortunately, these personnel werenot always available on time—a situation whichcaused us much concern. We knew that this“resource debt” could never really be paid offuntil THIEF shipped—nothing is so difficult asprying resources away from a team that is tryingto ship a product before Christmas. It wasn’tuntil December 1998 that we first began to seesome of these promised resources. However,these “resources”—real people—had just finishedup THIEF and were totally fried followingthe grueling crunch to ship THIEF. The savinggrace and reason that this arrangement was ultimatelysuccessful was that these developers wereall talented and experienced and already knewthe technology. Their addition to the team gaveus a solid boost during the final months in ourship cycle.The other benefit of the cooperative developmentagreement between Irrational and LookingGlass was that our respective engine programmerscould share knowledge. The ability towalk over and quiz engine programmers aboutsystems proved to be an invaluable benefit thatmore than compensated for the lack of a rigorouslyspecified and documented engine. Withouta formal understanding of the engine, we had toresolve engine issues in a personal and informalmanner. This process relied on the personalitiesof the responsible individuals on the engineteam. Thus, the Irrational programmers balancedtheir time not only according to the complexityof their tasks but also according to howmuch support was available from the engineside. Overall, Irrational’s relationship withLooking Glass was an unusually close one andultimately successful as a result of our mutualrespect and willingness to work with each other.Despite our partnership being based on a formalcontractual arrangement, it was our ability to

11Section I: STARTUPS11work flexibly above thislegal level that enabled thedevelopment to proceedsmoothly.4. Design lessonsfrom SYSTEM SHOCKThough the SYSTEM SHOCKlicense was wonderful,there were some problems.The biggest was simply thechallenge of living up to theoriginal. Fortunately, wehad the freedom to payhomage to SYSTEM SHOCKlegitimately by reusing elementsfrom it. Additionally,we had access to some ofthe original developers,including our own lead programmerRob Fermier.Conceptsketches of the Cyborg Midwife.As with most sequels, we faced the challenge ofkeeping the good elements of the original gamewhile not blindly copying them. We knew thatmost players would want a new story set in thesame world, with the same basic flavor as theoriginal game, yet we also wanted to reach outto a broader audience. We resolved these issuesby identifying the key elements that made SYS-TEM SHOCK so good and reinterpreting thoseelements using current technology. Some elementsmade it through largely unchanged (forexample, the storytelling logs and e-mails, theübervillain Shodan and her close involvementwith the player throughout the game, and thecomplexity of the world). Other elements werereinterpreted (such as thelook of the environment,player interface, and techniquesfor interacting withthe world). A small numberof items were simply cut,most notably the cyberspacesequences—we werefairly united in our opinionthat these just didn’t workwell in the original.Notably, as with the originalSYSTEM SHOCK, weopted to omit interactiveNPCs in the game. SYSTEMSHOCK eschewed livingNPCs because the technologyof the day was simplyinadequate to supportbelievable and enjoyableinteractions with them. It’s been four years, andthat technology is still not available. So we continuedthe tradition of SYSTEM SHOCK and providedplayers with background informationusing personal logs and e-mails gleaned fromthe bodies of dead NPCs.Perhaps our biggest deviation from the originalrevolved around the player interface. It’s commonlyaccepted that SYSTEM SHOCK’s interface,while elegant and powerful once understood,presented a significant barrier to entry. Our primarygoal was to simplify this interface withoutdumbing it down. We devoted more designeffort to this task than to any other system inthe game, and it required many iterations beforewe were happy with it. We adopted a bi-modal

Irrational Games’ SYSTEM SHOCK 2 12interface in which there are two distinct modes(inventory management and combat/exploration)between which the player can toggle. Thiswas a risky decision. This bi-modal model wasmandated by our desire to keep the familiar andpowerful mouse-look metaphor common tofirst-person shooters while retaining cursorbasedinventory management. How we switchedbetween modes became our biggest design challenge.Sometimes these mode changes are explicitlyrequested through a mode change key, andsometimes they are invoked automatically byattempting to pick up an object in the world. Sofar this system seems to be working well, thoughonly time and user feedback will tell whether wereally got it right.5. Working with a young teamThe SYSTEM SHOCK team was frighteninglyyoung and inexperienced, especially for such ahigh-profile title. Many of our team memberswere new to the industry or had only a fewmonths’ experience, including the majority ofartists and all the level builders. Of the threeprincipals, only Rob had previous experience inhis role as lead programmer. Neither Ken, thelead designer, nor I, the project manager, hadpreviously worked in these roles. It’s not totallyclear how we pulled off our project with ourlimited experience.Partially, it must have been due to our ability tobond as a team and share knowledge in ourcommunal work environment (“the pit”). To acertain extent, inexperience also bred enthusiasmand commitment that might not have beenpresent with a more jaded set of developers. Wealso worked hard to transfer knowledge fromthe more experienced developers to the less seasonedindividuals. Rob worked on an extremelycomprehensive set of documentation for thefunctional object tools, as well as a set of exercises(“object school”) to be worked on eachweek. These kinds of efforts paid back theirinvestment many times over.This is not to say that our progress was allsweetness and light. The art team, for example,floundered for a long time as we tried to integratethe junior artists and imbue a common artlook in the team’s psyche. We had a lot of verymediocre art midway through our project andthe art team was stagnating. Ultimately, managementhad little to do with the art team’s success—theywere largely able to organizethemselves and create a solid, original look. Onthe management front, our inexperience wasapparent. We blundered through the early stagesof development with scheduling and managementissues. A large problem was our failure toassign specific areas of responsibility andauthority early on. Bad feelings arose as a result,which could have been avoided if we had clearlydelineated areas of responsibility from the start.What Went Wrong1. Poor level design processLevel design is a clearly defined professionalactivity in the game industry. It’s a professionthat mixes artistic and technical skills in equalmeasure, and the bar is raised on both fronts

13Section I: STARTUPS13every year. Despite our understanding from thevery beginning that the level building would bea problematic part of the SYSTEM SHOCKdevelopment process, we didn’t quite grasphow difficult and time consuming it would be,nor did we expect that it would eventuallyblock the shipment of the game.In hindsight, our failure to understand theamount of work needed to design levels is reprehensiblegiven that we had seen the same problemsemerge on THIEF, and that SYSTEMSHOCK 2 levels involved substantially morecomplex object placement than THIEF. Iattribute this error mostly toour denial of the problem—wehad a limited budgetfor level designers andthere is a long training timerequired to get designersfamiliar with the complexDark Editor. So we lockedourselves into working withthe resources we had.Hacking the security system.Since each individual taskrequired from the designer (apart from initialarchitectural work) was relatively simple, it waseasy to believe that the sum total of work wasalso relatively small. What we overlooked wasthe fact that SYSTEM SHOCK 2 involves so manyobjects, scripts and parameters. As such, thework load on level designers was excessivelylarge. In addition, we made a classic beginner’smistake and failed to provide adequate time fortuning in response to playtesting feedback. InSYSTEM SHOCK 2 this was particularly importantbecause the ability of the player to reenterlevels means that the difficulty of a level cannotbe adjusted in isolation from the rest of thegame. Often we had to impose global changesacross all levels, which could be very expensiveeven when the change was relatively minor.We took a novel approach to the level buildingprocess by attempting to design levels using aproduction-line method. Using this metaphor,we attempted to divorce the different stages ofwork on the level: rough architecture, decorativeand functional objects, architectural polish,and lighting. It was not considered necessary forthe same individual to be involved in all stagesof this production process.This approach had positiveand negative consequences.The advantages were that wecould track progress on levels,we could “bootstrap”levels fairly quickly, and wecould (in theory) swap individualsin and out of differenttasks. The disadvantages arefairly obvious, and most stemfrom the fact that the variousstages of level design are clearly not independent(for example, architecture is ideally built withan understanding of the functional objects thatare to be used in the level).Although I think our process was necessary inorder to get the game out on time, it probablydetracted from the quality of some of the levels.In addition, psychological factors, such as lackof ownership and training issues (stemming fromunfamiliarity with levels) speak very stronglyagainst transferring people from one task or

Irrational Games’ SYSTEM SHOCK 2 14level to another. Nevertheless, there were severalbenefits of our procedure—mostly the ability toemploy particularly talented individuals to pinchhit on particular levels, and the psychologicalbenefits of completing architectural work earlyin the schedule.Perhaps the rudest shock in our level buildingprocess came from our misunderstanding ofwhat part of the process would prove to be mostdifficult. Architectural work was actually fairlysimple, because we intentionally kept our spacesfairly clean and did not attempt anything toounusual. However, placing and implementingour objects was far more complex and involvedthan we expected. One difficulty that weencountered was educating our designers inwhat was expected from them in terms of gameplayimplementation. Most of our level buildershad previously built QUAKE or UNREAL levelsand were not familiar with the style of gameplaythat we were trying to build in SYSTEM SHOCK2. Partially this was because we were simplyexploring a style of gameplay that we did notentirely understand ourselves. But it reflected afailure on our part to properly educate thedesigners. Building prototypical spaces, lookingat past games, and conducting more intensivediscussions about gameplay will all be part ofour future projects.2. Motion capture difficultiesThe Dark Engine has a complex creature animationplayback system and deformable mesh renderer.We encountered many problems with thispiece of technology along our data integrationpath, and found quirks in the playback systemsas well. Primarily, the system was hampered bythe fact that data frequently had to be modifiedby hand, that mysterious bugs would appear inmotions during playback which had not beenpresent in the source data, and that few toolswere available for debugging and analysis. Wewere ill-equipped to deal with these kinds ofproblems, having devoted few resources to dealingwith the technology problems.Our primary animation source was motion capturedata. We were nervous about the technologyfrom the start and attempted to minimizeour risk by concentrating primarily on humanoidcreatures with a small number of interestingvariants such as spiders and floating boss monsters.In retrospect, this was a very wise decision,as we had a lot of trouble even with thissimple set of creatures.Motion capture technology and capture serviceswere contracted from a local company, butunfortunately this company viewed its motioncapture work primarily as a side business anddid not display much interest in it. In fact, theycancelled this sector of their business during ourproject, and we had to fight hard to completethe sessions that we had already scheduled withthem.Our capture sessions were hampered by ourinexperience with the technology and by the factthat we did not plan properly for the sessions.We hadn’t defined key poses, rehearsed themotions, or ensured that our motions were compatiblewith the technology. Optical capturetechnology, the technology that we used, can beglitchy and has difficulty with motions that have

15Section I: STARTUPS15obscured markers, as in the death motions thatwere necessary for SYSTEM SHOCK 2. Over thecourse of three sessions, we gradually refinedour motions, but we spent a lot of time reshootingfailed captures from earlier sessions. Even inthe best cases, most of our captures exhibitstrange artifacts (feet pointing down throughthe ground, hands improperly aligned, and soon), whose causes are still unknown to us. Infuture projects we will hand-animate almost allof the data, and we will need to understand betterwhat aspect of the conversion process introducedthese artifacts into our final gameanimations, although the irregularities neverappeared in our raw data. Motion capture technology,while highly efficient compared to handanimation, must be approached carefully toobtain good results.3. Implementing scriptedsequencesMotivated by the dramatic scripted sequences inHALF-LIFE, we attempted to introduce similarelements into SYSTEM SHOCK 2. In doing so, webroke one of our rules: we tried to step outsidethe bounds of our technology. Although weattempted relatively simple sequences and ultimatelygot them working, they were time sinks,and the payback was relatively slight. For example,we scripted a hallucinatory sequence inwhich the player character rides through theinterior of the alien boss-monster, known as theMany. This so-called “Many ride” was thesource of innumerable bugs—the player wouldbe thrown off the moving platform, manage tokill his projected self, bump into walls, and soon. We confirmed our intuition that the DarkEngine does not support complex scriptedsequences well because the toolset (AI, movingterrain, and animation) is not optimized for thissort of behavior. The moral is, once again, towork with your technology, not against it.4. Inexperience with multiplayergame developmentEarly in the project we were asked to identifythe major risks associated with the project. Ournumber one candidate by far was the multiplayercomponent. This was the only new substantialengine feature that was to be added andit was a complicated piece of work. We wereparticularly nervous about this technology for acouple of reasons. First, it is usually muchharder to make this kind of pervasive change toan existing piece of software than it is to buildit in from scratch. Second, Looking Glass hadno track record in shipping multiplayer technology,and we were not confident that thedevelopment was fully understood. Irrationaldid not want to introduce multiplayer supportinto SYSTEM SHOCK 2 because we considered ita tangential feature that did not contribute toour core strengths. However, marketing concernsdictated it, so ultimately we acquiesced.Our lack of enthusiasm for this feature contributedto its developmental problems because wefailed to monitor its progress adequately orraise concerns when that progress fell behindschedule. Because this was the first multiplayerproduct developed by Irrational or LookingGlass, we did not properly estimate the timerequired for the multiplayer testing. We did notdevote adequate quality assurance resources tothis feature. Too much time was spent testing

Irrational Games’ SYSTEM SHOCK 2 16the multiplayer features over the LAN and notenough over the more demanding modem connections.Given the difficulties posed by themultiplayer technologies, the engine developersworking on the task made great efforts, andtheir early results were promising. However, theearly departure of one of the programmers, andthe fact that he was not replaced, ultimatelydoomed any possibility of shipping the multiplayertechnology with the initial SKU. Reluctantly,we opted for a patch that would beavailable at the same time as the single-playerbox reached shelves. Our cooperative multiplayergame will undoubtedly be fun and willprobably be enjoyed immensely by a relativelysmall number of our customers.However, we wonder whether ourfailure to deliver a promised featurein the box will ultimately hurt usmore than the absence of that featurefrom the start would have.run a business knows, there is a lot more tostarting and maintaining a company than sittingaround at board meetings smoking cigars. Fromthe mundane matters of making payroll, organizingtaxes and expense reports to businessnegotiations and contract disputes, there is substantialoverhead involved in running even asmall company such as Irrational.In our naïveté, we did not factor these tasks intoour schedules, and the result was that theymostly became extra tasks that kept us in theoffice late at night and on weekends. As a resultof our misjudgment, we just had to work harder.Rather than enduring a crunch period of a few5. Running a companywhile building a gameAs the principals of the company,Ken, Rob, and I didn’t really understandwhat it took to run a businessand simultaneously work in thatbusiness. None of the Irrationalfounders started the company to bebusinessmen, and we have alwaysbelieved that the ultimate health ofthe company depended on us allstaying involved in the developmentprocess, which is, after all, whateach of us enjoys and wants to do.Unfortunately, as anyone who hasThe team at Irrational Games, from left to right: FIRST ROW:Steve Kimura/Artist, Jonathan Chey/Project Director, JustinWaks/Multiplayer Programmer, Mauricio Tejerina/Artist, Rob“Xemu” Fermier/Lead Programmer, Dorian Hart/Designer,Lulu Lamer/QA Lead. SECOND ROW: Ian Vogel/LevelDesigner, Scott Blinn/Level Designer, MichaelSwiderek/Artist, Rob Caminos/Motion Editor, NateWells/Artist. THIRD ROW: Mike Ryan/Level Designer, KenLevine/Lead Designer, Mathias Boynton/Level Designer.NOT SHOWN: Gareth Hinds/Lead Artist.

аллантоидный стебелек (caulis allantoicus, LNE) - образование в виде стебелька, соединяющее зародыш ивнутреннюю поверхность бластодермического пузырька; содержит эпителиальную выстилку и производныевисцеральной мезодермы - соединительную ткань с кровеносными сосудамиаллантоис (allantois; греч. alias, allantos колбаса + -eides подобный) - полый вырост задней кишки зародыша высшихпозвоночных, состоящий из слоя энтодермы (у человека недоразвитого) и слоя висцеральной мезодермы, в которомобразуются кровеносные сосуды, входящие в состав плацентарного круга кровообращения; наиболеепроксимальный участок А., соединяющийся с задней кишкой, дает начало мочевому пузырюаллели (греч. allelon друг друга, взаимно; син.: аллеломорфы, гены аллельные) - формы состояния одного и того жегена, занимающие идентичные локусы гомологичных хромосом и обусловливающие фенотипические различияособейА. ДИКОГО ТИПА - см. Аллели нормальныеА. ДОМИНАНТНЫЕ - А., одинаково проявляющиеся в гомо- и гетерозиготном состоянии и препятствующиепроявлению других аллелей данного гена у гетерозиготА. ЛЕТАЛЬНЫЕ (син. летали) - А., обусловливающие гибель организма-носителяА. МНОЖЕСТВЕННЫЕ - А. одного гена, возникающие в результате мутаций и отличающиеся по своему проявлениюА. НЕСТАБИЛЬНЫЕ - А., характеризующиеся высокой мутабельностью, т. е. мутирующие значительно чаще среднегоуровня спонтанных мутацийА. НОРМАЛЬНЫЕ (син.: А. дикого типа, плюс-аллели) - А., обычно доминантные, обусловливающие развитиепризнака, характерного для большинства особей, составляющих природные популяции данного биологического видаА. ПОТЕНЦИАЛЬНЫЕ - см. ИзоаллелиА. РЕЦЕССИВНЫЕ - А., проявляющиеся только в гомозиготном или гемизиготном состоянииА. СУБЛЕТАЛЬНЫЕ - А., значительно снижающие жизнеспособность организмов-носителейаллели ложные - см. Псевдоаллелиаллеломорфизм ступенчатый (аллели + греч. morphe форма) - гипотетическое подразделение гена на линейнорасположенные, частично перекрывающиеся и способные к самостоятельному мутированию части (субгены)аллеломорфы (аллели + греч. morphe форма) - см. Аллелиаллелотип (аллели + греч. typos отпечаток, образец, тип) - совокупность аллелей или генов, несущих информацию опризнаках данной популяцииАллеманна синдром (R. Allemann, 1893-1958, швейц. уролог) - наследственная аномалия развития: удвоение почек идеформация пальцев в виде барабанных палочекАллена - Буриана трабекулотом (Allen; F. Burian; трабекула + греч. tome разрез, рассечение) - микрохирургическийинструмент для рассечения участка трабекулярной сети глаза, представляющий собой зонд с режущейповерхностью, изогнутый соответственно кривизне венозного синуса склеры (шлеммова канала)Аллена проба (W. М. Allen, род. в 1904 г., амер. гинеколог; син. Аллена - Хейуэрда - Пинто метод) - метод изученияфункционального состояния коры надпочечников, основанный на определении количества дегидроэпиандростеронав суточной мочеАллена - Хейуэрда - Пинто метод (W. М. Allen, род. в 1904 г., амер. гинеколог; S. J. Hayward, А. I. Pinto) - см. Алленапробааллерген (allergenum; аллергия + греч. -genes порождающий) - 1) вещество антигенной или гаптенной природы,способное сенсибилизировать организм и вызывать аллергию; 2) препарат для диагностики и лечения аллергическихзаболеваний, изготовленный из экзогенных А., обычно не вызывающий сенсибилизации организма и аллергическихреакций при правильном его примененииА. БАКТЕРИАЛЬНЫЙ (а. bacteriale) - А., представляющий собой компонент бактериальной клетки, продукт еежизнедеятельности или специально изготовленный из них препаратА. БЫТОВОЙ - А., с которым человек контактирует в быту, напр., домашняя пыль, продукт бытовой химии и др., илиспециально изготовленный из них препаратА. ВИРУСНЫЙ (a. virale) - A., представляющий собой компонент вируса, продукт его взаимодействия с клеткой илиспециально изготовленный из них препаратА. ГЕЛЬМИНТНЫЙ (a. helminthicum) - А., представляющий собой продукт обмена или распада гельминта илиспециально изготовленный из них препаратА. ГРИБКОВЫЙ (a. mycoticum) - А., представляющий собой компонент грибка, продукт его жизнедеятельности илиспециально изготовленный из них препаратА. ДИАГНОСТИЧЕСКИЙ (a. diagnosticum) - А., применяемый для диагностики болезней путем постановкиспецифических аллергических диагностических пробА. ИНГАЛЯЦИОННЫЙ - А., попадающий в организм в естественных условиях через органы дыханияА. ИНФЕКЦИОННЫЙ (a. infectiosum) - А., представляющий собой компонент возбудителя инфекционной болезни,продукт его жизнедеятельности или специально изготовленный из них препаратА. КОНТАКТНЫЙ (a. contactilе) - А., попадающий в организм в естественных условиях через кожу, конъюнктиву илислизистую оболочку ртаА. ЛЕКАРСТВЕННЫЙ (a. medicamentosum) - А., представляющий собой лекарственное средство или какой-либо егокомпонентА. ЛЕЧЕБНЫЙ (a. medicale) - A., применяемый для проведения специфической гипосенсибилизации при аллергическихболезняхА. МИКРОБНЫЙ (a. microbicum) - А., представляющий собой компонент микроорганизма, продукт егожизнедеятельности или специально изготовленный из них препаратА. ПИЩЕВОЙ (a. alimentarium) - А., представляющий собой компонент пищевого продукта или специальноизготовленный из него препаратА. ПРОМЫШЛЕННЫЙ - А., представляющий собой вещество, входящее в состав исходного, промежуточного иликонечного продукта промышленного производстваА. ПРОТОЗОЙНЫЙ (a. protozoale) - А., представляющий собой компонент организма, относящегося к типу простейших,продукт его жизнедеятельности или специально изготовленный из них препаратА. ПРОФЕССИОНАЛЬНЫЙ (а. professionale) - А., с которым человек контактирует в условиях профессиональнойдеятельностиА. ПЫЛЕВОЙ (a. pulvereum) - A.,. представляющий собой компонент домашней (бытовой) пыли или специальноизготовленный из нее препарат29

This Page Intentionally Left BlankIrrational Games’ SYSTEM SHOCK 2 18

19Bohemia Interactive Studios’OPERATION FLASHPOINTby marek spanel and ondrej spanelThe story of OPERATION FLASHPOINT’s developmentis quite unusual in the game industry thesedays. For one thing, the team didn’t start out asprofessionals; originally only the lead programmerwas allowed to work on the game full-time.Switching publishers three times, starting a newcompany, growing the team from one to 12 fulltimemembers, and moving offices five timesduring the game’s development were just someof the hurdles we had to clear. Only the team’svision and obsession for the game remainedconsistent from the very first playable versionuntil the end. It’s not possible to describe wholestory in the space given for this article, so let’sjust jump directly to the final moments.It was 8 P.M. on Friday, May 25, 2001. Ourpublisher’s representative, who had been in Praguefor the last few days to make sure everythingwas going OK as we were finalizing thegold master, left Prague feeling confident thatthings were going well—the disc was almostready and could be sent to final testing and thento manufacturing after some weekend testing.Meanwhile, our lead programmer (To makematters even more exciting, he was then workingat his temporary home in France for coupleof weeks.) was trying to resolve some seriousBack-StoryOPERATION FLASHPOINT is one of the most realistic simulationsyet made of modern infantry combat. Playersassume the role of a Marine and progress from basictraining to command roles, in a variety of real-world missionsset against a background of 1980s central-Europeanrealpolitik. Bohemia Interactive accomplished thedifficult task of adding realistic details, such as limitedinventory and critical hits, without losing gameplay, raisingthe difficulty bar while substituting tension andimmersion for the usual explosion-heavy killfest. OPERA-TION FLASHPOINT expands the standard formula withground and air vehicles and squad-based combat, makingthis game as much a tactical simulator as first-person-shooter.graphical anomalies with the hardware transformationand lighting (HW T&L) rendering. If hewere to fail, HW T&L would not be included inthe final release. If he solved it, some data organizationchanges would be necessary to suit theneeds of the HW T&L. He spent nearly thewhole day resolving some random crashes thatappeared in the game during the last day, goingback and forth over e-mail with an Nvidia supportengineer.The crash was fixed by late afternoon, and by10 P.M. it looked like the HW T&L problemswere at an acceptable level. Around midnight,

Bohemia Interactive Studios’ OPERATION FLASHPOINT 20the tools that would perform the data formatchange were ready. On the other front, the teamhad received the final localized strings for thegame. However, the file containing the corestrings of the game that had been delivered byour publisher appeared to be untested and unusable.After spending a couple of hours dealingGame DataRelease date: June 22 (worldwide except NorthAmerica), August 29 (North America), 2001Publisher: CodemastersGenre: realistic first-person shooterPlatform: Windows 98/ME/2000Full-time developers: 10Part-time contractors: 3Estimated budget: $600,000Length of development: Over 4 yearsDevelopment hardware: Various PC systems from266MHz Pentium IIs to 1GHz Pentium 4s and 1.2GHzAthlons with 20GB hard drives and Voodoo 2 orGeForce 2 graphics cardsDevelopment software: Windows 98/2000, Linuxservers, Visual C++ 6, SourceSafe, Adobe Photoshop5.0, 3DS Max, Microsoft Office, TextAloud (for voiceprototyping)Proprietary software: Oxygen (3D low polygonmodeling and texturing tool), Visitor (landscapeeditor), and some other proprietary toolsNotable technologies: DirectX, Vorbis Ogg, Vicon 8motion capture systemProject size: 10,000+ files, 250,000 lines of C++(some assembly), 5,000 textures, 800 3D models,100,000 words (localized into six other languages),more than 60 single-player and multiplayer missionswith it, most of the team had to go home tohave some sleep. Still, the team leader stayedbehind at the office, trying to use the new HWT&L data format, going over each step byphone or e-mail with the lead programmer(while also trying to implement new localizedstring tables and fix some problems in the campaignand missions). At 3 A.M. it looked like allthe data had been converted—and both the leadprogrammer and the team leader could go havesome sleep.Saturday morning, our publisher realized thatthe gold master hadn’t actually been delivered.Tensions rose even further, and nerves began tounravel. Only two days remained before massproduction was scheduled to begin. Everyone onthe team had been working since early Saturdaymorning, but at times a successful end to theselast-minute crises seemed to be so far away. Byaround 5 P.M. on Saturday, most of the importantissues in the code had been resolved, andthe lead programmer decided to take anotherlook at the HW T&L implementation. Luckily,within a few hours, he suddenly discovered theroot of all of the HW T&L problems and fixedthem.The plan was to deliver the gold master to ourpublisher via FTP by that evening. Nobodyexpected that it would actually take until Sundaymorning. After a long, sleepless night of playingthrough the game and fixing any problems thatappeared, everything looked fine, and most ofthe team could finally go to sleep again. Withsome relief, we finally started the game uploadon Sunday around 9 A.M. But were we done?Not yet. Suddenly, a seagull stopped flying in

21SECTION I: STARTUPS21some of the in-game cut-scenes. The team leadercalled to wake up the lead programmer inFrance: “The seagull is not flying. What should Ido?” We had to stop the upload until the leadprogrammer delivered necessary code fix.After the project leader received the updated filesfrom the lead programmer, he started to rebuildthe game in Visual Studio. It was Sunday aroundnoon, and the game had finally gone to the publisherfor final testing. The publisher’s test staffstarted playing the game Sunday afternoon.Everything went smoothly at first, but later theydiscovered one serious scripting bug in one ofthe campaign missions that made it unplayable.Late in the evening, they called the team leaderabout the bug, and he had to drive to the officeafter sleeping just a couple of hours over the pastthree days to fix the bug as quickly as possibleand then upload the fixed version to the publisher’sserver in the U.K. Around midnight Sundaynight, the disc was finally ready to go.Three weeks later, hundreds of thousands ofcopies of the game were available in storesworldwide. In the meantime, the developmentteam was playing the game, terrified of finding adisastrous bug. Fortunately, no such critical bugappeared. Considering the amount of workwe’d done on the game in those last couple ofdays and hours, the risk of finding some majorproblems was pretty high. On Friday, June 22,the game was released, and it immediatelybecame the top-selling PC game in many countries.The team knew that their mission was successfullycompleted. The passion and hard workof every single member of the development andpublishing teams started to pay off.What Went Right1. The teamProbably the most positive thing we encounteredduring development of this game was thepeople working on it. Almost all of the peoplewho joined the team really helped to improvethe game and remained fully dedicated to itfrom the first day until the final moments. Whilewe were understaffed almost all the time, we arehappy to say that while the team was growingsteadily, it was very stable—almost all the peoplewho participated in the development ofOPERATION FLASHPOINT are still working at ourstudios now that the game is finished.Another advantage was that the team was verycooperative. Some roles on the team were notdemarcated very strictly. Still, between the programmers,designers, and artists, everyone couldcomment on any part of the game, and everyone’sopinions were taken seriously. While thisoften made communication more difficult, itdefinitely helped the design and developmentprocess and enriched the game in many areas.One of the most powerful tools we used forinternal communication was our intranet newsserver, which proved to be an invaluable toolduring the whole design process. The game wasmostly designed on the fly, and the newsgroupsmade the design process not only convenient,but really quite enjoyable.

Bohemia Interactive Studios’ OPERATION FLASHPOINT 222. The communityOPERATION FLASHPOINT’s public following isincredible. We ourselves are surprised by thenumber of people creating fan sites, developingnew content for the game, or just keeping intouch with the community by reading news andforums. Currently there are hundreds of differentsites dedicated to FLASHPOINT, and dozensof them are of a truly professional quality withnews updated almost hourly. Another greatthing about the community is that some of thepeople have been following this game for yearsalready, and they still carry a great deal ofenthusiasm for it.Some of the first great fan sites started out morethan two years before the game was released,and we managed to keep people’s excitementgoing with regular updates about the improvementswe were making to the game throughoutits development. We take it as a good sign thatmost of the sites are still online and updated regularly.About halfway through development, weinvited some people from the community to participatein the design of the game directly, viaexternal forums and newsgroups. Their skills inboth military and gaming areas were invaluable,and we constantly used their feedback toimprove the game.Since the release of the public demo version(around three months prior to the release of thefinal game), the community following hasbecome much bigger. The only downside to theincrease in the community base is that the communityhas become much less focused and lessmature, as the average age of those visiting theWeb sites has descended.The Head of a tank crew in Oxygen. Youcan see face of Petr Pechar, one of theartists on OPERATION FLASHPOINT, under thehelmet.A Soviet AKSU rifle shown in BohemiaInteractive’s proprietary modeling tool,Oxygen, with direct real-time previewingusing the game’s engine.But the community still looks really vital andthe most-visited fan site has counted millions ofpage views already. Recently, fans have been creatingcustom-made tools and enhancements tothe game in addition to the various Web sitesand services.

23SECTION I: STARTUPS233. Open architectureSince we know that plenty of players enjoy notjust playing games but also providing their owncontent for them, we wanted to enable thisextensibility as much as possible. Therefore, thegame included exactly the same mission editorthat we had used to design our missions. Inaddition, much of the game’s functionality isdata-driven instead of being hardcoded.This includes not only themission files and world maps butalso the capabilities and propertiesof units. The units are stored in avery powerful hierarchical configurationtree with inheritance capability,yet they are relatively easy toedit.expression evaluator for trigger activation,which was surprisingly powerful, and a fullscripting language soon followed. When thegame was released, we knew immediately thatscripting was a really good choice, as many usermademission used scripts to implement specificnew functionality. Looking back, we can sayscripting proved to be much more powerfulthan we expected.By using these configuration files, itis possible to add completely newunits and worlds to the game oradd modified versions of existingones, which is what many playersare doing to create their own content,thus lengthening the product’slifespan. We wanted to use configurationfiles to shorten coding time as well,because we figured that the fine-tuning of mostvalues could be done by designers or testersinstead of programmers. But this didn’t work aswe expected, mostly because only the programmersreally knew meaning of the values.Our scripting language also featured prominentlyin the game’s development and extensibility.We started to build the mission editor as avisual tool, but we soon recognized its limitationsin certain areas. Seeing this, we added anBohemia Interactive’s in-house motion capture facility hasproven very beneficial in creation of lifelike humanmovement animations.We only wish we had added it sooner in thedevelopment cycle, so that some of the functionalitythat we hard-coded into the game couldhave been scripted instead, including some AIbehavior.At a later stage of development (after the Europeanrelease, in fact), we extended the game’sability to support add-on content. Single filesstored in specific folders could add, forinstance, new models, units, or islands. Besides

Bohemia Interactive Studios’ OPERATION FLASHPOINT 24some official add-ons that we have introducedsince the game’s release, there is already a massivenumber of user-made add-ons, all availablefor free on the Internet.4. Creative freedomFrom the very beginning of the project, we triedto create the game that we really wanted to play.We didn’t look too much toward other gamesfor inspiration, and we virtually ignored gamesthat might be considered our competition. Wealso gave little regard to whether the marketwould like the game or not. Our relationshipswith publishers were never too strong (actually,we changed publishers several times), and allimportant decisions were made by the coredevelopment team, keeping us relatively independentthroughout the game’s development.In fact, changing publishers so many timeswasn’t strictly a negative thing. Even though itled to some financial uncertainties, the creativefreedom we enjoyed instead of some moremoney was more than worth it. The result ofthis creative freedom is a game that is really distinct.Our design-on-the-fly approach (or“design by playing,” as we prefer to think of it)made the game very enjoyable and a differentexperience from any other.Most design decisions were first discussed(mostly in newsgroups as mentioned earlier) andthen tried out in the game. No matter how nicea design idea might have seemed at first, onlythe elements that worked well in the gameended up being included.5. Long development cycleThe unusually long time that FLASHPOINT wasin development was very beneficial. In terms ofgameplay, the game is very mature, whichwould not have been possible in a shorter developmentcycle, especially because this was ourfirst major game. Two or three years into development,the game started to be really enjoyable.In fact, it was polished enough then to suit ouroriginal plans for the release version. But due tovarious things (mainly on the publishing side),the game wasn’t released at that point, whichgave us more time to polish and improve it. Wewere able to incorporate various features thatwe originally hadn’t planned to develop, eitherbecause they were too difficult or requiredexcessive CPU or memory resources.We were also able to incorporate feedback fromvarious external testers—our friends as well ascolleagues at well-known gaming companieswho evaluated the game throughout its development.We refocused and redesigned the game acouple of times, always opting to keep everythingthat worked well and change the things wefelt could work better.What Went Wrong1. Development cycle muchlonger than expectedIronic as it is, we have to start What WentWrong exactly where we left off with WhatWent Right. Despite some of the usefulness the

25SECTION I: STARTUPS25extra development time offeredus, in the end the cycle wasprobably too long, and in optimalconditions would havebeen at least 20 percent shorter.It may have been possible toshorten the cycle, but we experiencedvarious external eventsor internal missteps that preventedus from accomplishingthat.First of all, some technologiesin the game were a bit outdatedafter more than four years. Wedidn’t know at the outset thatthe game would be still indevelopment after so long, andwe hadn’t left time at the end torework parts of the engine. Some of the criticismof OPERATION FLASHPOINT addresses theamount of detail in the textures and some models—andwe have to admit that these could havebeen better.Furthermore, the excessively long developmentcycle led to burnout and heavy exhaustion, particularlyfor the people who had been workingon the game since very beginning (the lead programmer,lead artist Jan Hovora, and the teamleader). In some cases, we weren’t able to sustainsome of the features we’d implemented twoor more years prior. They just disappearedsomehow in the process of reworking parts ofthe code, and we didn’t even notice. Newcomersto the development and testing process neverknew such features had ever existed.OPERATION FLASHPOINTenables the player to use anyvehicles, including gunshipsand planes.The main problem wasn’t thatthe development cycle was toolong per se, but that the developmentwas so much longerthan we’d expected. Next time,we will work much more diligentlyto better estimate ourdevelopment time—and we willprobably try to aim higher withthe detail of our artwork, evenif it seems insanely detailed forpresent and predicted hardwarecapabilities.2. DocumentationLack of documentation is acommon affliction among gamedevelopers, but some aspects ofthis problem were so severe in our case that theyare worth mentioning. While we’d neverbelieved too much in designing the game onpaper, the real problem was that we never evenhad documentation of the things that we’d finished.This situation led to incredible problemsin the final stages of development. Many taskscould only be done by one person on the wholeteam. In other cases, hours were spent trying toinvestigate how something had originally beenmeant to work.We recognized these problems and tried toimprove them, but apart from a few instances,our effort wasn’t really successful. As the developmentteam grew, the missing documentationwas becoming a more serious problem. But thefinal project deadlines were getting closer as

Bohemia Interactive Studios’ OPERATION FLASHPOINT 26well, so it was nearlyimpossible to find thetime to address the problem.3. QualityassuranceWe experienced variousproblems in communicationand cooperationwith our publisher. Generally,their focus andassistance in some areasof the production of thegame (design suggestions,voice-overs, translation,scriptwriting)were really helpful. But inother areas, we experiencedsome events andcircumstances thatslowed down and complicatedthe game’s developmentrather than movingthings forward.One of the most unsatisfactory areas was theway the QA procedures were managed anddesigned to work by the publisher. We neversucceeded in achieving a common bug database,and the publisher enjoyed an illusory feelingthat its QA database really covered the project.The truth was that such a database (even withoutany direct access for the development team)hardly said anything about the project’s statusbecause it covered just small fraction of all theThe combination of infantry combat withfull simulation of vehicles is a crucial partof the design of OPERATION FLASHPOINT.problems we had tried tofix.Even when the publisherdedicated a pretty bigtesting team to the game,it sometimes seemedsomething of a waste oftime for everyoneinvolved in it. In the end,we had to largely ignorethe publisher’s QAreports, because they containedtoo much uselessinformation and very fewreal bugs. We tried tofocus on very limitedexternal testing manageddirectly in the very latestages of development toameliorate this problem—butthis approachcould hardly replace real,full-time testing of thegame.We admit the situation was very difficult for theQA team as well—in no small part because ofthe lack of documentation on our side—but westill believe this process could have been handledmuch better. One of the mistakes we madewas assuming that the publisher’s QA would besufficient, so we didn’t build a strong testingteam in-house. We definitely will find a solutionfor any future projects, because the way it wasdone for OPERATION FLASHPOINT wasn’t satisfactory.

27SECTION I: STARTUPS274. Some content was not underour full controlOne area of concern thing was that our final CDwas still manipulated by the publisher. The publisherapplied SafeDisc protection to the finalcode, which caused some unexpected compatibilityproblems that we weren’t able to control.The mixing of various SafeDisc versions and aserious compatibility problem with Windows2000 that was present in the first Europeanbatch of CDs could have been avoided.In addition, we weren’t able to finalize theEnglish language in the game because we didn’thave a native English writer on the team. Wealso didn’t oversee the voice recording and voiceactor selection, which led to some results thatwere unsatisfactory to us.5. Multiplayer APIFrom the very beginning we were aware thatour game had huge multiplayer potential, especiallyif it were implemented as a massively multiplayeronline game. But we knew we would beunable to deliver such experience.Instead of aiming for such an unrealisticallyhigh goal, we decided to implement missionbasedmultiplayer that shared as much code aspossible with single-player game. Even thiseffort proved to be extremely difficult.OPERATION FLASHPOINT was always developedprimarily as single-player game with a strongstory, but for a very long time we were thinkingabout multiplayer functionality, and we tried toDaytime and weather changes dynamicallyin the game so the area looks prettydifferent in various daytime and weatherconditions.design the game code in such a way that itwould help us incorporate multiplayer later. Forimplementation, we wanted to avoid low-levelnetwork coding and instead use a high-levelAPI.As we were already using Direct3D for graphicsand DirectSound for audio, and both suited ourneeds quite well, we decided to use DirectPlay asour network API. DirectPlay offered high-levelhandling of all network communication, includingVoice Over Net capabilities. Unfortunately,our experience with this API was extremely bad.Often when trying to get some high-level functionalityworking, we realized it contained bugsthat rendered it almost unusable. We had toimplement our custom code for things wethought DirectPlay would provide, but that wassometimes very hard, as we did not have thelow-level control that we needed.

Bohemia Interactive Studios’ OPERATION FLASHPOINT 28We also encountered many performance problems,some very strange, such as significant (particularlyserver-side) slowdown even with notraffic over the network. This along with thelack of documentation and a lack of stabilityresulted in many problems that were hard todebug. Another drawback that we didn’t recognizebeforehand is that DirectPlay is Windowsonly,but many dedicated servers for games currentlybeing played online run on Linux. Overall,selecting DirectPlay as our network API wasone of the most unfortunate decisions in thewhole game’s development.Future DreamingMost start-up game developers dream of developinga number-one title. We weren’t any different.With OPERATION FLASHPOINT, this dreamhas come true for us. The game achieved thenumber-one position in sales charts of variouscountries and regions, including the U.S., Germany,the United Kingdom, Benelux, Scandinavia,and Australia. More than 500,000 copiessold worldwide in just three months, proving tous that our last four years of effort were worthsomething.We always stayed focused on the game, and wedidn’t have too much regard for those whobelieve that the success of any game is mainly aquestion of marketing, securing a big license, orworking on a sequel. We always believed thatit’s the game itself that makes the differencebetween success and failure. We’re still playingthe game and we still like it. After such a longtime, it’s hard to believe that OPERATION FLASH-POINT remains the favorite choice of games formost of the development team. We’re still workingon new content for FLASHPOINT out of pureenthusiasm. In the end, we don’t feel ourselvesto be anything more than proud members of abig and healthy FLASHPOINT fan communitythat has arisen around the world.We know that someday we will have to leaveFLASHPOINT to its own destiny. But currently,we still feel too involved in the game. We arealready looking forward to future projects, butit will take months for us to start one. We considerthe success of OPERATION FLASHPOINT asthe pole position for our next race. We plan touse all the experience and resources that wehave gained during the last couple of years topush gaming even further in the future.

29Surreal Software’sDRAKAN:ORDER OF THE FLAMEby stuart denmanOrigins of the TeamBecause DRAKAN was Surreal’s first product, thestory of DRAKAN’s development is also the storyof Surreal’s development as a company. Surreal’screation is the classic game development story inwhich four ambitious recent college graduatesdecided they had nothing to lose and formed agame company. These four founders contributedfour critical skills to the team: art, programming,design, and business skills. None of ushad ever run a company or managed schedules,but we all loved games, and we knew what ittook to make a good one.Lead designer Alan Patmore had always playedgames and had the business savvy to complementNick Radovich’s business experience andconnections. I had been programming gamesand graphics since the age of ten, so eventhough I didn’t have experience working at agame development company, I did have theskills and motivation. Mike Nichols, our creativedirector, came from within the industryBack-StoryDRAKAN: ORDER OF THE FLAME is a fantasy 3D actionadventuregame on the TOMB RAIDER model with thirdpersonperspective highlighting the iconic central characters:a beautiful woman with a sword teamed with afire-breathing dragon. The different abilities of the protagonistscombine to produce varied and new gameplaypossibilities, with an aerial perspective unusual to thegenre.and was the only member with any titles underhis belt.Our initial goal was to develop several gameconcepts and a solid technological foundationthat we could pitch to game publishers. Thiswould get us the funding we needed to pay ourselvesand start hiring programmers and artistswithout having to involve venture capitalists.Once we got project funding, we were able tobuild a strong team of artists, programmers, anddesigners who all played games. Some of theteam came from other game companies—luredby the informal atmosphere and the focus ongames, not profit. Others were inexperiencedwith game development, but had the skills andfresh ideas we needed.

Surreal Software’s DRAKAN: ORDER OF THE FLAME 30As the technology lead, I was determined tobuild Surreal’s foundations on its technology. Byretaining rights to our engine and tools, wealways had something to fall back on if a gamedesign was cancelled by the publisher. This alsoallowed us to develop multiple game titles fromone generic technology and license the technologyto other companies. Any investment in timethat the programmers and I put into the engineGame DataRelease date: August 1999Developer: Surreal Software Inc., Seattle, Wash.http://www.surreal.comGenre: 3 rd -person fantasy action-adventureIntended platform: Windows 95/98Project budget: $2.5 millionProject length: 28 monthsTeam size: 23 full-time developers, 2 sound andmusic contractorsCritical development hardware: Pentium II and AMDK6-2 (3DNow!), 200 to 450MHz, 128MB RAM withNvidia Riva 128 and TNT, 3dfx Voodoo 2 3Dhardware. Artist workstations: Wacom tablets.Critical development software: Windows software,Programming software: Microsoft Visual C++ 5.0 and6.0, Visual SourceSafe 5.0, Intel VTune 2.5,InstallShield International 5.0. Art and animationsoftware: Softimage, 3D Studio Max, AdobePhotoshop, In-house modeling and texturing tools.Sound and music: Sonic Foundry Soundforge, EmagicLogic Audiocould be quickly put to use on another project ifanything went awry.We moved away from the popular DOOM-typeengines toward a landscape-style renderingengine in order to set our games apart. Therewere many unique ideas that we could buildfrom this: flying, underwater environments, outdoordeathmatch, and so on. But the technologywas not only about rendering; the tools had toempower the designers and be general enoughto support almost any game. So I designed atoolset in which every game-specific propertyand behavior would be provided by the gamecode itself, and the editor would be just ageneric interface to the underlying game specifics.Origins of the BeastAfter pitching several game ideas to all themajor publishers, we finally sold the first“dragon” concept to Virgin Interactive Entertainment(VIE) in the summer of 1996. The conceptwas very different from today’s DRAKAN.The first concept was for a dragon RTS game inwhich the player’s dragon could fly around takingover villages and forcing them to do theirbidding. VIE wanted a more arcade-styleshooter game to fill a slot in their product line,so we started developing a fast-paced, third-persondragon-flying game.It was not until early 1997 (when VIE begancutting projects just prior to closing its doors)that Surreal sold the DRAKAN concept toPsygnosis. Psygnosis saw the strength in ourteam and gave us complete freedom to perfect

31Section I: STARTUPS31the design. We wanted more of an RPG feel, butas a dragon, the player was limited in what heor she could carry or interact with. Adding ahuman rider was the best solution, and a femalecharacter was the natural choice since shewould offset the dragon’s immense size andpower. With an increased budget under Psygnosis,we hired more team members and increasedthe art and game-play content to a level that thepress called “ambitious” at our public debut atE3 in 1998.The production under Psygnosis allowed us toexpand the technology as well. We added realtimelighting effects and expanded the simpleheight-field landscape engine into our seamlessindoor/outdoor layer technology. Critical to thistechnology was Psygnosis’s willingness to dropsupport for software rendering (a risky marketingdecision at the time). This allowed usunprecedented freedom. We switched over totrue-color textures, increased the polygoncounts throughout the game, and built arbitrarygeometry for our worlds. The downside to relyingon 3D hardware was that we faced seriouscompatibility challenges—the game would haveto run on almost every 3D card. This also meantbattling Direct3D driver bugs, and the possibilitythat we would be inundated with technicalsupport calls, since people would not have softwarerendering to fall back on if the 3D hardwarefailed to work correctly.What Went Right1. Success with graphicsThere’s no doubt DRAKAN had an ambitiousdesign, so the graphics had to be top-notch inorder to make the game world believable. Theamount of art and animation content we wouldneed mandated careful planning, lest our scheduleslip. The solution to the problem was what Icall “flexible reuse.” In addition to the sharingof texture and geometry data between objects,DRAKAN’s engine (code-named the Riot engine)was programmed to allow arbitrary scaling androtation of art content. By assigning differentbehaviors and combining multiple art components,we were also able to create totally newstructures with minimal effort. Because wedropped 3D software rendering, we knew all ofour textures could be created in true color. Thisvastly improved the look of DRAKAN, so muchso that we decided to switch from using palettebasedtextures to true-color textures, whichA panoramic view of the first level in DRAKAN.

Surreal Software’s DRAKAN: ORDER OF THE FLAME 32required quite a bit ofreworking on most of thetextures in the first few levels.This decision is just oneexample of Surreal’s aestheticfussiness. Often if afew people thought thatsomething within the gamedidn’t look good enough, itwould end up gettingredone until everyone wassatisfied. The benefits canbe seen in the final product,but our schedule sometimessuffered as a result.Though the artists createdthe objects and buildings inthe game, the designerswere responsible for placingthe objects into the gameand gave immediate aestheticand game-play feedbackto the artists. Theyalso were responsible forbuilding the landscapes andcaves, which defined the overall level flow. Thisprocess evened out the workload between artistsand designers, but it required the designers tohave a good artistic sense. This can be seen inthe very fantastical landscape architectures thatthe designers constructed and then painted withtileable textures. The textures were drawn bythe artists to have many variations and transitions,which added to the organic nature of theterrain.2. A green teamwith fresh ideasDRAKAN had an advantagethat many large gamedevelopment companiessometimes overlook. It hada young team, highly motivated,bursting with ideas,and ready to take risks. Theideas were unique andmotivated by the desire toset DRAKAN apart from theshooters and TOMB RAIDERclones (although this wasstill difficult, given the tendencyof the gaming pressto compare games to oneanother).The most original idea inDRAKAN was the combinationof dragon flight withsword and bow combat onArokh’s polygon mesh and alphablendedwings (above).tal idea formed a devel-the ground. This fundamenoper’scarnival for moreinnovative ideas and forced the player to strategizein a way not often seen in action games.The relative vulnerability of the female ridercontrasted with the powerful dragon requiredcareful thinking by the designers. Levels werecreated with restrictions on the dragon’s abilityto go places. Rynn could enter caves, but wouldcome across areas where the dragon’s flyingabilities or strength would be necessary to proceed.The player (as Rynn) would then have tofind a large door or other method to get thedragon inside the cave system. In this world of

33Section I: STARTUPS33magic, creative ideas for special effects are veryimportant, and these tasks were ideally suited topeople who were not afraid to do things “outsidethe box.”3. Engine and toolsIf ever there was an example to put the C vs.C++ argument to rest, it is DRAKAN. There simplyare no performance reasons not to go withC++, as long as the programmers understandwhat is happening under the covers. Object-orientedcode generates so many benefits, especiallyfor an engine that you plan to build on formany years to come. In DRAKAN, the game-specificsource code and engine source code wereseparated into different projects, so no gamespecificcode was allowed in the engine. Thegame-specific code included such features as theuser interface, AI, andgame entities, and containedno platform-specificcode.The engine is broken upinto many classes that handlevarious engine tasksand are the interfaces bywhich the game codeaccesses the engine. Forinstance, there is a soundclass for playing sounds, atexture class for workingwith textures, a sequencingclass for playback ofscripted cut-scenes, andnumerous others. Thesealso form a framework forConcept sketch of the Dark Unionsailing ship.future porting of the system-specific functions toother platforms. The stability of this system canbe validated; we are currently creating additionalgames based on the DRAKAN engine withlittle or no code changes to the engine project.To further reduce the debugging time, we putcoding guidelines in place to ensure the consistencyof code between programmers, and createdclasses to catch array boundary violationsand memory allocation problems.DRAKAN has no scripting language. Instead, theprogrammers create modules that are visuallyconnected by the designers to create scriptedevents in the game. Such modules include triggers,switches, timers, counters, and more complexmodules such as doors, enemy creatures,and weapons. The modules have programmerdefinedparameters associated with them. Aparameter can be almostanything: a number, a listof options, a sound, a texture,another module, andso forth. The system meantdesigners could tweakparameters and combinemodules in ways that theprogrammers neverintended.One particularly niceexample was an effect thatwas originally created forthe “ice sword.” The effectwas made up of a numberof particles (originallysnowflakes) that would collectfor a certain amount of

Surreal Software’s DRAKAN: ORDER OF THE FLAME 34time on the mesh of anaffected object. After a time,the particles would fall tothe ground and stick for abit. All these properties,from the timings to the particletexture, are configurable.With this feature attheir disposal, the designerscreated glowing aurasaround ghosts by increasingthe particle size andmaking the stick-time infinite.They created snow thatlanded on invisible platformsto guide playersacross them. The snoweffect was attached toarrows to drop ice behindthem as they flew. All thisfrom a small bit of programming.Colored conceptual sketch of aWartok grunt.The engine also has an efficientcaching system, so it’sable to handle hundreds ofmegabytes of data on ourminimum system requirementof 32MB RAM. The two main characters,Rynn and Arokh, total more than 20MB of animations,plus 12MB of sounds (including ingamecut-scenes). To pull this off, the systemkeeps the most recently used sounds or animationsin the cache and can flush memory that ithasn’t used in a long time. Further reduction ofmemory usage is achieved by sharing animationsbetween characters with the same skeleton,even if they have completely different skins.The system only loads the data that it needs, asit needs it. This is importantduring development, as artistsand designers are proneto leave unused textures,sounds, and models in adatabase. The result is goodengine performance duringdevelopment, which is alsorepresentative of the finalproduct.We tried to ensure that theengine and tools always displayedto the artists anddesigners something thatwas representative of thefinal game (WYSIWYG).The best example of thiswas our real-time 3D editingsystem. The engine was integratedinto the editor, so anygeometry, texture mapping,or lighting changes made bythe designer would beimmediately reflected in the3D view. The importance ofthis aspect of the toolsshould be emphasizedbecause it gave the designers the ability to tunelevels and game play very quickly and with aminimum of guesswork.4. Compelling designA good design will not only sell a game—it canalso help smooth the development process. TheDRAKAN world has immense possibilities, sonew ideas were born easily within its scope. Thiskept the team highly motivated, as there were

35Section I: STARTUPS35always innovative things to do with the genre.The varied environments gave a wealth of newthings to work on for the art and design team,and were an ideal canvas for programmer invention.The design also kept Psygnosis very interested.DRAKAN became its top PC product, andit was comforting to us as developers to knowthat our publisher was behind the product.Psygnosis saw the marketing potential in abeautiful female character combined with afearsome, fire-breathing dragon and the presslatched on to the concept with excitement. Theycould market it to TOMB RAIDER fans, AD&Dfanatics, and even 3D shooter addicts.Even the most brilliant design would be difficultto implement lacking a proper design document.The 175-page DRAKAN design document containedoutlines for the entire game, including allAI behaviors, weapons, and level flows. Itserved its initial purpose well, and was a blueprintfor our lead designer’s vision. The documentwas vital to the development team,especially when it came to scheduling, creatingtasks, and communicating with the publisher.But as you will read in the following “WhatWent Wrong” section, feature creep overtookthe project halfway through, and the documentnever kept up with the changes. A design documentshould always be maintained throughoutdevelopment to preserve it as a useful resourcefor the team. Fortunately, the team could alwaysrely on Alan to explain anything or to fill in anyholes in the design document.5. Indoor/outdoor environmentsOne of the major technologies that set the Riotengine apart from the other landscape engineswas its ability to render both indoorand outdoor environments using thesame engine. The benefits to gameplay were huge because we could doarbitrary cave systems, arches, overhangs,and other structures thatwere perfect for a fantasy game. The“layer” system that the landscapewas created with was ideal for massiveoutdoor environments andallowed the designers to create veryorganic-looking worlds.Surreal’s in-house level editing tool showing the real-time3D editing window in the center and top-down layout viewin the upper-left.Rectilinear structures such as buildingsand objects were created usingarbitrary models imported fromexternal 3D modeling programs.

Surreal Software’s DRAKAN: ORDER OF THE FLAME 36Although these models were not included in thevisibility calculations, the layers were includedand were nicely suited for use in the visibilityculling of large environments. Because the layerswere small height fields that made up the ceilingsand floors of the surroundings, they tookup very little space in memory. This meant thatthe levels could be vast, and it helped give theplayer a sense that there was a living worldaround them.What Went Wrong1. Staying on scheduleDRAKAN was originally slated for release in February1999, but ended up being released sixmonths later. Even with careful scheduling andtask planning, we failed to meet the final deadlines.Part of the problem was that we didn’taccount for the time the teamwould spend creating versions ofthe game for E3 and for magazineand Internet demos. Eachdemo pulled nearly two weeks oftime away from our normallyscheduled tasks. The majority ofthe scheduling problems weredue to feature creep and otherimprovements that were considerednecessary during development.In March 1998, the design team was faced witha mountain of work ahead in order to completethe 14 original levels as designed. After carefulconsideration, the designers decided to spendtheir efforts on enlarging and improving uponthe ten best level designs. They also ended upcutting many features that did not show muchgame-play promise. The dart gun and the boomerangweapons were among those eliminatedfrom the game. Even though these tasks hadalready been mostly completed (in terms ofcode) for several months, they had not yet beenput into the game.By the end of the project, the designers did nothave adequate time left to work with programmersto play-balance those features, and the artstaff had not done any work on them either. Sothey got cut. The decision allowed us to focus onimproving the weapons that worked well, suchas the bows and arrows. We now know that it’scritical that programming tasks get put into thegame and tested almost immediately so that theireffectiveness can be realized early on. This lackof coordination between designers, artists, andprogrammers often caused problemsduring development. Someof this was because our designdocument wasn’t updated whenweapons, levels, or AI were redesigned.The initial AI programming followedthe original design document,but didn’t work well whenput into the game. It wasn’t untilour designers worked with the AIprogrammers to figure out exactly what theywanted for our combat system that the AI reallycame together. This kind of collaboration

37Section I: STARTUPS37should have occurred at the beginningof the AI programming processand the lack of it caused moderatedelays.DRAKAN’s art team often rebuiltgeometry and model textures,sometimes up to three times beforethey were satisfactory. This mayhave been partially due to Surreal’shigh aesthetic standards, but a lackof consistent artistic vision is also toblame. DRAKAN had lots of characterconceptual art, but no “artbible” to document all the modelsand environments for the game.This meant that if our art lead wasnot satisfied with work of anotherartist, he would often rebuild ithimself. At various points duringdevelopment his time was spreadthin across many different tasks. Inaddition, the art team went throughcommunication problems andpower struggles that hampered thecoordination of the team.2. Inadequate testingAlthough we tracked bugs internallybefore and during the alphaand beta releases, Psygnosis wasresponsible for the bulk of the testingafter alpha. For a game as vastand ambitious as DRAKAN, the timethat we allocated for testing was inadequate.Multiplayer and collision detection issues, inparticular, were not given enough testing time.Rynn’s highestpolygon count wasonly 538.When the final shipping dateapproached, we reluctantly agreedto allow some noncritical bugs toslip through to the gold master inthe interest of meeting the deadline.A patch was inevitable.Other testing complications addedto the problems. As Psygnosis wasbeing reorganized by its parentcompany, Sony Computer EntertainmentEurope (SCEE), half thetesting department was let go andmerged with SCEE’s U.K. testinggroup. This caused minor hiccupsin tester allocations to DRAKAN.Since the testing team was locatedin Europe, communication was difficult,and often messages weredelayed by a day or two. Bugreports were sent to us viaMicrosoft Excel worksheets, whichwere converted from an Oracledatabase that sat isolated on theirLAN in the U.K. Often the Excelworksheets would come to us corruptedor would have incompletebug descriptions. Bug responsesfrom Surreal’s programmers had tobe tracked carefully and enteredback into the Oracle database byhand.We kept our own internal databaseat Surreal using Outlook forms in special publicfolders on our Exchange Server. We ended upgenerating almost 1,000 internal design, art,and programming bugs during the entire

Surreal Software’s DRAKAN: ORDER OF THE FLAME 38project. This rivaled the number of bugs generatedby the testing team during alpha and beta.The internal system worked very well, but itcould have been more useful if the Psygnosistesters had access to the system as well. We triedgetting on-site testers, and some of the U.K.team did come to Surreal for about a week. Butit was too late in the project and for too short atime to be effective.3. Collision detection andresponseOne of the biggest chores for the testing teamwas to make sure that all of our hundreds of 3Dmodels could not be penetrated by missiles,NPCs, or Rynn. Each model had to be properlybounded by the artist during the model’s construction,a process which took about 20 percentof their modeling time to construct.Bounding was generated in our custom modelingtool and approximated the polygons of themodel using a hierarchy (tree) of boundingspheres or oriented bounding boxes (OBBs).This made the collision detection system veryfast and accurate, but it also meant that if anartist made a mistake in the bounding tree, collisiondetection might not work.To say this created a testing challenge would bean understatement. Even though the engine wascapable of rendering arbitrary meshes, the collisiondetection system was not designed to handlesome of the detailed meshes that the artistsproduced. Some of our AI used the boundinginformation at the lowest level, while Rynn’scollision response system used a polygon-accurateanalysis, which didn’t work perfectly forsome complex models. Frame-rate variationsacross machines also caused differing results,making it hard for programmers to reproducethe bugs and correct the problems. Finally, ourindoor/outdoor landscape system created somechallenging collision-detection problems that wehadn’t anticipated when it was originallydesigned.4. MultiplayerLighting effects created varying moods. Thisbridge model was reused from the islandslevel.Considered by some the Achilles’ heel of DRA-KAN, its multiplayer suffered from developmentalneglect. For the game’s multiplayer to havesucceeded, the design, art, and programmingteams would have had to spend at least twice asmuch time on it than they did. The two multiplayerdesigners did most of their level andweapon work during the alpha and beta periods.The same designers also created most of theartwork for the multiplayer effects and weapons.Any game-related bugs that came up werefixed by our single network programmer, who

39Section I: STARTUPS39already had his hands full optimizing the underlyingnetwork engine.Most of these game-related problems arosebecause the same weapons were used in bothsingle and multiplayer games, but the originalprogrammers were not careful to make them“network aware.” Originally, we thought thatDirectPlay was the easiest networking solutionfor us. But as the design got more complex, wefound that DirectPlay just did not work well forus. DirectPlay was a debugging nightmare. Thenetwork programmer’s machine crashed severaltimes per day when debugging the networkingcode and we couldn’t determine what was causingthat to happen. It wasn’t until we switchedto Winsock that we discovered that the crasheswere caused by DirectPlay.DirectPlay also caused a serious problem for uswhile we debugged the game under the firstrelease of Windows 98. DirectPlay actuallycaused the system clock to slow down. Thiscaused the game to run slower and sucked uptons of CPU cycles, forcing a reboot. When putto the test, DirectPlay also had issues with firewalls,which we were not able to resolve. Undercertain circumstances, the way DirectPlay handledthe message queues sometimes caused messagesto pile up until the application hung.Perhaps Microsoft will be addressing theseissues in future releases.It was clear even before alpha that the networkingcode would need to be rewritten. In the finaldesign, we only used the TCP/IP portion ofDirectPlay, and we used a Winsock front end tohandle communication with the master server.We proposed to Psygnosis that they give usmore time to convert the system over to Winsock,to which they replied yes—but only as adownloadable patch, since the additional workwould have delayed the game’s release. TheWinsock conversion was not finished until amonth after DRAKAN’s release, and greatly stabilizedthe multiplayer experience. This, combinedwith the release of the level editor and mods,has created a resurgence in multiplayer support,but it will never be as good as it could havebeen.5. Badly executed storyAlthough the overall story concept of DRAKANwas a great, the script and execution of the ideawere lacking. We hired a movie scriptwriter todo the initial work on the script, but he was notfamiliar with the fantasy genre and did not havea firm grasp on Alan’s vision for the design.From there, the script was edited and rewrittenby several more people: members of Surreal,members of Psygnosis, even one of the voiceactors. Under pressure to finish the script, it wascompleted with cheesy one-liners and otherbadly written dialog.Once it had been recorded by the voice actors, itwas very difficult to rerecord lines that werebadly written or acted. Some were re-recorded,but that was a luxury we could only afford forthe completely failed lines. The voice acting wasdifficult to get right, because just as some of thewriters had almost no vision of the game, thevoice actors likewise had little understanding ofthe characters they portrayed.

Surreal Software’s DRAKAN: ORDER OF THE FLAME 40Another problem with the executionof the story was that most ofthe construction of the cut-sceneswas left until the last minute, sinceall the levels had to be “geometrycomplete” before cut-scenes couldbe created. This meant that thescenes at the end of the game werehastily done, and some even had tobe cut from the game.Onward to theNext ProjectDRAKAN’s development was abumpy ride, but it went suitablywell considering it was the firstgame developed by an inexperiencedteam. Even with some of theschedule slips that occurred, thegreat design, art, and programmingkept the project going strong.DRAKAN has been a great learningexperience for the team, and thecareful evaluation of our past mistakeshas helped us in the developmentof our current projects.DRAKAN was recently named “PCGame of the Year” by several popularmagazines, and it has soldvery well. If DRAKAN showcaseswhat this team is capable of in ourfirst project, it will be very excitingto see what we are capable of inthe future.The DRAKAN team: FRONT ROW, FROM LEFT TO RIGHT: SatishBhatti (network programmer), Tim Ebling (programmer), ToddAndersen (designer), Susan Jessup (artist), Louise Smith(artist/animator), Andre Maguire (designer), Mel Guymon(lead animator), Tom Vykruta (programmer). MIDDLE ROW:Shaun Leach (programmer), Armen Levonian (programmer),John Whitmore (designer), Greg Alt (programmer), HeronPrior (animator), Tom Byrne (artist). BACK ROW: StuartDenman (lead programmer), Scott Cummings (animator),Boyd Post (sound engineer), Alan Patmore (lead designer),Hugh Jamieson (character artist), Mike Nichols (lead artist),Hans Piwenitzky (artist), John McWilliams (designer), NickRadovich (business/sound).NOT PICTURED: Joe Olson (artist), Duncan (designer), IsaacBarry (designer), Ben Olson (artist).

41Pseudo Interactive’sCEL DAMAGEby kevin barrett, john harley, rich hilmer,daniel posner, gary snyder, and david wuThe story behind CEL DAMAGE is long, winding,and harrowing, but ultimately uplifting. Andbecause CEL DAMAGE is our first published title,its story is also the story of our company,Pseudo Interactive. Based in Toronto, we beganwork on the technological core of the game fouryears ago. A demo of our driving-combat physicsengine at the Game Developers Conferencein 1997, PI’s first year of operations, received awarm reception. Shortly thereafter, PI struck upa relationship with Microsoft’s EntertainmentBusiness Unit (EBU). Over PI’s first two years,we started up and killed a few projects. However,with the coming of Xbox, we found aproper niche for our emerging technology.The physics engine that PI president and technologydirector David Wu was developing lentitself well to console applications. EBU recognizedthis, and an early alliance was formedbetween PI and the embryonic Xbox team. Ahigh-profile Microsoft producer came to PI witha vision of where PI needed to take its gametechnology, and a new project was born. At thattime, the project was called CARTOON MAYHEMand was primarily a car-based racing game withancillary gag and weapon features. As we struggledwith the demands of Microsoft’s vision forBack-StoryCEL DAMAGE achieves an ambitious vision—to set acombat driving game in a universe with the look andfeel of the golden age of cartoon violence. This feat isaccomplished through a fusion of artistic vision withtechnical expertise—a renderer that mimics the look ofcel animation and a cartoon physics engine that allowsmeshes to deform and bounce with the dynamicexpressiveness of Warner Brothers mayhem. A range ofentertaining cars and drivers contend in a variety deathmatch,capture-the-flag, and racing events. The actionhas an intuitive fast-paced arcade feel, and the range ofpowerups and characters give CEL DAMAGE depth andreplayability. CEL DAMAGE is notable as part of a trendone could call post-realism—a high-tech tour de forcewhose aim is not just to mimic reality but to create aworld with a particular feel and flavor.IP development, rendering, and weapon effects,we realized that the game engine, which was apatchwork of two years’ worth of divergingdemands and evolution, would need a completeoverhaul.For better or for worse, we undertook that overhaul.So it was that just as we were getting intoCARTOON MAYHEM’s development, our engine,and our ability to iterate content in playablebuilds, went down for over eight months. Thiswas a crucial time for Xbox and its first-party

Pseudo Interactive’s CEL DAMAGE 42developers. Microsoft was allocating itsresources to those teams with proven trackrecords and those showing steady progress. Wewere obviously lacking in both areas. Microsoftcut PI, along with our Xbox title, at the end of2000. Though this was a disheartening developmentfor us, by this time we had the gameGame DataRelease date: November 1, 2001Publisher: Electronic ArtsGenre: physics-based cartoon racing/combatPlatform: Microsoft XBoxNumber of full-time developers: 16Number of contractors: 12Estimated budget: $2 millionLength of development: 2 yearsDevelopment hardware used: 600MHz Pentium IIIswith 256MB RAM, 30GB hard drives, and NvidiaGeForce cardsDevelopment software used: Microsoft Visual Studio,3DS Max, Photoshop, Illustrator, Winamp, SourceSafeNotable technologies: pitaSim, Vtune, MicrosoftVisual C++Project size: 800,000 lines of codeengine back up and running, and we were suddenlyable to produce good demo levels. Itwasn’t long before we drew interest from severalother publishers. We had a quickly evolvingtechnology and a ton of assets ready to go. Thedemos we put together enabled us to land a newpublishing deal with Electronic Arts.Switching publishers allowed us to preparesome great new material, including an internallydeveloped IP, extra gameplay features, a newrenderer, and a new title: CEL DAMAGE. We realizedwe were going to make the Xbox launch,and we were going to do it with our own propertyand the backing of the world’s largest thirdpartypublisher. These three facts alone made allthe work of the previous several years worthwhile.What Went Right1. StaffingTwo years ago, when we started work on ourXbox title, we had a core group of about eightpeople. It was apparent that if we wanted todevelop a console game, whole cloth, in time forthe Xbox launch, we would need more staff inevery department. We hired more team membersas we progressed through development. Wewere fortunate in that we were able to find verytalented and motivated people who were alsoable to contribute to our corporate élan. Webrought our staff in from all over North America,and although none of us had console developmentexperience, each new member brought arich skill set to the company.The search and interview process for each teammember was exhaustive. We would often see acandidate two or three times before rejectinghim or her and moving on to someone else. Talentand experience were sought-after attributes,but not at the expense of team chemistry. In theend, our hiring methods were vindicated. Wewere able to create a group of friends who

43Section I: STARTUPS43enjoyed working with one another and weredeeply devoted to the project.Our approach to team communication wenthand in hand with our approach to staffing. Wefound that weekly full-staff meetings, individualweekly lectures or presentations to the entirestaff, and regular departmental reviews greatlyimproved all team members’ understanding ofhow their co-workers contributed to the project.We also held an ace up our sleeve. We formed astrategic alliance with a local technical collegethat offered a diploma course in 3D visual arts.Through the school, we instituted an internshipprogram in our art department. We integratedtop students into our team, which was a verysuccessful exercise that we will maintain duringour next project.Moral: Wait for the cream to rise, then scoopit off the top.2. Early development with XboxAs a new entrant in the highly competitive consolemarket, the Xbox group was looking forgame experiences that would make their consolestand out. As Microsoft pointed out so oftenduring the Xbox design period, “Great technologydoes not sell game systems, great games sellgame systems.” Picking up on that mantra, westarted our development when the console waslittle more than an optimistic dreamchampioned by a charismatic team ofvisionaries.Chief among them was their boldAdvanced Technology Group manager,Seamus Blackley. We were convertsto his ambitious plans for theXbox. With the promise of a stable,RAMpacked, hard-drive-enabledcomputational powerhouse, we wereconfident that we could deliver thebreakthrough game experience that Microsoftwas seeking.Our game grew and achieved its focus as theXbox did the same. Knowing that CEL DAMAGEwould be held to standards set by second-generationPlaystation 2 titles during the 2001 Christmasbuying season, we were spurred on toutilize whatever technology the Xbox team wasstuffing into the system. We believe that throughthis evolving relationship, we’ve managed tocreate an innovative and highly entertainingtitle. It’s also worth noting that CEL DAMAGEprobably would not exist today were it not forthe support and inspiration provided by Seamusand the rest of the Xbox team. They stood up

Pseudo Interactive’s CEL DAMAGE 44for our project and pushed as hard as any of usto make CEL DAMAGE a reality.Moral: It’s all about whom you know.3. Synchronization toolsPI grew a great deal over the course of theproject, and we knew it was important to keepeveryone synchronized. The increasing size ofthe team, combined with the growing mountainof content and code, made regular updates moredifficult and time consuming. The process ofcreating a build became a black art that onlyone or two people could do correctly.Although we implemented AutoBuild with lowtechWindows commands and utilities, this onebuttonsolution proved to be extremely valuable.Each build that the process generatedserved as the absolute point of reference for thecurrent code base. Even with six people workingsimultaneously on the same source code, wewere able to keep inconsistencies and problemsto a minimum.Another low-tech solution, MakeBuild, filledour largest gap in synchronization, though itsimplementation came quite late in the project.MakeBuild consisted of our source game content,automatically compiled into run-time formatby adding a few simple commands to theThe first step toward synchronizationcame fairly early on with the creation ofan automated code-compilation process,dubbed AutoBuild. We investigated a fewdifferent automated build programs, butnone was as flexible or complete as ahome-brewed batch file (or rather, a collectionof batch files and supplementaryprograms). Each night, or whenever necessary,AutoBuild could check out allsource code to a clean directory tree. Itthen built and executed any code generators,built all binaries, copied the outputto a shared directory, and generated an e-mail report containing a .ZIP file of allbuild output, along with a summary oferrors and warnings. Whenever convenient,our programmers could run anotherbatch file to synchronize completely.Early in development, CEL DAMAGE was morerace-themed. Here’s an early concept for aloop-the-loop road gag in the desert theme.game editor, and a few batch files. By automaticallyrunning MakeBuild after AutoBuild, wehad a brand-new build waiting for us eachmorning. Our daily build process kept artists

45Section I: STARTUPS45and QA staff up to date without bogging downany individual with responsibility for creatingthe builds. MakeBuild accelerated the feedbackcycle between content creation and gameplayreview.Of course, not all updates were visible in thebuild, and we made several other utilities to helpkeep everyone abreast of changes under thehood. Our CheckInReporter was a simpleVisual Basic program that scanned the Source-Safe database for all check-ins over the previous24 hours, and then created and e-mailed out anExcel spreadsheet report. These were especiallyhelpful in tracking down regressions. We createdanother simple VB program that e-mailedout active bug lists to each team member onceper day.Moral: Spending a few days creating simpletools pays big dividends throughout theproject.focus testing generated reams of data, whichwas boiled down to nearly 400 gameplay andasset recommendations. This information providedan important perspective on what peoplewere interpreting as fun and fair. This feedbackwas very valuable, since we’d lost all objectivitytoward the game and its difficulty level oncewe’d mastered the various weapons and gags.The bug-tracking software that our internal QAused for the duration of the project was calledPI_Raid. This tool, designed and customized inhouse,allowed us to stay on top of gamedefects, generate work items, and comment onevolving game features. We kept our bugs smalland focused. While this approach often left eachof us with a lot of bugs in our “bin,” we wereable to close out several per day, providing minimorale boosts throughout the project. Thoughsome of the bugs that we logged might havebeen considered trivial, cumulatively tacklingthem had a dramatic, positive effect on the gameand our level of polish.4. Internal bug tracking and QAWe made sure that our daily build process wasup and running before we built our internal QAdepartment. The daily build mentality wasinstrumental in the iterative process and wasQA’s greatest ally. New art and game logic assetscould be evaluated in-game within 24 hours oftheir creation, allowing broken assets and badfunctionality to be identified immediately.Asset pound-downs and targeted focus testingran concurrently as soon as we had four functionalgame levels. As development progressed,Moral: Get fresh eyeballs on your game andefficiently iterate gameplay.5. Coordinated scheduleOne of the pleasures of working on CEL DAM-AGE was the lack of a brutal crunch period inthe final weeks of development. We also feltthroughout the last year of the project that we’dbe able to realize our desired feature set. A goodschedule, coordinated with each department,helped us achieve this unique state. Our earlywork with Microsoft taught us the value of

Pseudo Interactive’s CEL DAMAGE 46adhering to a schedule, and after wemoved on from that relationship, wewere able to maintain, and evenimprove, our scheduling skills. Our guessis that badly maintained and poorlyenforced schedules are the primary causeof game projects missing their ship dates,dropping features, and winding up withmorale-busting, project-end crunch periods.Following are some schedule-relatedfactors that worked for us:Estimating task duration. No one canestimate with 100 percent accuracy.However, our leads and staff communicatedconstantly to refine delivery dateestimates. If an asset looked as though it wasgoing to run overtime, we would cut it or someof that person’s later deliverables, from theschedule. If such changes created holes in thegame’s design, we would be flexible and designaround the holes.Software. We used Microsoft Project. If you’veused it, you know it’s not great, but it gets thejob done. That was all we needed. Once we gotused to Project’s idiosyncrasies, it was smoothsailing to the end of development.Team-wide involvement. We periodicallyprinted the master schedule and posted it on awall where everyone could see it. This helped inmany ways. First, it demonstrated the interdependenceof the departments. Each staff membercould see that an asset he or she wasworking on was needed by someone in anotherdepartment. Second, missing items could beidentified more easily, since more eyes wereSome early desert environment renders made to testscale, detail, and color. Our tests included fog, vertexlighting, and gradations with the goal of evoking aclassic Warner Brothers style. These elements wereactually dropped as the vision of our own house stylecame into focus.looking at the schedule. Third, seeing the scheduleupdated gave people a strong sense of makingprogress. This progress contributed to teamconfidence and morale.Short, staggered crunches. We crunched, but wedid it early in small, manageable, prescribedintervals, giving us a buffer at the end of theproject, after our feature set was complete. Peoplewere then freed up to work on visualweapon enhancements and level polish. At theend of the project, the team was playing fullandsplit-screen CEL DAMAGE during and afterbusiness hours. This intense play period helpedidentify exploits and balance the gameplay. Thisdata wouldn’t have been available to us if wehad crunched long and hard at the end of theproject.Moral: The schedule is your friend. Never letfriends down.

47Section I: STARTUPS47What Went Wrong1. Design on the flyOnce we got our technology back online inDecember 2000, it began evolving very quickly.Feature sets for weapon and death effects, drivingbehaviors, gag functionality, and animationswere growing every day. Because we weredesigning a game to the technology (rather thanthe other way around), we were throwing outdesign documents as quickly as they could bewritten. Art assets had to be revised, retextured,discarded, and rebuilt from scratch severaltimes. As most readers will know from experience,this is a scenario for feature creep, obsoletetool sets, and blown deadlines.While we were able to nail down our feature setfour months before shipping, our evolvingengine did cause other problems. Essentially,our strategic preplanning was stillborn. Everyweek, we had to revise our perceptions of whatthe game would really be, which frustrated ourattempts to describe the game to prospectivepublishers at the beginning of 2001. Differentstaff members had different ideas of what ourgame would finally end up looking and playinglike.Fortunately, once publishers and press playedthe game for themselves, the core of CEL DAM-AGE’s identity as a cartoon-based vehicular combatgame became self-evident.Moral: It’s OK to design to an evolving technology,but institute hard cut-off dates forcode development and features.2. Asset tracking andimplementationOur initial efforts produced large amounts ofart content to show off the XBox’s power. However,evolving performance specs for the Xboxand our game engine, along with a new IP introducedearly in 2001, generated several massivecontent revisions. These revisions were necessaryfor level geometry, static world objects,gags, skyboxes, cars, characters,weapons—everything. In the worstcases, we saw at least 12 major revisionsto individual assets.A before and after shot using the desert theme’s GeneralStore. Cel-shading conventions were prototyped in 3DSMax using the Illustrate! plug-in.While we had an established directorystructure for storage at thebeginning of the project, new workflows,staff, and management methodsprecipitated a patchwork of filenamingconventions and trackingmethods. Final game meshes were

Pseudo Interactive’s CEL DAMAGE 48inadvertently overwrittenwith geometric primitives.We “lost” assetson the server for days ata time. Other trackingproblems cropped up aswell. A bug in our gameengine created duplicatetextures that were difficultto hunt down andeliminate. Also, we hada problem with texturerevisions that got wipedout on import to thegame editor. To compoundour headaches,objects were often usedin several different levels, but if an optimizationwas made to one, that change was not automaticallypropagated through all levels.Obviously, we needed a tool to track our artassets and their properties and to update contentin the game. We created the robust PI_Assetfor just such a use. Unfortunately, it was introducedtoo late in the project for full implementation.As a stopgap measure, artists begansending out dailies through e-mail. Thesereports proved useful in tracking what had beenaccomplished in the course of a day and whatshould be updated in the build, but data managementwas still a problem. PI_Raid showed usjust how many holes our pipeline had in it.While the primary purpose of PI_Raid was totrack and resolve bugs, the artists and levelbuilders found themselves using it as a means toprovide a pathway to updated content. ThroughPI_Raid, a person could know when an assethad been updated, whereit could be found, andwhat had changed in it.Using our bug reporterto track game assets wasnot an ideal solution, butit did serve us well in apinch.While the build-discardrebuildprocess hit ourstaff pretty hard, it createda sturdy springboardfor future assettrackingmethods, and italso reinforced a bettermentality for thoroughnessin our development procedures. Our nextproject will definitely see better tracking andimplementation methods.Moral: Don’t overwrite finished, texturedbuilding models with spheres.3. Single member over-taskingDue to our relatively small staff, we had to putmanagers in the critical path of day-to-day assetdelivery. These same people held crucial, uniqueskill sets. As you know, this is a recipe for bottlenecksthat hamper development. One exampleamong several was the role of our artdirector. We made this person responsible foroverseeing the game art, scheduling his staff’sworkweeks while developing their technicalexpertise, modeling, creating the game’s interface,producing our cut-scenes, overseeing

49Section I: STARTUPS49interns, and distributing hundreds of art bugs.The time needed for one person to do all thesethings just wasn’t available every day.Fortunately, we were able to create an art leadposition to handle the staff and bug tasks. However,not every instance of over-tasking could befixed by adding a new body. We had one textureartist, but three or four art staff members weregenerating meshes. Add to this the frequent discardingof textures and rebuilding of models,and the amount of work crossing the texturedesk became enormous. We also had a singlestaff member who was responsible for updatinglevel content every day. If you consider that onsome days we’d generate 100 updated assets,and each one had to be imported, adjusted, andhand-tweaked in the levels, you can gain anappreciation for the bottleneck occurring there.With so many items funneling through onemouse, the balance between efficiency andhuman error was highly stressed. Ultimately wedealt with the regressions that cropped up, butit’s clear that better integration tools for ournext project will help a lot.Moral: Spot bottlenecks early and divert thework as necessary.4. Last-minute implementationof crucial elementsOur inexperience in console game developmentcaught up with us about three months awayfrom the end of the project. For the better partof two years, we had spent all of our efforts ondeveloping in-game assets and gameplay. As ourdelivery date to EA came into focus, we realizedthat we still needed to get a fair bit of contentunderway, including a solid front-end interface,music, cut-scenes, voice acting, foley sound, andsound effects. Once we had our budget in place,we scrambled to pull together a stack of contracted,out-of-house assets.We drew up a shopping list that looked somethinglike this: 13 cut scene scripts and storyboards,12 pieces of in-game music, a themesong, interface music, 450 sound effects, 1,000lines of in-game dialogue and 200 lines of cutscene dialogue to be read by seven differentvoice actors, six minutes of foley sound and cutscene music, and six man-months of modelingand animation talent. We also realized weneeded a way to play back our cut-scenes in realtime through the game engine and renderer,even through these code elements were notdesigned to handle the task.We took on the interface and playback tasks inhouse,but farmed out everything else. Obviously,the work was finished on time, but toaccomplish this we had to divert the attention ofall of our in-house managers to get these itemsimplemented. Spillover bottlenecking wasunavoidable. Though we were ironing outimplementation bugs until the day we shipped,the quality of the talent and assets we were ableto find on short notice shone through in the finishedproduct.Moral: The last 5 percent of a game takes 50percent of the effort.

Pseudo Interactive’s CEL DAMAGE 505. Switching publishersAs we already mentioned, we switched to a newpublisher halfway through development. Goingfrom Microsoft to EA was a mixed blessing.While we were able to improve gameplay anddevelop our own IP, we lost both our financialbacking and our internal focus at a crucial timein the project. We were also forced to reinventall of our art assets to avoid an IP conflict withMicrosoft.However, what could have been a project-widemeltdown actually hardened our resolve to getCEL DAMAGE on store shelves. Once we realizedthat the CEL DAMAGE property would belong tous, and that our mistakes and successes wouldbe our own, the training wheels came off. Webecame more determined and professional. As arite of passage, this publishing switch mighthave been exactly what we needed. In the end,perseverance carried the day, and gettingdropped as a first-party title was a black eyefrom which we recovered.Moral: When life gives you lemons, startdrinking hard lemonade.Damage ControlNow that CEL DAMAGE is out the door, PI’s lastmonkey is off its back. We are published andmoving ahead. There is plenty for us to lookforward to now, not the least of which is CELDAMAGE 2. We are excited about the prospectsfor Xbox and hope to continue to exploit itsstrengths with network and team-based play inour next game. Fortunately, our experienceswith CEL DAMAGE have shown us where we canimprove our processes and strategic planning onour next venture.

51Nihilistic Software’sVAMPIRE:THE MASQUERADE—REDEMPTIONby robert huebnerWhen Nihilistic Software was founded in 1998,there were only two things we knew were certain.The first was that we wanted to form acompany with a small number of very experiencedgame developers. The second was that wewanted to make a killer role-playing game.Nihilistic got started without much fanfare, justa few phone calls and e-mails. After finishingwork on JEDI KNIGHT for LucasArts, the coreteam members had, for the most part, gone theirseparate ways and moved on to different teamsor different companies. About eight monthsafter JEDI KNIGHT shipped, various people onthe original team began to gravitate togetheragain, and eventually formed Nihilistic just afew exits down Highway 101 in Marin County,Calif., from our previous home.Having moved into our new offices and boltedtogether a dozen desks from Ikea, our firstproject was to build a 3D RPG based on WhiteWolf’s pen-and-paper franchise, Vampire: TheBack-StoryVAMPIRE: THE MASQUERADE—REDEMPTION successfullytranslates the popular paper-and-pencil role-playingsystem to the PC environment, bringing the lush, atmosphericOld-World mythos to digital life. Players take thepart of Christof Romuald, a Christian knight turned vampire,in a lavish, complex storyline spanning 800 years,from Eastern Europe to London. The game playsthrough combat and the use of various disciplines, specializedvampire powers of mind and body. VAMPIRE isnotable for its addition of Storyteller Mode, whichallows players to fashion and run their own multiplayercampaigns in the engine, just as in paper-and-pencilgaming, a move that prefigures games, such as NeverwinterNights, and might be a new direction for playerdrivencreativity.Masquerade. Before linking up with Activisionas our publisher, Nihilistic president RayGresko already had a rough design and storyprepared for an RPG with similar themes and adark, gothic feel. After Activision approachedus about using the White Wolf license, weadapted parts of this design to fit the World of

Nihilistic Software’s VAMPIRE: THE MASQUERADE— REDEMPTION 52Darkness universe presented in White Wolf’scollection of source books, and this became theinitial design for REDEMPTION.Game DataRelease date: June 2000Publisher: ActivisionGenre: 3 rd -person vampire role-playing gamePlatform: Hardware-accelerated PCFull-time developers: 12Contractors: 8Budget: $1.8 millionLength of development: 24 monthsHardware used: Intel and AMD PCs, Nvidia and 3dfx3D acceleratorsSoftware used: Alias|Wavefront Maya, Photoshop,QERadiant, Visual C++Technologies: 3D skinned characters, continuouslevel-of-detail, custom-built 3D engine, MP3 audiocompression, lip synchingLines of code: 300,000 for game, 66,000 lines of Javafor scripts.Because of our transition from first- and thirdpersonaction games to RPGs, we approachedour first design in some unique ways. Many featuresthat are taken for granted in action games,such as a rich true 3D environment, 3D characters,and the ability for users to make add-onsor modifications, were reflected in our projectproposal. We also adopted many conventions ofthe FPS genre such as free-form 3D environments,ubiquitous multiplayer support, and fastreal-time pacing. To this we added the aspects oftraditional role-playing games that we foundmost appealing: a mouse-driven point-and-clickinterface, character development, and a widevariety of characters, items, and environmentsfor exploration.Using the White Wolf license also meant thatour users would have high expectations in termsof story, plot, and dialogue for the game. It’s arole-playing license based heavily around dramaticstorytelling, intense political struggles,and personal interaction. Fans of the licensewould not accept a game that was mere statbuildingand gold-collecting.In keeping with our basic philosophy, we builtup a staff of 12 people over the course of theproject’s 24-month development cycle. The budgetfor the game was fairly modest by today’sstandards, about $1.8 million. The budget wasintentionally kept low for the benefit of bothNihilistic and our publisher. We wanted our firstproject to be simple and manageable, ratherthan compounding the complexities of starting acompany by doing a huge first project. Also, wewere looking to maximize the potential benefitsif the game proved successful. For its part,Activision was new to the RPG market and wastesting the waters with RPGs and the WhiteWolf license in particular, so they probably consideredthe venture fairly high risk as well.Development started around April 1998. Whenwe began, we examined several engine technologiesavailable, such as the Unreal engine and theQuake engine, but ultimately decided againstlicensing our engine technology. The game weenvisioned, using a mouse-driven, point-andclickinterface, had a lot more in common with

53Section I: STARTUPS53games such as STARCRAFT than even the bestfirst-person engines. We decided to create a newengine focused specifically on the type of gamewe wanted to create, and targeted 3D-acceleratedhardware specifically—bypassing the tremendousamount of work required to supportnonaccelerated PCs in a 3D engine. As an addedbenefit, the company would own the technologyinternally, allowing us to reuse the code basefreely for future projects or license it to otherdevelopers.What Went Rightart, and save the company money by licensing asingle, relatively inexpensive tool.Thankfully, however, our leads in these areasstrongly objected to this plan. They argued forallowing each department to use the tools thatallowed them to do their work most efficiently.This single decision probably accounted formore time saved than any other. The leveldesigners cited QERadiant as their tool ofchoice, since most of them had previously donework with id Software on QUAKE missionpacks. id was generous in allowing us to licensethe QERadiant source code and modify it tomake a tool customized to our 3D RPG environments.1. Letting the artists anddesigners pick their toolsWith such a small team and tight budget, boostingthe team’s efficiency was our primary focus.If bad tools or art paths slowed down progress inthe art or level designdepartments, we wouldhave no chance of hittingour milestones. When westarted to map the developmentproject, the programmersgravitatedtoward using a packagesuch as 3D Studio Maxfor both art and leveldesign. Our argumentwas that doing everythingin a single package wouldincrease portability ofassets between levels andLocations included both interior andexterior cityscapes, allowing dramaticsituations such as this battle atop a clocktower in medieval Prague.Because QERadiant was a finished, functionaltool even before we wrote our own export module,the level designers were able to create levelsfor the game immediately, even before an engineexisted. And since QERadiant stores its data ingeneric files that store brush positions, the levelswere easily tweaked andre-exported as the enginebegan to take shape. Ifthe level designers hadspent the first six monthsof the project waiting forthe programmers to createa level editing tool orlearning how to createlevels in a 3D art tool, wewould not have been ableto complete the morethan 100 level environmentsin 24 months withjust three designers.

Nihilistic Software’s VAMPIRE: THE MASQUERADE— REDEMPTION 54On the art side, lead artist Maarten Kraaijvangerlobbied hard for the adoption ofAlias|Wavefront tools for 3D art. We tried toconvince him that a less expensive tool wouldwork just as well, but in the end we decided toallow the art department to use what they feltwould be the most efficient tool for the job.Since Maya was just being released for WindowsNT at that time, the costs of using thattoolset were not as great as we feared, and itallowed the artists the produce an incrediblenumber of 3D art assets for the project. Duringthe 24 months of the project, an art departmentof four people produced nearly 1,500 texturedmodels, a mind-boggling figure using any tool.2. Small team,one project, oneroomWhen we started Nihilistic,we had a theorythat a small number ofhighly experienceddevelopers would beable to produce a titlemore efficiently than alarger team with fewerbattle scars. In myexperience, successfullydelivering a gameis less about what youdo and more aboutwhat you choose not todo. Most games that ship late do so because thedevelopment team went down one or more“blind alleys”—development ideas or strategiesthat for whatever reason didn’t pan out, and theA set of four interactive 3D head models atthe bottom of the screen are skinned andanimated in real time to give lifelike status foreach party member.work done in that direction is lost. As a smallteam on a tight budget, we could not afford tolose valuable time on these diversions. Experiencedteam members have the wisdom to lookdown a particular path and recognize when it’sa likely dead end.We also knew that we wanted an office environmentwhere all the team members were in a singleroom without any walls, doors, or officeswhatsoever. This didn’t really seem like a radicaldecision—many of us got our start working forteams that operated like this—but it seems likethese sorts of companies are becoming less andless common in today’s industry. My first gamejob was working at Parallax (now Volition) software.We were eightpeople sitting along onewall of a narrow officespace in Champaign,Ill. Even the originalDARK FORCES developmentteam was sequesteredin a one-roomstudio in a buildingseparate from most ofthe other LucasArtsteams.This type of environmentdoesn’t just foster,but rather forces communicationbetween allparts of the team. Forinstance, a programmercan overhear a discussion between two artistsabout how to proceed with something and beable to jump in with an answer that will save theproject days or months of work. This sort of

55Section I: STARTUPS55thing happens on a daily basis; artists correctmissteps by the technology team before they aremade, a level designer can immediately show abug to a programmer, and so on. Each of theseincidents represents hours or days of projecttime saved. In an office environment with wallsand doors, most of these situations would gounnoticed or unaddressed.3. Using Java as a scriptingengineWe knew from the start that allowing the usercommunity to edit the game was an importantpart of the design. After working in the first-personaction-game market, we saw the benefits ofsupporting the user communityand wanted to carry this ideaover into role-playing games,where it is not the norm. Abuilt-in scripting system makesa game engine much moreextendable by fans. In JEDIKNIGHT, we created our owncustomized game languagecalled COG. Creating COGtook a lot of effort from thedevelopment team; severalmonths of work went into creatingthe compiler, testing thegenerated code, and implementingthe runtime kernelused to execute the scripts. Theend result was worth it, but itcost a lot in terms of time andresources to pull it off.Professional conceptual art,such as this rendering ofAlessandro Giovanni bycontractor Patrick Lambert,helped the characters evolveas the art design took shape.When starting VAMPIRE, we looked for ways toincorporate a scripting engine more easily thancreating our own from scratch yet again. Therewere several scripting systems we examined andtested. At about that time, another game developmentcompany, Rebel Boat Rocker software,was getting a lot of attention for its use of Javatechnology. After exchanging a few e-mails withlead programmer Billy Zelsnak, we decided togive Java a try. Up to this point I knew very littleof Java, and had largely dismissed it as a languagesuitable only for making icons dance on aweb page and the like.After a crash course in Java, we did a few simpletests incorporating it into our game engine. Itpassed each one with flying colors.In a matter of a few weeks,we had solved the major challengesinvolved in interfacing astandard, freely distributableJava virtual machine to our 3DRPG engine. From that pointon, the only maintenancerequired was to add new nativefunctions to the scripting language,which we did wheneverwe added new engine functionalitythat we wanted exposed tothe script writers.We also trained several designersin the use of the scriptinglanguage, and they started creatingthe hundreds of small scriptsthat would eventually drive thestoryline of the game. Ever sincethose initial tests, I kept waiting

Nihilistic Software’s VAMPIRE: THE MASQUERADE— REDEMPTION 56for the other shoe to drop, so to speak. Iexpected to come to work one day and find outthat the Java thread was chewing up 100MB ofRAM or eating 50 percent of the CPU time, butamazingly, the system was trouble-free throughoutdevelopment and never became a significantresource drain. If for some reason we had hit adead end with the Java system late in the project,it would have easily taken three to four monthsto get back on track using a different scriptingtechnology. In the end, the gamble paid off. Wesaved months of programmer time that wouldhave otherwise been devoted to creating a scriptingenvironment, and the result was a system significantlymore efficient and robust than any wecould have created ourselves.4. Storyteller modeThroughout the project, the design slowly tookshape through a series of meetings that involvedthe entire staff. Each new design element waspresented to the group and subjected to a (sometimesheated) discussion. This process of opendiscussion and free exchange of ideas resulted ina lot of the most interesting design aspects of thegame. It was in one of our earliest design meetingsthat we came up with the idea of developingthe multiplayer aspect of the game not as atypical deathmatch or cooperative system, butrather to create a “storyteller” or “dungeonmaster”system. The idea was inspired by thevenerable text-based multi-user dungeon(MUD) games that date from a calmer time inthe history of the Internet.Many of us at Nihilistic had played MUDs incollege, often to the detriment of our studies.One thing that made MUDs so appealing wasthe ability for “wizards,” high-ranking users ofthe MUDs, to manipulate the game environmentand create virtual adventures for the players inreal time. The Vampire license from White Wolfemphasizes the role of the “storyteller,” or moderator,so we felt the time was right to take thisstyle of play out of the college computer lab andinto a commercial RPG. Implementing the storytellersystem turned out to be fairly simplefrom a technology standpoint. Most of the basicfunctionality for a storyteller game is identicalto what would be required in a traditional client/servermultiplayer game.The added cost was mostly in the area of designand the user interface. It took a bit of experimentationand redesign to arrive at an interfacethat was powerful enough to run games as a storytellerwithout being overly confusing to thenovice player. The UI work included new interfacepanels with lists of objects, actors, andother resources, and a few buttons to manipulatethe selected resources. Our overall designgoal for the user interface was to ensure that

57Section I: STARTUPS57important functionality was accessible usingonly the mouse, and all keyboard functionalityrepresented only “advanced” controls such ashotkeys and shortcuts. Even though the storytellersystem is something used primarily byadvanced players, we wanted to preserve thisdesign goal, which meant quite a bit of extra UIwork to make a mouse-driven interface powerfulenough to drive astoryteller game.In the end, the storytellerfeature ended upbeing one of the gemsof the game design, andresonated with both thepress and gamers alike.Activision made gooduse of the feature intheir PR and marketingcampaigns, and wehope the expandabilityand storyteller aspectsof the game will givethe game an increasedshelf life.5. Using experiencedcontractorsOne problem with our strategy of using a smallcore team is that we couldn’t possibly cover allthe aspects of designing a commercial gamewith just 12 people. Instead, we relied heavilyon external contractors for certain key aspectsof the game. Sound was one area where wemade use of external talent. Our colleaguesfrom LucasArts referred Nick Peck to us, basedThe ambitious design included parties of upto four 3D characters, each withinterchangeable weapons and armor.on his excellent work on Tim Schafer’s GRIMFANDANGO. Nick ended up not only supplyingus with sound effects, but also working on someof the additional voice recording and ambientloops. For our music, we teamed up with KevinManthei who scored the Dark Ages portion ofthe game, and with Youth Engine, a local duo,for the modern-day tracks.Even in the conceptualstages, we used externalartists to help us sketchand visualize the game.Peter Chan was thelead conceptual artistfor JEDI KNIGHT andhad subsequentlybecome an independentcontractor. Hiswork in the firstmonths of the projectwas key in establishingthe look of the game’senvironments. We alsoworked with PatrickLambert for character concepts and he deliveredincredibly detailed full-color drawings thatreally brought the characters to life for the modelersand animators.Perhaps the most critical external relationshipwas with Oholoko, a small startup spun offfrom Cyclone Studios. We hired them to do ourcinematic sequences that introduce the storyand provide the endings. While starting theproject, we met with several firms specializingin computer animation, but pretty much acrossthe board their rates were well beyond our

Nihilistic Software’s VAMPIRE: THE MASQUERADE— REDEMPTION 58budgets for that partof the game. Itseems that the highdemand for computeranimationfrom movies andtelevision has driventhe larger firms’prices beyond thereach of typicalgame budgets. Byworking with asmaller, less establishedcompany, wewere able to getmore bang for ourbuck in our cinematics,and the resultsproved to be of thehighest quality.What Went Wrong1. Overly ambitious designIn retrospect, we were in some ways our ownworst enemy. Many of the team members hadwanted for some time to do a really huge,ambitious role-playing game. When we actuallystarted the project and had a budget andschedule, we probably weren’t realistic abouthow long RPGs typically take to develop, especiallyone that travels to four different citiesacross an 800-year timeframe. We were veryreluctant to make big cuts in the design, suchas cutting one of the two time periods orAll of the more than 100 3D characters, such asLucretia, a Setite priestess, were modeled andanimated by hand by a team of four artists usingMaya.removing the multiplayeraspect.Because of this, weeventually had tomake the decision tomiss our first scheduledrelease date ofMarch 2000. Wealso cut back on ourplans to release aninteractive demosome months beforethe game and scaledback the scope ofthe multiplayer beta.Fortunately,expanding the schedulea few months(from March toJune), we were ableto preserve almostall the elements from the initial design. But toaccomplish this, the art and design departmentsreally had to work above and beyond the call ofduty for an extended period of time. We did cutback a bit in the area of multiplayer by removingthe ability to play through the entire singleplayerscenario cooperatively as a team, andinstead replaced that with two smaller, custommademultiplayer scenarios using levels and artfrom the single-player game.Part of this was because we did not plan properlyfor multiplayer when making some of theJava scripts that drive the single-player game. Ifthe multiplayer game had been functional earlierin the schedule, the single-player game scriptsby

59Section I: STARTUPS59might have been written from the start to be“multiplayer friendly” and we could haveshipped more multiplayer content in the box.2. Prototyping with a proprietaryAPIWhen we started developing the 3D engine forthe game, which we named Nod, the 3D APIlandscape was quite a bit different from how itis now. We decided to use Glide as an initial prototypingAPI with the belief that it would be amore stable platform and avoid the complexitiesof supporting multiple hardware through amore general API until we had solidified theengine a bit. However, once we had a basic,functional engine running under Glide, the programmers’attentions turned toward game playand functionality rather than switching thegraphics engine to a more general API such asDirect3D or OpenGL. Because of this “if it ain’tbroke” mindset, we expanded our supportbeyond Glide fairly late in development. At thefirst public showing of the game at E3 in 1999,we were still basically a Glide-only game, whichmeant we couldn’t demonstrate the game in 32-bit modes or support some features not presentin Glide at the time.The extensive use of Glide also gave us someunrealistic performance estimates for otherhardware. Since Glide allows low-level access tothings like texture-memory management, wespent significant time writing our own optimizedtexture manager. When we switched toDirect3D, most of this work had to be discarded.Since Glide allows more flexible vertexformats than Direct3D, some of our underlyingdata structures needed to be changed, whichmeant re-exporting hundreds of levels and models.We were making low-level architecturalengine changes at a stage when the engineshould have been pretty much locked down.Also, because we switched late in our developmentschedule, we probably didn’t spend asmuch time as we should have on compatibilitytesting with a wide variety of hardware. In retrospect,we should have switched to Direct3Dor OpenGL several months earlier in the developmentschedule.3. Pathfinding difficultiesOne problem we identified early in the developmentprocess was the problem of pathfinding.Navigation of variably-sized characters througha completely free-form 3D environment is oneof the most difficult problems I’ve had to tackleas a game programmer. Unit navigation is hardenough when you have a flat 2D plane orrestricted 3D environment, but in an environmentwhere the level designers are free to makestairs, ramps, or any other 3D construct you canimagine, the problem becomes exponentiallymore difficult.My natural tendency when presented with sucha sticky problem is, unfortunately, to make itgood enough for the early milestone and demobuilds, and then just “deal with it later.” Unfortunately,“later” quickly became “now,” and“now” turned into “yesterday.” We should havetackled this problem much earlier, before thelevels were near completion. We should haveworked with the level designers to come up with

Nihilistic Software’s VAMPIRE: THE MASQUERADE— REDEMPTION 60a set of restrictions for their levels, or someadditional tagging in the editor to specify to theengine where characters should and should notmove. Instead, the only hints from the leveldesigntool were “walkable” floor flags, but littleor no special marking of walls, cliffs, andother pathing hazards.Since we waited too long to address the problem,better solutions such as walk boxes or walkzones would have taken too long to retrofit intothe more than 100 levels already in the can.Instead, we spent weeks making small iterativefixes to the system to hide the most extremeerrors and turn what was an “A” bug into a “B”or “C” level problem.4. Feature and data timingThis is a fairly common problem in games I’veworked on, and VAMPIRE was no different. Thetechnology team typically looks at the developmentschedule and schedules that entire block oftime to achieve a certain feature set. Often,however, new engine features get added too latein the schedule to be utilized fully by the designersand artists.This happened several times during VAMPIRE.Some of the more interesting special effects, forexample, were added only a few weeks beforethe data was to be locked down for final testing.Other features that we added couldn’t even beimplemented extensively. For example, we addeda more flexible shader language so late that onlyone to two percent of the surfaces in the gamewere able to take advantage of it. Some featuresthat we had originally planned for the engine,like bump mapping and specular lighting, werecut completely from the initial release becausethere was insufficient time both to complete thefeature and to create art to drive it.We softened the blow somewhat by movingsome of these features to a planned patch, whichwould add them later if the game proved successful.Unfortunately there are very few programmingtasks that don’t require some sort ofartist or designer input to find their way into thefinished product, so unless programmers spendthe last six months of the project doing nothingbut fixing bugs, some of this is inevitable. Wecan justify it to a degree by looking toward thelikely sequel or add-on projects as a way to takeadvantage of some of the engine work that wasunderutilized in the original title.5. Self-restraintAs the project was drawing to a close, we foundthat we ended up with a bit “too much game,”as someone put it. From the start, we decided toauthor our data for a high end platform, sowe’d have a good-looking game at the end ofthe 24-month schedule, and also because it’smuch easier to scale art down than up. Unfortunately,we never really started to rein in our artand design teams when we should have near themiddle of the project. Instead, we continued toadd more and more resources to the project,resulting in a minimum installation footprint ofabout 1GB.We authored all our textures in 32-bit color andthen scaled them down at load time for 16-bitcards. Our models were also extremely detailed

61Section I: STARTUPS61(1,000 to 2,000 triangles each,on average) and relied on automaticlevel-of-detail algorithmsto scale them down for slowermachines. We lit our levelswith relatively high light-mapresolutions. All of this madethe game look great on highendsystems but it meant thegame was fairly taxing on lowtomidrange systems.In the end, the game just barelyfit on two CD-ROMs. We hadoriginally planned to includeboth 16-bit and 32-bit versionsof the game textures and allowplayers to choose which versionto install, but after all theart was completed there wasno room on the CD for morethan one version. Likewise forsounds: we wanted to includemultiple quality levels butspace prevented this. We actuallycompressed most of thevoice samples with MP3 and had to remove severalsounds from the game in order to fit it ontwo CDs.In the end, our game looked gorgeous but haddifficulty running on machines with less than128MB of RAM—and even then, it used a fairamount of space on a swap drive. This glut ofresources will also make it more difficult if wechoose to port the game to a more limited consoleenvironment.Characters were created witha budget of between 1,000 and3,000 triangles. Bosscharacters, such as Ahzra theTzimisce Elder were generallythe most complex.At Last,RedemptionFor the first project from a newdevelopment startup, I can’timagine how things could havegone much better than theydid, except perhaps if we couldhave avoided shipping it thesame year as DIABLO II. As acompany, we managed toaccomplish the three mostimportant things in this business:not running out ofmoney, not losing any teammembers, and actually shippingthe product. Our publisherremained committed tothe project throughout its lifecycle, and even increased theirsupport as the project continuedto take shape.The course of developmentwas amazingly smooth, withvery few surprises or conflicts along the way. Inthis industry, you can almost bet that at somepoint in a two-year development cycle somethingtraumatic will happen to either the developmentteam or its publisher, but for us thewaters were remarkably calm. About the mostexciting thing to happen during developmentwas when we lost our entire RAID server whileattempting to add drivers to it, resulting in theloss of a few months’ worth of archived e-mails.Our good fortune allowed the team to focusstrictly on the game and prevented distractions

Nihilistic Software’s VAMPIRE: THE MASQUERADE— REDEMPTION 62from outside the company. Also, keeping ourcompany focused on just one title and resistingthe frequent temptation to take on more workand more staff allowed everyone to be on thesame team with little or no secondary distractions.Hopefully, by avoiding feature creep anda four-year “death march” kind of ending tothis saga, we can avoid a lot of the burnout thatwe have seen and often experienced on otherteams. By maintaining links with both the fancommunity through our web board, and withthe developer community at large by attendingshows like GDC, E3, and Siggraph, our teamwas able to keep a positive attitude and highenergy level throughout the schedule. Weremain convinced that small development teamswith a single-title focus are the best way to shipquality titles consistently, so our plans movingforward are to staff up gradually from 12 toperhaps 16 people over the next few monthsand embark on our next two-year ordeal a littleolder, a little wiser, and just a tiny bit larger.

63Ensemble’sAGE OF EMPIRESby matt pritchardI had an experience in a local computer storerecently that caused me to burst out laughing. Ihad stopped to self-indulgently admire the top-10 PC games display when I overheard the followingexchange between two young men:“What do you think about this one, AGE OFEMPIRES?” wondered the first.His companion shot back, “Aww, the Borg atMicrosoft just combined WARCRAFT and CIVILI-ZATION to cash in on these kind of games.”Always eager to boost our sales, I took thisopportunity to tell the young men how AOEwasn’t the creative product of a giant corporation,but of a small group of talented people livingright in their own backyard. For us, AGE OFEMPIRES was not only a game of epic proportions,it was an epic journey for a small band ofpeople determined to turn an idea into a realgame company. Along the way, we laughed, wecried, we consumed pizza and caffeine, and welearned a great deal about making games.Back-StoryAGE OF EMPIRES gives a real-time-strategy treatment toearly world history, from 5000 BC to 800 AD, in whatmany see as the real-time update to the classic CIVILIZA-TION. Players choose one of the major ancient peoples(each with their own characteristic strengths and weaknesses)and bring their nation from Stone-Age squalorup the cultural-technological ladder to the sprawlingsplendor of the empires of antiquity. The action unfoldsin real time—players harvest grain, conduct diplomacy,marshal troops from the genre's godlike perspective,watching their shining white cities unfold across jewelgreenlandscapes. Strong play balance and beautifulpresentation have made this game a pillar of the genre.Designing the PastPerfectObviously, AGE OF EMPIRES didn’t start outlooking like the final product. Despite someaccusations, DAWN OF MAN (AOE’s originaltitle) wasn’t created to be a WARCRAFT II clone.(In fact, WARCRAFT II wasn’t released until afterAOE’s development was well underway.)Instead, the final design was evolved and refinedover time, with a few significant design eventsalong the way. One of the best things I thinkyou can have in a game company is a staff thatplays a lot of different games. This was true ofour staff at Ensemble, and was helped in no

Ensemble’s AGE OF EMPIRES 64small part by programmer Tim Deen’s habit ofbuying and actually playing almost every newPC game as it came out.It was Tim who brought WARCRAFT II to theattention of the rest of the Ensemble staff. AtGame DataRelease Date: 1997Publisher: MicrosoftGenre: StrategyPlatform: Windows 95 & Macintoshthat time, many of AOE’s game elements, suchas resource management, empire building, andtechnology research, were taking clear shape.However, we didn’t really know what to doabout combat. WARCRAFT II was a splash ofcold water in the face, waking us up to howmuch fun real-time combat could be. Severaltimes a week, the staff would stay late to playmultiplayer WARCRAFT. These impromptuevents continued until AOE reached the point indevelopment when it became more fun to playthan WARCRAFT.Another major shift occurred a little over halfwaythrough development, when the designerswere looking at AOE’s localization plans. Theyrealized that AOE would be sold in Asia, butdidn’t include a single culture from that region.We held a company-wide meeting and decidedto add early Asian civilizations to the earlyEuropean, African, and Middle-Eastern tribesthat we’d already developed. Though the additionwould create more work for the artists anddesigners, the enhanced appeal that the gamewould have in Asia would make this a profitabledecision.All of these changes occurred because the game’sdesigners weren’t afraid of taking design inputfrom the rest of the staff. Making a game thateveryone would be proud of and would want toplay was something that got more than just lipservice at Ensemble.Perhaps the best example of this core value isthe Wonder, the penultimate building that aplayer can build and use to win the game. Inearly 1997, AOE was great for slugfests, buteveryone felt that the game play needed to offersomething more. Numerous ideas were triedand rejected. Then Mark Terrano, our communicationsprogrammer, hit upon the idea ofbuilding an “Armageddon Clock” that wouldforce players to drop what they’re doing andrespond to the new challenge. AOE is chock fullof little ideas and touches that were thought upby the artists and programmers. This participationtangibly increased the sense of ownershipand pride that we all took in the game.One of things that is truly underappreciatedabout the designer’s job is play balancing. Thedesigners spent months and months adjustingcosts, strength, speed, and many other statisticsin an effort to create a game that was fun toplay and yet didn’t offer any loopholes orcheats. At this point, I realized that Tim Deenwas truly a gamer’s gamer. During development,if any of the various iterations of AOE’s designopened up a way for one player to take advantageof another player and thus make the game

65Section I: STARTUPS65one-dimensional, Tim would find it. And whenwe didn’t believe his assessments, he wouldpromptly show us by using the loophole to kickour butts at the game. For the better part of ayear, play balancing was a prominent task, andit paid off in giving AOE more staying powerand better game play than many others in therecent crop of real-time strategy games.required, was done before the computer AI wascompleted, and was based on the data flowmodel taken from human players. As a result, weinitially missed the fact that computer playerswould sometimes issue large numbers of commandsin quick bursts. We did, however, addressthis oversight with the first patch. An area whereAOE’s communications worked out better thanBlazing theMultiplayer PathMultiplayer support was an integralpart of the early design, and AOE wasstructured in such a way that most ofthe game could not differentiatebetween human and computer players.When DirectX first came out, itappeared that DirectPlay would be thebest choice for providing communicationsover the widest variety of connectiontypes. To support a high number of movingunits, we went with a modified game synchronousmodel, where the entire game is simultaneouslyrun on all machines. Only moves,changes, and commands are communicated toother machines. This approach has the advantageof minimizing the amount of data that hasto be sent. The unanticipated danger of usingthis model is that it can generate a conditionwhere the game on one machine becomes out ofsync with the game on other machines.This caused some very hard-to-reproduce bugswith AOE. Load metering, the process of determininghow much bandwidth the game updatesAll of the 2D sprites in AOE began life as 3D models.expected was the game’s ability to dynamicallyadapt to latency. A sliding window delays theactual game time when a command takes effect,so that all players receive the command and donot have to pause before executing it.The problem of handling players who havedropped from a game presented Mark Terranowith difficult challenges. Since drops are unpredictable,usually there is no way to know whathappened. The problem could be the gamelogic, Winsock, the physical connection, or theISP, and could exist on either the sender’s orreceiver’s side. Getting the game to handle dropsby anyone at anytime required a great deal ofwork.

Ensemble’s AGE OF EMPIRES 66One of the lessons learned from the multiplayerexperience was to make full use of communicationstesting tools, such as automated logs andchecksums. Also, we discovered that creating asimple communications data flow simulatorprogram can provide great benefits and isolatethe communications code from the rest of thegame.DirectPlay also turned out to be problematical.Difficult-to-reproduce bugs, quirky behavior,and poor documentation made the going moredifficult. Guaranteed packet delivery for IPXwas one of the more notable examples. At theCGDC, Microsoft promised to deliver this featurewith DirectX 5 and even included in thebeta. However, when DirectX was actuallyreleased, this feature was nowhere to be found.The cost of that one missing item was the extratime we had to spend writing our own guaranteeddelivery system and a bad packet generatorprogram with which to test it.Painting the SceneAGE OF EMPIRES contains 20MB of in-gamesprite graphics. Even though all of the displaysare 2D, we decided early on that all of thegraphics in the game would be taken from 3Dmodels. We used 3D Studio and 3D StudioMAX for art production. Because 3D renderingis so time-consuming, each artist was issued twomachines each, both usually 200MHz PentiumPros with 128MB of RAM, which at the timewas better equipment than the programmerswere using. The objects in the game were createdas 3D models that had anywhere from acouple thousand to 100,000 polygons. Themodels were then textured, animated, and renderedout to a .FLC (Autodesk Animator) filewith a fixed 256-color palette.So far, the process I’ve described is identical tothat of many other games. At this point, however,the artists added another time-consumingstep. The .FLC files were handed off to a 2Dspecialist, who took the animation apart frameby frame and “cleaned up” each image withPhotoshop. The clean-up process involvedsharpening detail and smoothing the edges ofthe irregular shapes. Since most of the sprites inAOE had screen dimensions of only 20 to 100pixels in each direction, the visual qualityimprovement that we realized was significant.When AOE was shown at the 1997 E3, the artistsreceived numerous compliments on theirwork from their peers at other companies.The choice to go with 3D models for the ingameobjects provided benefits for other artneeds, as they were readily available for use inthe static background scenes that appear on themenu, status screens, and the various cinematics.The cinematics, including the three-minuteopener, were a fulltime project unto themselves.The 256-color palette (actually 236) used inAOE was something of a problem. The palettewas chosen and set in stone at the very beginningof the project, before most of the modelsand textures had been created. As a result, itturned out that some portions of the color spectrum,such as browns for wood textures, hadtoo few available colors to get the best visualquality.

67Section I: STARTUPS67The palette wasn’t revisedduring the development processbecause that would haverequired rerendering andtouching up every image inthe game—far too expensivetime-wise. On the otherhand, the palette did have awide and balanced range ofcolors, which contributed tothe overall bright and cheerfullook of the game’s graphics.If we do another 8-bitcolor game, we’ll generatethe palette at a point furtheralong in the developmentprocess.Going forSpeedPerformance is an issue forall but the simplest of games,and it certainly was for AOE.When I joined Ensemble, thegame was still in an early form and slow. Thetwo biggest problems were the graphics engine(which was just plain slow) and various updateprocedures, which produced occasional pausesof up to a second in game play. If we were goingto sell to anything but the most cutting-edge systems,some serious optimization was in order.Early Asian civilizations had to beadded when Microsoftannounced plans to distributeAOE in Asia.would rise to over 220,000lines before it was finished).After spending a few weeksstudying what we had, I proposeda major overhaul ofthe graphics engine structure,including writing a majorportion in assembly. AOE’soriginal design team asked ifthe frame rate of a benchmarkscenario could beraised from its current 7–12fps to 20 fps. I told them yes.Inside I was sweating bullets,hoping that I could deliverthat much improvement.I couldn’t just go ahead andrip out the old graphicsengine, as it would hold upeveryone else, so I spent thenext five months workingmostly on the new engine.Along the way, I managedsome incremental improvementsthat upped the framerate to 10–14 fps, but the big breakthroughcame during an all-nighter, when the last pieceof the new design was put into place. Much tomy surprise, the benchmark scenario was nowrunning at 55 fps. It was exciting to come backinto the offices the next day and see the formerlysluggish animation running silky smooth.The story gets personal here, as I did a greatdeal of the work on this part of AOE. I startedby trying to get a handle on what the over100,000 lines of C++ code did (the sourceBut my work was not all on the graphics engine.I also spent a great deal of time identifying andoptimizing myriad processes in the game. Sincethe game was real-time, many improvements

Ensemble’s AGE OF EMPIRES 68involved spreading out a process over severalturns rather than of stopping the game until itcompleted. In the end, the optimizations paidoff handsomely and allowed us to raise thedefault resolution from 640×480 to 800×600.A practical lesson that I learned from this experiencewas how much additional overhead andslowdown a game can acquire as it approachescompletion. Often, early in a game project theengine will show great performance—but thegame’s not finished. When you replace the simpletest levels with the complex final levels, addall the AI, UI, and bells and whistles, you canfind a world of difference in actual performance.This was true for AOE as well. As weapproached completion and all of the loose endswere tied off, many of the performance gainswere traded in for new features.(Tribe). The conversion was very successful andallowed the AOE programmers to retain anicely object-oriented design. The benefit herewas that it made the code much easier to modifyand extend, saving the programmers a greatamount of development time.2. We made the game databasedrivenThanks to the object-oriented design, almostnothing about any object in AOE is hard-codedinto the program. Instead, huge tables of informationdescribe every characteristic of everyobject that appears in the game. The designersused a system of over forty Paradox tables tocontrol and shape the game. As a result, theywere able to constantly update and tweak thegame, and then test their changes without havingto involve a programmer.Things That WorkedOut (S)well1. The game was broken intoseparate engine and gamecomponentsAbout halfway through development, there wasconcern that the code base had expanded farenough beyond the initial design in some areasthat every new change and addition would looklike an ugly hack. Lead programmer AngeloLaudon and Tim Deen took two weeks and separatedthe code base into two separate sections,the general engine (Genie), and the game itself3. We stayed in close contactand working together with thepublisherI can’t say enough good things about how theclose contact with our publisher, Microsoft,helped the development of AOE. By keepingthem “in the loop” on our progress, they workedwith us instead of against us as things happened.The best example of how this relationship aideddevelopment is the way we handled schedule slippage.Each time something took longer thanexpected or new problems cropped up, we effectivelycommunicated the delay to Microsoft.With a clear understanding of what was happeningand why, they reaffirmed their commitment toassist us in producing a quality game, whatever

69Section I: STARTUPS69amount of time that would take. So instead ofbeing panic-stricken and whacked out, weremained professional and focused on our goals.4. We played our own gameWhile this may sound simple, it’s very important.Throughout the development process,every person in the company not only playtested,but played AOE with the purpose of havingfun. As a result, we were very in tune withwhy the game was fun, and what people werelikely to get out of it. We had 20 guys who weredetermined not to let the game play be compromisedor watered down.5. Performance was goodPerformance truly means a lot if you want yourgame to have broad appeal. AGE OF EMPIREScan adequately run an eight-player game in16MB of RAM on a P120 system. Contrast thatwith TOTAL ANNIHILATION, which requires32MB and at least a 200MHz CPU for an eightplayergame. Achieving this level of performancerequired a group effort. The programmersexpended extra energy on keeping memoryconsumption in check and identifying bottlenecks,while the artists culled extra animationframes and reorganized the graphics to maximizefree memory.6. The company respected itsemployeesI have to say something about the way EnsembleStudios treated its employees and their families.It is well-known that software development,especially game development, involves great sacrificesof time and can be hell on personal relationships.Ensemble’s thoughtful managementrespected that by going out of their way toinclude families at numerous company dinnersand other events, and to make them feel welcometo come by the offices at any time.Additionally, after crunching hard to meet amilestone, they would insist that employees takea couple of days off to catch up with their families.People were allowed flexible schedules ifthey needed them, and flowers or other tokensof appreciation were sent to the families periodically.The result of this deliberate action bycompany management should be obvious; companymorale and loyalty was higher than I haveever seen in fourteen years of software development.My wife loves my job as much as I do.7. Localization really workedFrom the beginning, we knew that Microsoftwanted to release AOE in six different languages,including Japanese. About halfwaythrough development, we updated our codebase to provide full localization support. Thisrequired stripping out and replacing all text referencesin the source code and maintaining allgame text in an external resource file. It alsoplaced severe restrictions on how we could drawand display the text. We had to use the WindowsGDI exclusively, something most gamesshun like the plague. It also meant that interfaceitems such as buttons had to be sized to hold thelargest possible translated form of their captions,limiting the clever things one could dowith the design of the user interface.

Ensemble’s AGE OF EMPIRES 70But we buckled down and did it, following theguidelines exactly. And to our pleasant surprise,the conversion was swift and painless. We felteven better when the translators at Microsofttold us that localizing AOE was the smoothestand most pain-free project they had ever done.The benefit to us was enormous in that we had asingle executable program file that was the samefor all translated versions of the game, thusavoiding the huge headache that comes withtracking bugs and releasing updates for multipleversions.8. We worked as a team thatrespected all its membersA project of AOE’s size required that we allwork together in close quarters for extendedperiods of time. One of our expressed criteria inhiring new people is that we must be able torespect each other. This respect, complementedby the company’s actions towards its employees,fostered an excellent sense of family and teamspirit among everyone. We avoided having differentgroups develop a sense of isolation fromthe project, and as a result, attitudes and spiritsremained high even during the worst crunchtime. Had tempers flared and cliques developed,I honestly don’t believe that AOE could havemade it out the door in 1997.Things That Went WrongOr We Could Have DoneBetter1. We held the beta test too latein the development cycleA public beta test of AOE was held in August1997, but we didn’t come near to exploiting thefull potential of it. We were too close to the endof the project to make any game play changes,despite the wealth of useful feedback wereceived. Manuals were already set to beprinted, and most of the design had been set instone. All we could really do was fix any bugsthat were found. For any future projects, wevowed to hold the beta testing earlier.

71Section I: STARTUPS712. There was inadequatecommunication with the QApeople at MicrosoftFor most of the project, bug reporting was handledthrough a database and developers didn’tdirectly communicate with the testers. As aresult many bugs wound up taking much longerto resolve, and new features went untested. Anintermediate database was simply not enough tolet testers and developers know what the otherwas really thinking. In future projects, wewould like to assign a specific tester to each programmerand have them communicate by phoneevery couple of days. Near the end of development,this did happen for a couple people—forthem productivity with testing and bug resolutionwas drastically improved.3. We sometimes failed tocoordinate development throughthe leadsYet another area where personnel communicationcould have improved the development wasamong our own teams. Each team—Programming,Art, Game Design, and Sound—has alead person who is responsiblefor keeping track of whateach member of his or herteam is doing. The lead is thego-to person when someoneoutside has new requests forthe team. As the developmentof AOE progressed and thepressures rose, adherence tothis system broke down as people went direct toget their needs filled quickly. We paid a price forit. People didn’t know about programmingchanges or new art that was added to the game,and the level of confusion rose, creating a timedrain and distraction. We all had to stop attimes just to figure out what was going on.4. We failed to adequately testmultiplayer games with modemconnectionsOne problem with our development environmentis that it isn’t comparable to the typicalend user system. During the course of development,the multiplayer portions of AOE weretested extensively. When we played a game inthe office, our fast machines, stuffed full ofRAM, communicated with each other on ourhigh-speed LAN. When we tested Internet play,our communications were handled through thecompany’s T1 line. One thing that we failed torealize in our testing was the fact that mostplayers would be using dial-up modem connectionsto commercial Internet service providers.And it wasn’t just us; the same situation appliedto the testing labs at Microsoft. As a result,modem connection games were undertested.Bugs that were harmless when ping times werelow resulted in droppedgames for users on slowerInternet connections. And ourhigh-speed network maskedthe fact that under certainnot-so-uncommon circumstances,AOE could require15K of network bandwidthper second—six times whateven a 56K modem can provide on the uplinkside. As a result, we were taken a bit by surprise

Ensemble’s AGE OF EMPIRES 72when reports of multiplayer game problemsrolled in. Though our first patch fixed this problem,the situation was unacceptable. Now, eachdeveloper has a modem and several differentISPs are used, as modem testing is a big part ofour testing process.5. Portions of developmentrelied on products that were notdelivered on timeThere was a second reason that modem gameswere undertested: problems with the deliveryand quality of DirectPlay from Microsoft. Featuresthat were promised, and even included inbeta releases, weren’t present when the delayedfinal release was delivered. DirectX 5a wasn’tavailable to us until a month before the gameshipped. In the meantime, our communicationsprogrammer was burning the midnight oil writingthe functionality that was expected but notdelivered. Waiting on promised drivers andSDKs is one of the harder things that developershave to deal with; even those with Microsoft asa publisher have no control over them.6. We did not plan for a patchThe version 1.0a patch, even though it was asuccess, was problematic in that as a companywe had not planned for it. The general argumentis that if you know you are going to need torelease a patch, then you shouldn’t be shippingthe game in the first place. While one can takethat stand, it’s also a fact that no game developer’stesting can match that of the first 50,000people who buy and play the game. Your customerswill do and try things that you neverdreamed of, while running on hardware anddrivers that you never heard of. Lookingaround, nearly every significant game releasedthis year has had a patch or update released forit. Rather than deny this reality, we would liketo allocate resources and expectations in thefuture so that we can release any necessaryupdates days or weeks after our games ship,rather than months.7. We didn’t manage “surprise”events as well as we could haveDuring the development period, we experiencedseveral sudden events that caused us, as a company,to stop what we were doing. These eventsincluded the creation of a demo version of thegame and materials for press coverage of AOE.While most of the events were beneficial to thecompany, we weren’t very good at handlingthem, and they threw off our schedules. Thesedisruptions mostly came late in development,when their impact was felt the most. One of ourgoals for future games is to minimize the impactof unplanned events by giving advance noticewhen possible and restricting them by minimizingthe number of people that have to respondto them.8. We didn’t take enoughadvantage of automated testingIn the final weeks of development, we set up thegame to automatically play up to eight computersagainst each other. Additionally, a secondcomputer containing the development platformand debugger could monitor each computerthat took part. These games, while randomly

73Section I: STARTUPS73generated, were logged so that ifanything happened, we couldreproduce the exact game over andover until we isolated the problem.The games themselves were allowedto run at an accelerated speed andwere left running overnight. Thiswas a great success and helped us inisolating very hard to reproduceproblems. Our failure was in notdoing this earlier in development; itcould have saved us a great deal oftime and effort. All of our futureproduction plans now include automatedtesting from Day One.Patching It All UpOnce AOE was shipped off to production, wethrew ourselves a big party to let off somestress. It turns out we were a bit premature inour revelry. Shortly after AOE arrived on storeshelves we began receiving feedback on problemswith the pathfinding, unit AI behaviors,population limits, and multiplayer play. Additionally,some bugs were found that a playerThe AGE OF EMPIRES development team. The author issecond from the right in the row of guys who are kneeling.could exploit to gain an unfair advantage in thegame. Management was stirred to action atboth Ensemble and Microsoft, and the decisionto do a patch for AOE was made. Althoughtime was taken away from other projects, and ittook longer than desired, the patch was a success;it vastly improved the quality of multiplayergames, fixed the bugs, and addressed thegame play concerns that had been raised. Andthat brings the development of AOE to where itis today, which I hope is somewhere on yourhard drive…

This Page Intentionally Left BlankEnsemble’s AGE OF EMPIRES 74

75SECTION IISequels and SophomoreOutingsA sequel project (and really any company’s nextgame after producing a signature hit) marks aparticular point in a company’s life-cycle.You’ve made a game that sold, and maybe evenmade a profit. Your game idea is no longer acrazy experiment, it’s a proven commodity. Thefly-by-night startup is an actual business. Peopleknow your company’s name, there are fans outthere with Web sites and bulletin boards, talkingabout you. And your publisher is eager to makethe next deal, in fact they’ve already penciled itin for Q4 of next fiscal year: the sequel.There is, no question, a luxurious feeling todoing a sequel. It’s a victory lap, an encore. Sowhat if you’re not blazing a trail into unknownterritory—at least you get to travel in comfort.You don’t have to explain your high concept toglassy-eyed listeners, waving your hands in theair to evoke an imaginary interface. Publisherslove it. They know you’re a bankable commoditynow; they’ll take your calls and return youre-mails. You are, to some extent, resting on yourlaurels, and a soft comfy perch it is.At first glance it seems like easy money—if theybought the first one, they’ll buy the next. Butwhen you sit down to make a sequel, you realizeit’s not quite so simple. There are unique challengesinvolved. Sequels and follow-ups areharder than they look, as the postmortems inthis section tell us.It’s true that any company making a sequel hasseveral advantages. Obviously, name-recognitionis one—there is a pool of people whobought the first game and presumably liked it,who will immediately be interested in the nextone. Financially, there’s a certain guaranteedlevel of sales. There is already a community ofplayers out there who will buzz about it ongaming boards, and publicize details of thesequel on their Web sites. Game journalists willbe more willing to write a preview, since thearticle has a ready-made hook. And, for better

Section II: SEQUELS AND SOPHOMORE OUTINGS 76or for worse, you will have already have workingcode, proven game mechanics, and art assetsto recycle or use for inspiration when you getdown to work.Crucially, the release of the first game has providedenormously rigorous testing of key technologyand design elements. No amount of inhousequality assurance testing can replace hundredsof thousands of users out there in the realworld installing your game on any and allmachine types and display devices, now matterhow inappropriate or unlikely. If it’s for a gamingconsole, an army of twelve-year-old boyswill have devoted weeks of their time to discoveringany and all flaws in the design and technology.Any flaws in the renderer, anycompatibility problems, will have beenannounced in magazine reviews, and shoutedout in ALL CAPS on popular gaming forums.The almighty power of the Internet will leave noaspect of your game unmolested.The feedback will also be about the design, andno matter how painful it is, it is worth listeningto. Any imbalance in the gameplay and anyexploitable bugs in the level design will havebeen thoroughly hashed over on half a dozenWeb sites, most likely with illustrative screenshots.The judgment-calls you agonized over indesign meetings will be re-argued endlessly inpublic, and it may be clear that you shouldreverse your decision in your next game, or atleast try an alternate path. Regardless, you willknow the public’s opinion, most likely expressedin jauntily intercapped slang.The advantages are obvious, but the difficultiesof creating a sequel game are not always asapparent until you attempt to do it. The basicchallenge of making a sequel is paradoxical—yourjob is to make exactly the same game,but more/different/better. Some things (graphics?story?) have to change, but others (audio?weapons?) must be exactly the same, yet somehowimproved and more intense. You have todecide what the essence of the game is, what thefundamental thing about it that worked was,and then deliver it again in an improved package,with better graphics and a few new toysthat extend the basic concept without deviatingfrom it. The games discussed in this section allseemed to succeed by innovating on the smalllevel, expanding and enhancing existing featuresrather than transforming them.The first time the game shipped, it had nothingto live up to. This time, there will be a whole setof user expectations. Not everyone likes thesame game in the same way, and some peoplewill inevitably complain that what they likedabout the original game is gone. Everyone willhave some idea of what you should do, orshould have done, with the sequel, how thebasic formula can be improved. Not everyonewill be pleased.Also, as noted above, you will have existingassets to draw upon—code, design ideas, artwork.Again, you will have to decide what tokeep, what to tinker with, and what to scrapwholesale. Sloppy hacks put in at the lastminute to ship the first game can be rewrittencleanly or papered over and kept around fornext time. The question of when to fix broken

77Section II: SEQUELS AND SOPHOMORE OUTINGS77code and when to rewrite from scratch seems tobe one of the most persistent and vexing in thewhole field of software management. The argumentson both sides are endless—the pressure toreuse assets to save production time is balancedagainst the appeal of the clean slate.It is worth noting, of course, that by the time thesequel ships, the entire industry will have movedforward. Any code you keep from the first gamemay be three or four years old by that time, aneternity in software years. The minimum acceptablestandard for certain features may havechanged utterly, and Moore’s Law waits for noman.On the production side, you will have a wholehistory of development processes to followagain, or change around—your own in-housepostmortem of what you did right and wronglast time. Did weekly staff meetings work, orturn into an expensive waste of time? How badwas the crunch phase, and how can it beavoided? This can be difficult to evaluate, especiallywhen it involves key personalities on theteam. But a good, honest postmortem can savemonths of work and hassle and pain. Get it allout on the table, and the team will be strongerfor it.Finally, there is the issue of team fatigue. No oneis more uniquely qualified to do a sequel thanthe existing team, but chances are they are onesmost in need of a change. Unless they’re verylucky or truly excited about the project, they’llbe sick and tired of hockey or orcs or rabbits orwhatever the first game was about and be achingto work on something new and completelydifferent. Your hotshot renderer jockey may notfeel like polishing up old code—he or she mayonly be interested in writing next-generationapplications. After all (they may well argue), theteam shipped a successful game, and theirreward should be a chance to be creative again,not to grind out the same thing again.Even if your company’s second game is not atrue sequel, many of the problems and opportunitiesare the same. If your first game was a successthere are still challenges of continuity,because your company now has an identity, avibe associated with it. It’s a brand that youmust now manage. You have a company cultureand a set of production processes that have nowshipped one game, and you have to make decisionsabout what to keep and change next timearound.Viewed in the wider context of the games industry,sequels are likewise a double-edged sword.In a sense, they help keep the industry alive byreducing risk, guaranteeing a certain amount ofsales. This is incredibly important in an industryas expensive and as risky as the game industry.An average game published by a major gamepublisher costs $5–10 million to develop, andrequires 1–3 years in development time and ateam of 10–50 developers and artists. Anythingthat increases the odds of a decent return on thisinvestment is important, especially since many,many games never make back their productioncosts, while a handful of hits take most of theprofits. Sequels, and the brand name any studiorepresents, offer a modicum of stability in a desperatelyrandom industry. From the point ofview of the consumer, buying a sequel means

Section II: SEQUELS AND SOPHOMORE OUTINGS 78reducing their risk. They have a better sense ofwhat’s inside the box and whether it’s worthinvesting their hard-earned $50.The other side of the argument is that sequelsand copycat titles lack innovation. The dulllogic of capitalism supports design by formula—whatsold before will sell again. Theresult is that the industry fails to move improveand invent as fast as it should, and the shelves ofretail outlets are stacked with versions of thesame title year in and year out. Clearly bothsides of the argument contain an element oftruth.But sequels advance the field in their own wayby refining existing styles of gameplay, innovatingwithin known genres rather than creatingnew ones. As we can see in the following postmortems,sequels are a chance to use what hasbeen learned in the first outing. Experimentationis useful, but only if we take the time to learnfrom the results, to build on the foundation.Someday the medium of digital games willmature, and we will have an established traditionand body of technique to build on when wemake a game. In a sense, the sequels here are aglimpse of what that future will look like.

79Blizzard Entertainment’sDIABLO IIby erich schaeferThe original DIABLO went gold on the day afterChristmas in 1996, after a grueling four-monthcrunch period. We hadn’t put any thought intowhat game to do next, but as most developerscan probably relate to, we were pretty certainwe weren’t ready to return to the DIABLO worldafter such a long development cycle. The onlything we were certain of was that we wanted toavoid another crunch like we had just experienced.DIABLO II went gold on June 15, 2000,after a grueling 12-month crunch period. AfterDIABLO shipped, we spent about three monthsrecovering and kicking around game ideas forour next project, but nothing really stuck.The idea of returning to DIABLO began to creepinto the discussions, and after a couple ofmonths of recuperation, we suddenly realizedwe weren’t burned out on DIABLO anymore. Wedusted off the reams of wish-list items we hadremaining from the original, compiled criticismsfrom reviews and customers, and began brainstorminghow we could make DIABLO II biggerand better in every way.DIABLO II never had an official, complete designdocument. Of course, we had a rough plan, butfor the most part we just started off making upnew stuff: four towns instead of the originalBack-StoryThe DIABLO series belongs to one of the oldest of allgenres, the dungeon crawl—a lone adventurer exploringlabyrinths full of monsters, traps, and treasure, accumulatingexperience, ability, and power. In their sequel tothe original, Blizzard added a skill system to help differentiatecharacters and suit different playing styles andfurther polished the jewel-like simplicity of the game torefine the genre almost as far as it could go. DIABLO II'sstripped-down one-click interface, online competition,and dynamically generated dungeons make for simple,addictive, endless exploration.game’s one; five character classes, all differentfrom the previous three; and many newdungeons, vast wilderness tile-sets, and greatlyexpanded lists of items, magic, and skills. Wewanted to improve upon every aspect of theoriginal. Where DIABLO had three differentarmor “looks” for each character, DIABLO IIwould use a component system to generatehundreds of variations. Where DIABLO had“unique” boss monsters with special abilities,DIABLO II would have a system for randomlygenerating thousands of them. We wouldimprove the graphics with true transparency,colored light sources, and a quasi-3Dperspective mode. Level loads would be a thingof the past. The story would be factored in from

Blizzard Entertainment’s DIABLO II 80the beginning and actually have some bearingon the quests.Game DataRelease date: June 28, 2000Publisher: Blizzard EntertainmentGenre: dungeon crawlPlatforms: Windows and MacintoshFull-time developers: 40Length of development: more than 3 yearsDevelopment hardware used: Typical programmerworkstation: 500 MHz Pentium II running Windows NTwith 128MB RAM and 9GB hard drive. Typical artistworkstation: dual 500 MHz Pentium IIs runningWindows NT with 256MB RAM and 14GB hard drive.Development software used: 3D Studio Max,Photoshop, Microsoft Developer Studio/Visual Studioand SourceSafeNotable technologies used: Glide, Direct3D, RADGame Tools’ Bink, DirectSound3D, and Creative Labs’EAX.We knew creating this opus would be a big job.Because we had the gameplay basics alreadypolished, we figured we would hire some newemployees, create some good tools, and essentiallymake four times the original game doingonly two times the work. We estimated a twoyeardevelopment schedule. The DIABLO II teamcomprised three main groups: programming,character art (everything that moves), andbackground art (everything that doesn’t move),with roughly a dozen members each. Designwas a largely open process, with members of allteams contributing. Blizzard Irvine helped outwith network code and Battle.net support. TheBlizzard film department (also in Irvine) contributedthe cinematic sequences that bracketeach of DIABLO’s acts, and collaborated on thestory line.Almost all of DIABLO II’s in-game and cinematicart was constructed and rendered in 3D StudioMax, while textures and 2Dinterface elementswere created primarily with Photoshop. Theprogrammers wrote in C and some C++, usingVisual Studio and SourceSafe for version control.Blizzard North started out as Condor Games inSeptember 1993. The first contracts we landedwere ports of Acclaim’s QUARTERBACK CLUBfootball games for handheld systems and, moresignificantly, a Sega Genesis version of JUSTICELEAGUE TASK FORCE for Sunsoft. Silicon andSynapse, a developer that would later change itsname to Blizzard Entertainment, was developinga Super Nintendo version of JUSTICE LEAGUETASK FORCE. Condor ended up pitching the ideafor DIABLO to Blizzard, and halfway throughthe resulting development process Blizzard’sparent company acquired Condor, renaming usBlizzard North.Throughout a tangled history of corporate jugglingand ownership changes, Blizzard Northhas remained a very independent group. Ourstaff has grown steadily from about 12 at thestart of DIABLO to 24 at the start of DIABLO II,and finally to our current group of more than40. We concentrate 100 percent of our effortson game development. To help keep this focus,Blizzard’s headquarters in Irvine manages otherfunctions, such as quality assurance, marketing,

81SECTION II: SEQUELS AND SOPHOMORE OUTINGS81public relations, technical and customer support,as well as the operation of the Battle.netservers. Our parent company, Havas Interactive,deals with business functions such as sales, manufacturing,and accounting.What Went Right1. DIABLO II is still DIABLOA constant theme in previews and reviews ofDIABLO II was that we didn’t change anything; itwas more of the same. At first that struck us asodd. We kept less than one percent of the codeand art from the first game. We rewrote thegraphics engine, changed all the characterclasses and skills, shifted and expanded the setting,reworked and added to the magic items,brought back only a handful of our favoritemonsters, and designed a ton of new gameplayelements, such as running, hirelings, left-clickskills, and random unique monsters.Why, then, did everyone think it was the samething? In the end, we decided just to take it as acompliment. The play-testers and reviewersmeant they were having exactly the same kindof fun that they had in the original game. BothDIABLO and DIABLO II provide a constantsource of simple pleasures, many of which areperhaps too basic and obvious to mention inevaluations and reviews, but which are fundamentalto their success.We used the term “kill/reward” to describe ourbasic gameplay. Players continually kill monstersand get rewarded with treasure and experience.But the rewards don’t stop there. We offer asteady stream of goals and accomplishments toentice the player to keep playing. There’s alwaysa quest that is almost finished, a waypointalmost reached, an experience level almostachieved, and a dungeon nearly cleared out.On a smaller scale, we tried to make every singleaction fun. Moving around inventory items producespleasing sounds. Monsters die in spectacularfashion, like piñatas exploding in a showerof goodies. We strove for overkill in this sense,in that players are constantly on the verge ofsomething great—only a few mouse-clicks awayfrom a dozen interesting things.DIABLO II retained DIABLO’s randomly generatedlevels, monsters, and treasure. This obviouslyallows for better replay potential, but alsoserves to make each player’s game his or herown. Players feel an ownership of their owngame experience in that they are actively generatinga unique story. It’s enjoyable to tell friendsabout what you have just done in the game,knowing for sure that they have not done thesame thing. Simply following an online walkthroughwon’t help them accomplish goals withouteffort.Finally, DIABLO and DIABLO II are easy to play.We used what we call the “Mom test”—couldMom figure this out without reading a manual?If we see new players struggling with how to sellitems, we look at how they’re trying to do it andmake that way work too. We strove to make theinterface as transparent as possible. You want toopen a door? Left-click on it.

Blizzard Entertainment’s DIABLO II 82The player characters have modular armor of three varieties, light,medium, and heavy, which were mixed and matched to provide moreindividualized character appearances. “Paper dolls” created on paperand in Photoshop allowed mixing and matching of different pieces ofarmor to see how they worked together on the Barbarian.Want to move to a target location? Left-click onit. Want to attack a monster, pick up an item, ortalk to a non-player character? Well, you get theidea. It’s amazing how many games have differentcontrols and key combination for all theseactions when simpler is always better.2. Blizzard’s developmentprocessBlizzard’s development process is designed toensure that we make a great game. While ourgoal is to meet the milestones we set, our process,in terms of design and business, is structuredto allow us to wait until the game is asgood as it can be before we ship it. We recognizethat not all developers have this same opportunity,but many of the methods we use along theway are applicable to any development environment.First, we make the gameplayable as soon as possiblein the developmentprocess. Ourinitial priority was toget a guy movingaround on the screenand hacking monsters.This is what playerswould be doing most ofthe time, and it had tobe fun. We were constantlyable to hone thecontrols, pathfinding,and feedback mechanismsduring the entirelength of the game’s development. Most importantly,it allowed us to determine what was funto do, so we could provide more of it, and discoverwhat was awkward or boring, so we couldmodify or remove it.For instance, it became obvious very early thatplayers would be killing large amounts of thesame monsters, and those monsters would predominantlybe attacking the players. This gaveus the opportunity to plan for multiple deathsound effects and additional attacking animationsfor each monster. If we hadn’t experiencedthe core gameplay as early as we did, combatwould have ended up feeling much more repetitive.Also, we constantly reevaluate gameplay andfeatures. Up until the very end, if we can makethe game better we will, even if it means redoingbig tasks. For instance, we decided that wedidn’t like the Bone Helmet graphics for the

83SECTION II: SEQUELS AND SOPHOMORE OUTINGS83characters more than a year after having renderedthem, but we went ahead and remadethem, even though it took a couple of weeks andthe collaboration of four artists. Only weeksaway from scheduled beta testing, we scrappedour Act IV level layout schemes because theywere just a bit too emptyand similar. The lastminutefixes turned theselevels into some of thebest, befitting their climacticfunction. DIABLO IItook more than 40 peopleand over three years,essentially because wemade two or three gamesand pared them down tothe best one.Another gigantic reasonfor our success is our opendevelopment process. Westrive to hire people wholove games, and we makegames that we want toplay. Every member of the team has input intoall aspects of the game. Discussions around thehalls and at lunch become the big ideas thatshape the game. A programmer suggested to adesigner the concept of gem-socketed, upgradeableweapons, which turned out to be a hugecrowd-pleaser. A musician’s dislike for the oldfrog-demon’s animation inspired us to redo it.As a team, we don’t have to wonder what ouraudience wants, because we are our audience.If we like the game we are making—especiallyif, after two years of playing it, we are not boredto death—the game is clearly going to be a winner.3. Character skill treeCreating detailed sketches of settings,such as this hut in the Act III dock townof Kurast, preceded the actualmodeling of background art. Much timewas spent perfecting Act I since itwould likely be used in a beta test ordemo. The Amazon was the firstcharacter to be completed.Our most revolutionary new idea was the characterskill tree. For a characterto attain morepowerful skills, he or shemust master prerequisiteskills. The ability for charactersto branch into differentareas of the skilltree, and to choose a levelof specialization in eachskill along the way, providestruly unique characters.At the start ofdevelopment, we plannedto use the model from theoriginal DIABLO: characterswould find and readbooks to learn spells andskills. Unlike DIABLO,which had 28 spells sharedby all three characters, we wanted to create aseparate group of 16 skills for each of our fivenew character classes. This would definitelyhave been an improvement, but every characterof a given class would still end up knowing allthe same skills as other members of their class.Another problem was that players would likelybe finding spell books for other character classesmuch more often than for their own. The skilltree solved these problems. The general idea wastaken from the tech trees many strategy gamesemploy. In strategy games, players advance by

Blizzard Entertainment’s DIABLO II 84researching new technologies, which in turnopen up further avenues of research. Weadapted this to have our characters advance bychoosing a new skill or strengthening an oldskill every time they gain an experience level.Characters can generalizeby choosing awide variety of skills,or specialize by allocatingmany skillchoices into a smallgroup of skills.We also created astrategy element ofchoosing skills youmight not use, just soyou can get to onefurther up the treelater.The end result of theskill tree is that oneplayer can develop aNecromancer whokills monsters with a powerful poison daggerskill augmented by curses that cause monsters tofight each other, while his friend’s Necromancerwill summon hordes of skeletons to fight forhim, and doesn’t use any curses at all. The longevityof DIABLO II will be enhanced by the endlessstrategies that can be debated andexperimented with.4. Quality assuranceThe task of testing a game of DIABLO II’s scope,with its huge degree of randomness and itsThe architecture in DIABLO combines aspects ofmany different cultures in order to arrive at aninteresting mix that doesn’t look too much likeany single one. Here, the buildings of Travicalfrom Act III are based on Mayan and Aztecreferences.nearly infinite character skill and equipmentpaths, required a Herculean effort. We found wecould not play-balance the climactic fightagainst Diablo without actually playing theentire game up to that point, because we couldnot predict whatkinds of equipment acharacter might have,or what path throughthe skill tree he or shemay have followed.This meant 20 or 30hours of play for allthe different characters,with a good varietyof skill sets andequipment for each.Whenever wechanged the game’streasure spawn rateor experience curve,we had to test it allagain.Further complicatingmatters were multiplayer and difficulty-modebalance. Would a party of five Paladins, eachusing a different defensive aura, be untouchable?After more than 100 hours of play, is afire-based Sorceress unable to continue in “Hellmode”?The QA team created a web-based bug-reportingdatabase through which we categorized andtracked all bugs, balance issues, and gameplaysuggestions. In the end, this list delineated morethan 8,300 issues and suggestions. Well-organizedteams of testers concentrated on different

85SECTION II: SEQUELS AND SOPHOMORE OUTINGS85aspects of the game, divided into groups thatwould specifically test character skills, itemfunctionality, monster types, and spawn rates,or explore the countless variations found in therandom level generation system. The membersof the QA team became very good players andastute observers of the progress of the game.Everything worked much more smoothly thanour experiences with the original DIABLO.While the player characters are only seen inthe game as 75 pixels tall, all were modeledand rendered in high resolution for use onthe character selection screen and inpromotional materials. Here, the Paladinstands tall.5. Simultaneous worldwidereleaseIn the past, Blizzard’s strategy for shipping itsgame has been to get games on North Americanretailers’ shelves as quickly as possible after theEnglish version of the game went gold. With theoriginal DIABLO, we created our gold master onDecember 26, and some stores had it on theshelves by the 30th. Since DIABLO was released,the percentage of international customers hadincreased substantially, and with DIABLO II, wefully expect more than half of our sales to comefrom outside North America.With such a large number of customers locatedoutside the United States, for DIABLO II wedecided that there would be significant advantagesto coordinating the U.S. release to coincidewith the rest of the world, not only to buildanticipation for the product, but for the benefitand satisfaction of our customers as well. If werelease a game in the United States first, customersin the rest of the world don’t want to wait afew months while we translate and localize it fortheir country. Due in part to the internationalclimate fostered by the Internet, players aroundthe world all know about the game at the sametime and want to get it while it’s hot. Theymight buy the U.S. version under the table orsearch out a pirated copy. Worse, they mightlose interest by the time we release a localizedversion.DIABLO II’s simultaneous worldwide release alsoallowed our marketing and PR departments tofocus their efforts toward creating a frenzy ofinterest for the first week of sales. Although the

Blizzard Entertainment’s DIABLO II 86simultaneous release was a logistical headache,it was all worth it in light of DIABLO II’s superbsuccess.What Went Wrong1. Developing the newBattle.netWe have always been very proud that our companylaunched Battle.net with the originalDIABLO. Just a couple of months after DIABLOshipped, Battle.net was the largest online gameservice in the world. At DIABLO II’s launch, Battle.nethad more than 6 million unique activeusers. Despite the original DIABLO’s successonline, we knew as we began development thatto create the type of multiplayer experience thatwe wanted to achieve in DIABLO II, we wouldneed to fundamentally change the game network.And, as we expected, this became one of ourbiggest challenges during development. We hadto reinvent Battle.net’s structure by meldingexisting technology with new programming andfeature sets. This had implications across theboard. We had to rethink everything—programming,hardware, bandwidth, staffing, onlinesupport, and how we could financially supportthis model while keeping it free.Although the original Battle.net had been furthermodified to support STARCRAFT as a chatand matchmaking service, for DIABLO II weneeded much more: game servers where theCharacters and monsters, such as thisVampire, were created in 3D Studio Max. Anin-house tool would render the files from manydifferent angles (eight for all monsters, 16 forplayer characters), and export them in the fileformats used in the game.Realm games would actually be played, securecharacter-data servers, and game tracking systems.Trying to shoehorn these elements in theexisting Battle.net system proved very difficult.For instance, we planned to have characternames represent players in Battle.net, but it wasdesigned to handle chatting between accountnames.It took a lot of design and implementation timeto arrive at our final system, where users seecharacter names but have to send remote messagesto account names. We initially believedthat working with the existing Battle.net wouldsave us time, but in retrospect, we learned thatmelding technologies is a difficult process, andin some cases, recoding instead of integrating isthe better course of action.

87SECTION II: SEQUELS AND SOPHOMORE OUTINGS872. Launching the new Battle.netThe success of Battle.net after DIABLO’s launchcreated a new challenge for us. When DIABLOwas released, Battle.net was a new online service.Basically, we were able to ramp up as morecustomers joined the service. When DIABLO IIshipped, Battle.net had millions of users. Thelevel of anticipation was higher than for any ofour other games. We were well aware of theexpectations, and we knew that no other companyhad ever attempted tocreate and sustain an onlineservice that could supportthe type of usage DIABLO IIwould experience right outof the chute.We spent countless hourspreparing for Battle.net’sDIABLO II debut. Weteamed with the best ISPs inthe word, and conductedmonths of internal and external beta testing. Weramped up bandwidth and hardware. We beefedup the Battle.net, quality assurance, and supportservice teams.Although we had more than 100,000 peopletesting the DIABLO II Realms, having more thanone million customers in just three weeksproved to be very different from beta testing.The beta test was very successful in uncoveringmany stability issues that were addressed beforethe launch. After the game shipped, we facedbugs that only appeared at much higher usagerates. The issues that we faced at launch wereones that could not have been simulated in abeta test of 100,000 people. It took a muchlarger influx of players to trigger certain situations.Knowing the massive scope of what we weretrying to achieve with Battle.net, we had measuresin place at launch to help us deal withissues that arose as usage increased. Forinstance, we maintained both a team of programmersand the entire quality assurancedepartment to solve problems as they appeared,and had our support team working overtime.We also had an action planin place to increase hardwareand bandwidth asneeded. In some respects,we are victims of our ownsuccess. We underestimatedsales, but we alsounderestimated the allureof playing on the Battle.netRealms. By solving thecheating problem inDIABLO and enhancing Battle.net with new features—suchas the ability to see everyone’s charactersin the chat room—we seem to haveattracted a larger share of Battle.net playersthan with any of our previous titles.3. GraphicsShortly before DIABLO II shipped, we begannoticing some feedback from customers aboutthe resolution of the graphics in the game. Theywere frequently labeled “outdated” or “pixellated.”The shame is that the technology choiceswe made eclipsed the recognition of the fantasticjob the artists did. We put a lot of effort intocreating characters, monsters, and landscapes

Blizzard Entertainment’s DIABLO II 88resolutions. In any case, DIABLO II will probablybe our last 2D game.The Barbarian, translated from the sketches intoa full, high-polygon model. Each part of acharacter’s armor (the head, the torso, the legs,each arm, a weapon, and a shield) was renderedseparately with in-house tools.with a lot of unique character. The game displaysan incredible amount of action happeningonscreen in an easy-to-follow manner. Still, withall the negative reaction, we probably shouldhave done it differently. When we began producingart for DIABLO II in mid-1997, we investigateda lot of options. We mocked up a 3Dengine and checked out voxel systems. It didn’ttake us long to go back to what we used inDIABLO: 2D graphics at 640×480 resolutionwith 8-bit color depth. At that time it was stillthe only way to get eight characters, upwards of30 monsters, and upwards of 100 missiles allinteracting on the screen at one time withoutsacrificing detail and atmosphere.The graphics criticism caught us by surprise. Wethought (and still think) that the game lookedgreat. We probably should have built in a scalingtechnology to take advantage of hardwarethat could display the same graphics at higher4. ToolsWe developed the original DIABLO with almostno proprietary tools at all. We cut out all thebackground tiles by hand and used commercialsoftware to process the character art. Spells andmonsters were balanced by verbal estimates(“Hey, let’s make the lightning about ten percentweaker.”).DIABLO II’s vastly increased scale required muchbetter tools, and we made some, but notenough. In many cases we created tools to speedup content creation, but then abandoned them.Too often, we decided to keep using inferiortools because we thought we were almost donewith the game, and didn’t want to take the timeto improve them. Unfortunately, in most ofthese cases, we were not really almost done withthe game, and in retrospect, a couple of weeks’worth of work would have helped in the year ormore of development remaining.The greatest deficiency of our tools was thatthey did not operate within our game engine.We could not preview how monsters would lookin the environments they would inhabit. Wecouldn’t even watch them move around until aprogrammer took the time to implement an AI.Even after that, an artist would have to hasslesomeone to get a current working build of thegame to see his creation in action. Our soundeffects engineers ended up painstakingly creating.AVI movie versions of animations in orderto synch sounds with actions.

89SECTION II: SEQUELS AND SOPHOMORE OUTINGS89Our lack of tools createdlong turnaround times,where artists would end uphaving to re-animate monstersor make missing backgroundtiles months after theinitial work was completed.We should have made toolsthat let us create contentwithin the game engine.Instead of just handing off aset of animations and hopingthey looked all right whendropped into the game, artistsshould have had the abilityto position andorchestrate their creationsthemselves. The extra tooldevelopment time wouldhave been more than offsetby increased efficiency andhigher-quality work.5. Save-gamemethodologyAs much as we tried to makea frustration-free game, weseem to have failed somepeople with our save-gamescheme.Eschewing the common save-game feature weused in the original DIABLO’s single playermode, where every facet of the game state canbe saved to files and reloaded at will, we optedto make all modes behave more like DIABLO’smultiplayer game. In DIABLO II, we do not saveSome of the many locales in Act II:The Sand-Maggot lair (top),Jerhyn’s Palace (middle), and theSewers (bottom).the world state. Reloadingthe game resets the locationof monsters and treasuresevery time. The character isplaced in the town he or shelast visited, not in the wildernessor a dungeon.Although this choice wasslightly controversial aroundthe office, it had a lot ofadvantages. For one, playerscould not get stuck, unableto progress further. At anytime you can restart in town,refight the same monsters formore experience and loot,and return to a difficult areawhen ready. We created awaypoint system that allowscharacters in new games toreturn quickly somewhereclose to where they quit theprevious game. Finding newwaypoints is a rewardingmini-goal during play. Wealso wanted to discouragethe type of play where playersfeel they must alwayssave the game right before adifficult section, then constantlydie and reload untilthey get lucky and make it through. Finally, itwas just easier to make single-player games andmultiplayer games work the same way, and multiplayerrequires the method we used.

Blizzard Entertainment’s DIABLO II 90A lot of players don’t like our decision. Theyfeel it is too inconvenient to have to fight theirway back though the same areas and monsters.Many also want the opportunity to experimentwith skill choices and equipment purchases,then later revert the game back to an earlierstate if they don’t like the results. There aregood points on both sides, and we probablydidn’t spend enough time developing alternatives.The Final WordMany more things “went right” than could fit inthat section. Our internally controversial plan totell a separate but parallel story through our cinematicsequences seems to have succeeded, andthe workmanship and quality of these sequenceshas set a new standard. Our marketing and PRdepartments did a fantastic job building customerawareness and creating a frenzy of interest.DIABLO II’s music is outstanding, and alongwith an amazing array of sound effects, contributeshugely to the atmosphere of the game.The development of DIABLO II is a remarkablesuccess story. We got the opportunity to makethe game we wanted to make—and the game wewanted to play. DIABLO II turned out to be agreat game, one that many of us still play everyday. Initial sales figures are phenomenal, andreviews have tended to be better than those ofits predecessor. We have gained a lot of experiencethat should help us make even better gamesin the future. The only major downside toDIABLO II’s development was the inhumanamount of work it required. A year-long crunchperiod puts a huge burden on people’s relationshipsand quality of life.Our biggest challenge for the future is figuringout how to keep making giant games likeDIABLO II without burning out. As a start, weare hoping our experience will help us do a betterjob scheduling and managing the workload.We also believe that taking the time to makebetter tools will make things easier at the end ofprojects. Although I tried to avoid personalizingthis article, I am extraordinarily proud of theentire development team. DIABLO II could nothave happened without all the superb individualefforts, the incredible creativity, and the wholeteam’s dedication to the project, for which theyhave earned my gratitude, and no doubt that ofthe legions of players who enjoy the game.

91Epic Games’UNREAL TOURNAMENTby brandon reinhartUNREAL TOURNAMENT, released in November1999, was, in a way, an accident. After the originalUNREAL was completed, Epic wanted to followup the project with some sort of add-onpack. UNREAL multiplayer code was very poor,so the team felt that an expansion that improvedmultiplayer would be ideal. As feature lists grewand patches to UNREAL were released, the addonturned into a complete and independentgame.UNREAL TOURNAMENT has certainly seen a verynontraditional development cycle, one that I feelwould not have succeeded in any other genre.Ultimately, our decisions paid off, because thegame earned more than five “Game of the Year”awards and is consistently rated in the top ninetiethpercentile in reviews. The online communityis producing excellent expansions andmodifications to the game and we feel thatUNREAL TOURNAMENT will be around for along time to come.Early DevelopmentA proper look at the development of UNREALTOURNAMENT begins with the completion ofUNREAL. The Unreal engine was four yearsBack-StoryUNREAL TOURNAMENT is the sequel to one of the definitivefirst-person shooters, UNREAL. For UNREAL TOUR-NAMENT, Epic shifted from a hybrid of single-playerexploration and multiplayer deathmatch to a purely gladiatorialformat. UNREAL TOURNAMENT has no single defininginnovation, but multiple game modes, inventive leveldesign, and improved AI make it a solid incrementalimprovement to the genre.under development and the team was wearingdown. When the game shipped, it met with alarge amount of acclaim, but that positive imagewas tarnished over time as hardcore playersbegan to complain about the terrible networksupport. The UNREAL team was now faced withseveral more months of work on the game,essentially to bring it to the point it should havebeen at when it was put on shelves.Early in the process, plans were discussed towork on an official Epic add-on to UNREAL. Theadd-on would introduce much-improved networkplay, new maps, and probably some newgame features. The original ideas for the add-onwere never put on paper, and it never had aname. I was hired by Epic in August 1998 toassist with patching UNREAL. Eventually Istarted to write new code for the add-on withSteve Polge.

Epic Games’ UNREAL TOURNAMENT 92Initial work on the add-on in early summer1998 was made difficult by the fact that Epicwas a virtual company. The last year ofUNREAL’s development took place in Canada,with the U.S.-based Epic team flying back andforth to work with Digital Extremes in London,Ontario. When UNREAL was finished, no one atGame DataRelease date: November 1999Publisher: Info GamesGenre: first-person shooterIntended platform: Windows 95/98/NT, LinuxProject budget: $2 millionProject length: 18 monthsTeam size: approximately 16 developersCode Length: 350,000 lines of C++ and UnrealScriptCritical development hardware: Pentium II 400swith 256MB RAM and Voodoo 2 or TNT-based cardsCritical development software: Microsoft VisualStudio, 3D Studio Max, UnrealEdEpic wanted to travel anywhere, but at the sametime the team recognized that they needed tomove to a central location. The team decided torelocate all of its employees to Raleigh, N.C.By September 1998 everyone was together orhad a travel plan. Work started to come togetherrapidly on the add-on project. Steve Polge hadlaid the groundwork for several new game types,including Capture the Flag and Domination. Thelevel designers had five or six good maps readyfor testing. Throughout sporadic but intensemeetings, the team agreed to focus the add-onentirely on improving the multiplayer aspect ofthe game with new features and better net code.The amount of content grew, and we soon realizedwe had a much larger project on our handsthan we had originally thought. In November,after meetings with our publisher GT Interactive,Mark Rein suggested we turn the add-on into aseparate game. Initially, the team opposed theidea. We wanted to finish the project quickly andmove on to something fresh. The promise of amuch higher profit potential, coupled with ourrecognition of the state of the project finally ledus to agree with GT. In December, the nameUNREAL: TOURNAMENT EDITION was chosen,with “Edition” subsequently dropped from thetitle.A Game Takes ShapeEpic’s internal structure is extremely liberal,probably the most liberal in the entire gamingindustry. Programmers work on the projectsthey want to work on, with major features beingassigned to whoever steps forward to take onthe task. Artists work with level designers butare given significant design freedom. Leveldesigners work on the kinds of maps they thinkwould be cool. This design philosophy pervadedUNREAL TOURNAMENT’s development. InDecember, I downloaded a sample of a newUNREAL mod under development by an Australiannamed Jack Porter. The mod, UBrowser,was a server browser using a Windows-likeGUI. It was impressive, so I showed it to JamesSchmalz, lead designer at Digital Extremes, whosaid, “We need that, we need to hire this guy.” Afew weeks later Jack was a part of the team,expanding his UWindow GUI and reworking

93SECTION II: SEQUELS AND SOPHOMORE OUTINGS93UNREAL TOURNAMENT’s menus to use the system.Jack fit into the team perfectly, bringing a completesolution for the interface and menus aswell as his own independent programming initiative.Weekly meetings infused order into ourchaotic corporate structure. Everyone woulddebate and yell about what features were cooland what features sucked.The assignment of major features was largelyautomatic. Tim Sweeneyworked on improving netcode and engine fixes. StevePolge wrote the original AIcode and focused on addingplayer orders and otherimprovements (in addition tofilling out the new gametypes). Jack had the windowingsystem and a lot of menusto work on. Programmer Erikde Neve was in Europe puttingtogether level-of-detailcode as well as experimentingwith next-generation technology.I worked on the singleplayergame, game-play features,scoreboards, HUDs,special level actors, tutorials,and wrote a lot of the game’sstory and character backgroundcontent.The best features were addedentirely by the initiative ofindividuals. Level designerThe characters in UNREALTOURNAMENT were designed tobe futuristic pit fighters. Theselection of characters includeex-military specialists,criminals, and alien warriorssuch as the Necris PhayderAssassin pictured above.Cedric “Inoxx” Fiorentino designed CTF-Face,an extremely popular Capture the Flag map. Iadded the Multi-Kill system after a short discussionwith lead designer Cliff Bleszinski sparkedthe idea, and Jack implemented decals shortlybefore we shipped. It was this individual creativitythat ultimately bound the team together.Each new feature infused everyone with theenthusiasm to add more.Once the first batch of new player models,weapon models, and maps was completed werealized we had a game quitedifferent from UNREAL. Feedbackfrom the UNREAL deathmatchcommunity (includingthe highly vocal QUAKE community’scomplaints) alsodrove our designs. Subtlealterations to player movementand control changed thefeel of the game completely.Some changes in gameplay—such as whether toenable weapon-stay in singleplayer—were controversial, sowe held polls on popularUNREAL message boards.Throughout the spring andsummer of 1999, Epic waspursuing contract renegotiationswith GT Interactive.Everyone believed the gamecould ship at any time, sodevelopment became stopand-go.We would be in acode lockdown one week and

Epic Games’ UNREAL TOURNAMENT 94adding major new features thenext. The result of this jarringdevelopment cycle was good andbad. The periods of code lockdownallowed us more time toplay-test and fix bugs, which contributedgreatly to the game’soverall polish. On the other hand,it prevented us from adding manyfeatures that would have otherwisebeen included, and it wasdetrimental to the morale of theteam. We liked working onUNREAL TOURNAMENT, but it stillfelt like old technology to us. Theworld had seen the Unreal engine;we were ready to move on.New Code, NewFeaturesA close-up shot of the Black Thunder skin on Shane Caudle’sMale1 model. This was one of the first new skins developedfor UNREAL TOURNAMENT.As it turned out, though, we had a lot of time toenhance the engine. UNREAL was before its time,and a lot of the content and code was rushed bythe need to ship. With UNREAL TOURNAMENT,the team had a lot of time to use previouslyunexplored engine features. Erik de Neve’s levelof-detailcode ended up really speeding the gameup, giving us room for beefier characters andmore map decorations. Early on we experimentedwith using 16 256×256 textures perplayer, but opted for three or four 256×256pieces out of memory considerations. This quadrupledthe detail available to our skin artistsfor the player models. Reserving one of the256×256 textures for the head alone allowed usto mix and match body skins with heads, yieldinga massive amount of customization withonly a small amount of work. Another one ofthe 256×256 textures was reserved for teamcolor bits, so that a player skin could encompassall five possible team colors (none, red, blue, yellow,green) without too much memory use.Level design didn’t stand still either. Changingfrom single player to deathmatch-orienteddesign was refreshing for the designers, but notwithout its unique challenges. One issue was thetask of balancing the number of “hardcore”maps with “theme” maps. A hardcore mapfocuses entirely on layout and game play, whilethe overall style of the map comes second.Theme maps, on the other hand, focus on a unifyingidea or look and build from that. Forexample, the Koos Galleon, designed by PanchoEekels of Digital Extremes, is a large sailing

95SECTION II: SEQUELS AND SOPHOMORE OUTINGS95ship. It’s a very beautiful level, but focuses onthe theme of being a ship more than being adeathmatch map. The UNREAL TOURNAMENTteam decided that mixing the two styles was thebest approach.While most magazine reviews have expressedfrustration at the theme-oriented maps, wedidn’t want to appeal to only the hardcorecrowd. Including mapsthat were designed fortheir look and feelincreases the game’sinterest to average playerswho aren’t skilledenough at the game tobenefit from hardcoredesigns. Realism throughtextures and architectureis one of the Unrealengine’s strengths and itwas critical that weexploit that strength.Ultimately, we shippedUNREAL TOURNAMENTwith somewhere around45 to 50 maps, offeringmore than enough varietyand replay value foreveryone.Epic hired severalextremely skilledcontractors to assistwith art production.This is an extremelydetailed female skinby Steve Garofalo.Another task we facedwas choosing which ofUNREAL’s weapons tokeep and which to ditch.UNREAL TOURNAMENThas two firing modes,which makes designing a weapon like designingtwo weapons in one. UNREAL’s stinger and dispersionpistol were not needed in UNREALTOURNAMENT. Those weapons were good inUNREAL, because a player needed to start withsimple, weak weapons and build up. In UNREALTOURNAMENT, all the weapons had to beequally effective and carefully balanced. Aplayer good with the minigun needed to belethal with it. A player good with the pulse gunneeded to be lethal with it. Eventually we settledon the current load-out, but made quite a fewgameplay changes to the weapons that stayedfrom UNREAL. Each weapon was also given amuch more beefed-up look and sound.In the End,It All Worked OutWhile the talents and devotion of individualteam members created the content, the overallteam spirit tied it together. UNREAL TOURNA-MENT’s design process was often reckless, butthe game that resulted is nevertheless very polishedand a hell of a lot of fun. The deathmatchfocusedfirst-person shooter doesn’t need astory, dialogue, or scripted sequences, which areall features that more or less require an organizeddesign. Had we applied our hodgepodgedesign approach to a more focused genre, weprobably would not have had such a successfulgame. UNREAL TOURNAMENT should not beseen as a lesson in how to design a game, but asa lesson on how to organize a small team ofdevelopers.

What Went Right1. Smart internal marketingteamAt the front of Epic’s public relations wereMark Rein and Jay Wilbur. Their job was particularlydifficult during the development ofUNREAL TOURNAMENT. The media perceived usas impossible upstarts, takingan engine with terriblenet-play and attempting tocompete against id Software,the industry multiplayerchampion. BothMark and Jay fought hardto win over supporters inthe online and magazinepress. Mark made sure thatthe team stayed professionaland that everyonewas saying what he neededto be saying. Jay hunteddown potential engine licensees,and helped establisha level of curiosity amongthe community and media.UNREAL TOURNAMENTwas able to garner significantmagazine coveragebecause of the ongoing“QUAKE killer” debates.Mark and Jay worked toturn the initially negativeUNREAL TOURNAMENT’s deathmatchmaps were not constrained to any oneparticular theme or timeframe. CliffBleszinski’s DM-Barricade, shownabove, is a castle floating above astorm, while Pancho Eekels’DMGalleon is a massive ship sailingthe ocean (bottom).Epic Games’ UNREAL TOURNAMENT 96public response into something positive. Whilewe felt that our game would definitely stand onits own, we had to ensure that the positives werebeing clearly broadcast. Epic was very careful toavoid mentioning QUAKE 3: ARENA wheneverpossible, keeping the focus solely on UNREALTOURNAMENT’s features and staying away fromcomparative previews.Most interviews and previews would ask us theinevitable “What about QUAKE 3?” question, towhich we tried to answerwith complete respect forid’s project. Everyone knewthat UNREAL TOURNA-MENT and QUAKE 3 wouldbe pitted against eachother. Mark and Jay establishedvery early on that thecompetition would befriendly.2. Liberalinternal structure,open designdiscussionThe laid-back environmentthat both Epic and DigitalExtremes fostered greatlyenhanced the quality ofUNREAL TOURNAMENT.Everyone was free to suggestor implement an idea.Programmers had as muchdesign freedom as anyone

97SECTION II: SEQUELS AND SOPHOMORE OUTINGS97else on the team. Cliff Bleszinski (Epic) andJames Schmalz (DE) were the lead designers oftheir respective companies and served as contentfilters. They worked towards focusing the ideasput forth in the meetings. In addition, both ofthem contributed significantly to the final gamecontent. James designed two of the player modelsand created many skins and faces, while Cliffdesigned many of the game’s best maps.kept small. The open hours often saw teammembers working a 24-hour day, sleeping on acouch for six hours, and then working another24-hour day.In addition to fostering a hardcore work ethic,the system created a sideways information flow.A programmer would go straight to the artist heneeded something from, instead of through anart director. The fast communication allowedthe programmers to stomp out bugs relativelyquickly and the level designers to talk directly tothe texture artists. An example of this was thesingle-player ladder system. Shane Caudledesigned the art and I wrote the code. The fewerpeople we had to consult in order to completethe task meant a much faster turnaround.Everyone participated in giving the “coolnessfactor” thumbs-up or thumbs-down, but theactual development process was intentionallykept thin.After the release of UNREAL TOURNAMENT, the Epicteam started working on a free bonus packcontaining additional models. These are conceptdrawings of the Skaarj Warrior model for the pack.Team members were allowed to come into workwhen they wanted and stay however long theyfelt like being there. The only requirement wasthat every member attend a weekly design andfocus meeting. This system worked because Epicwas very careful to hire mature, dedicatedemployees and the core development team was3. Direct communication withthe gaming communityNearly every Epic and Digital Extremesemployee frequented message boards dedicatedto the subject of UNREAL and UNREAL TOURNA-MENT. The majority of Epic employees weredrawn directly from the gaming community,either through mod projects or independentgame work. Keeping in contact with the gamingcommunity allowed Epic to focus on the targetaudience during the design process. Beyond ourdirect communication with the UNREAL community,we also trolled QUAKE 3 message boards,reading the discussions of the fans of our leadcompetitor’s game. Learning what people liked

Epic Games’ UNREAL TOURNAMENT 98in a first-person shooterand why they liked ithelped us change themarginal multiplayerexperience in UNREAL tothe much faster pacedgameplay in UNREALTOURNAMENT.The gaming communitycan really help set thetone for your game.When UNREAL wasreleased, the online communitybecameextremely vocal andangry about the state ofthe net play. While mostmagazines had reportedpositive experiences with UNREAL’s single-playermode (reflected in positive reviews), the mediaeventually came to reflect the cries of the hardcoregaming community. This was in partbecause the net play was poor, but also due tothe fact that many members of the gamingmedia are themselves hardcore game playersand visit those same message boards and communityoutlets.We also learned that while the hardcore communityis very vocal, it is also relatively small.Designing a game to appeal to that communityalone is a critical mistake. Early in 1999 westarted work on tutorials for each game type.The tutorials are far from definitive, but theydid cover the basics of playing a 3D shooter.Testing on the parents and grandparents of teamIn the Assault game type, players have toenter a heavily defended base andcomplete map-specific objectives to win.Assault was the most difficult UNREALTOURNAMENT game type to design,balance, and play-test.members demonstratedthat the tutorials wereuseful for attracting andkeeping new players.This community-mindednessgreatly contributed tothe quality and completenessof UNREAL TOURNA-MENT. We had a verygood idea of what playerswanted. As I mentionedearlier, we often postedcontroversial design questionson public messageboards to gauge publicreaction. The results ofthese polls were taken intoconsideration when thefeature in question was implemented.4. Strongly object-orientedengine designThe Unreal Tournament engine’s strong objectorienteddesign makes it extremely modular.This modularity allowed our programmers tomake massive changes to parts of the gamewithout affecting other features. Each subsystemis connected to other subsystems througha clearly defined interface, and platform-specificcode is consigned to separate libraries. Creatingthe Linux port, for example, was simply a matterof rewriting an input and sound device andwriting a Linux version of the platform-specificlibrary behavior.

99SECTION II: SEQUELS AND SOPHOMORE OUTINGS99Throughout UNREAL TOURNAMENT’s development,Tim Sweeney and Steve Polge worked onimproving the networking code. The modularityof the engine meant that their work didn’t disturbanyone else’s work. Some features, such asJack’s decal system, were added very late in theproject. The decal system added a lot of depthand feedback to the game, and took less than aweek to get working and fully debugged. Erik deNeve’s mesh level-of-detail code touched only ahandful of source files. This ease of use is alsoreflected in the engine’sscripting language, Unreal-Script. Calling it a scriptinglanguage is a misnomer; it’sactually a lot like Java.Weapons, pickups, levelevents, AI nodes, and otherworld actors are all independentobjects.A weapon can be added tothe game without touchingany source files but the newobject definition. Thishighly extensible languagemeant that each programmercould add extensivenew game-play features with a very limited setof potential side effects. In the end, 90 percentof UNREAL TOURNAMENT’s game-play code waswritten in UnrealScript.The Unreal Tournament engine’s modular packagesystem coupled with UnrealEd makes thegame a mod-creation system out of the box. Wedesigned a lot of our code with amateur extensionin mind. Everyone at Epic recognized thevalue of the mod community and we wanted tomake the game attractive to new artists and programmers.Constructing game code in this waymade it much easier for us to prototype our ownnew features. Early UT weapons and pickupswere child objects of UNREAL. The two gamescan easily coexist even now.5. Good timingSteve Polge, our AI and game playprogrammer, made the botsunderstand the unique advantagesand disadvantages of each weapon.Here a bot is moving in very close touse the powerful Flak Cannon.As I said earlier, UNREAL TOURNAMENT wasdeveloped in the same timeperiod as id Software’sQUAKE 3: ARENA. The twogames promised to be ofthe same genre and the twocompanies were known fora high level of competition.While we tried to avoid the“QUAKE 3 vs. UT” comparisons,they ultimatelyworked in our favor. Thehigh level of public interestin the new engine wargreatly increased our visibility.Magazines and Websites often posted split previewsinstead of focusingon one game in particular. Interviews with idemployees would always lead to UNREAL TOUR-NAMENT questions and vice versa.UNREAL TOURNAMENT took almost exactly ayear and a half to develop, giving the team a lotof time to pack in features. We didn’t have tofocus on writing an engine from scratch, so wewere free to focus entirely on improvements. Atthis point, we’ve released three patches for

Epic Games’ UNREAL TOURNAMENT 100UNREAL TOURNAMENT that have solved ahandful of relatively minor problems. The teamhas had a lot of time available to spend on addingeven more features to the game since itsrelease, instead of fixing outstanding issues. Bythe time this article hits the stands, we’ll havereleased our first bonus pack: a free collectionof new models, maps, and game-enhancing features.What Went Wrong1. Bad timingMany aspects of the game’s timing workedagainst us. While the QUAKE 3 vs. UT hypeincreased our exposure, it also set a very harddeadline for completion. It was critical that wecomplete the game before QUAKE 3 wasreleased. The media advantage belonged to idand we believed that if UNREAL TOURNAMENTlaunched after QUAKE 3, we would be forgottenin the storm. At the same time, however, wewere caught up in grueling contract renegotiationswith GT Interactive. We did not want todeliver the completed game until we knew thecontract would work in our favor. Many timesduring the development of the game we werepromised that a resolution to the contract issuewas close at hand.The team would race to reach a point where thegame could be shipped, only to have negotiationsdrag on. The gold master was delivered toGT days after a final contract was agreed upon.Unfortunately, the game hit shelves in November,pushing us very close to QUAKE 3’s releasedate. While UNREAL TOURNAMENT often performedbetter than QUAKE 3 in reviews, webelieve that sales would have been much higherstill had we released in October. Word-of-mouthis a powerful force and the extra month wouldhave given us time to build a larger communitybefore Christmas.2. No central design documentWhile I am a big supporter of open, cabal-styledesign, I have to stop and wonder how UNREALTOURNAMENT would have turned out had we astrong initial design. It’s quite possible that thegame’s weaker elements would have been muchstronger if we had put together some concept artand focus material. In reviews, we have beencriticized for not having enough variation incharacters. If UNREAL TOURNAMENT had had alibrary of concept art to draw from, we mighthave had more interesting alien warriors. Thestory is more or less nonexistent in UNREALTOURNAMENT, but at times we considered havingin-game cut-scenes as rewards for a player’sprogress. The idea was dumped, but a designdocument might have made it easier to visualizethose scenes.I suppose this isn’t really a “what wentwrong.” It’s simply more of a “what we shouldhave done.” I think it’s important to thinkabout the game in that light. UNREAL TOURNA-MENT is a very fun game with a lot of featurespacked into a short amount of developmenttime. Those features were largely addedthrough spur-of-the-moment decisions. A moreunified approach to design would have allowedus to construct features that play on features,

101SECTION II: SEQUELS AND SOPHOMORE OUTINGS101or even think of ideas we didn’t have the perspectiveto realize.Epic will always be a very open, liberal companywhen it comes to the design process. If wedevelop a design document, we’ll use it with theunderstanding that it can be modified at anytime. That having been said, I think there is adefinite positive argument for having some sortof central guide to everyone’s ideas. Having theability to sit down and look over the big pictureis very valuable.3. Co-development across twocountriesEpic Games and Digital Extremes co-developedUNREAL TOURNAMENT. The Digital Extremesteam was located in Canada and Epic waslocated in the U.S. Epic supplied the programmingteam and a large group of content designers.Digital Extremes provided level designers, asound guy, and texture artists. James Schmalz,the high-up man at Digital Extremes, contributedtwo of the game’s player models and a lotof art. This co-development worked well forthe most part, but near the end of the project itbecame very difficult. During UNREAL, Epicteam members flew to Canada to work at DigitalExtremes’ offices. With UNREAL TOURNA-MENT, it became Digital Extremes’s turn to dothe traveling. Unfortunately, flying and drivingback and forth every couple of weeks is a verydraining experience. Many of the DigitalExtremes team members spent several weeksaway from their wives and girlfriends. Near theend of the project, they grew increasingly frustratedwith the situation.To compound this problem further, DigitalExtremes and Epic were attempting an expensivemerger. As UNREAL TOURNAMENT came to aclose, it became clear that the merger would nothappen. It was prohibitively expensive for asmall company to move across the border. ManyDigital Extremes team members already hadapartments and plans for living in Raleigh, andthe news of the terminated merger process wasdevastating.Much to Digital Extremes’s credit, the companyquickly recovered and moved to its backup planof developing its own game with the UnrealTournament engine. Nonetheless, the process ofco-developing the game had taken its toll oneveryone. The ups and downs of the merger processhad a negative effect on team morale. Hadthe co-development happened between companiesmore closely situated, it would not havebeen a problem.UNREAL TOURNAMENT used from three to four256×256 textures per model. This allowed us tofocus a lot of detail in the head and face area.Within the game a player can choose a skin andthen swap through several different faces.

Epic Games’ UNREAL TOURNAMENT 1024. Not enough artistsOn the content side, UNREAL TOURNAMENTwas held back by the number of available artists.Epic’s artist, Shane Caudle, is a supremeJack-of-all-trades, creating skins, models, andlevels of the highest quality. He spent most ofhis time working on new player models andskins for those models. Digital Extremesbrought a few texture artists to the table, butnot enough to create the huge libraries of newtextures needed for the game. In order to supplementthe skin and texture production, Epicturned to contract artist Steve Garofalo.Even with the additional help from externalsources, the team was unable to produce enoughnew textures. Level designers who wanted customtextures for their maps had to make dowith their own texturing ability. While the finaltexture and level count in UNREAL TOURNA-MENT is quite high, the levels would have beenmuch more impressive had the team been ableto act with full freedom. Since the completion ofUNREAL TOURNAMENT, Epic has hired bothSteve Garofalo and John Mueller to strengthenthe art team for future projects.5. Visual Basic editor interfaceThe Unreal Tournament engine uses UnrealEdas its level design and content management tool.For several years, UnrealEd has used a windowinginterface written in Visual Basic. The VBcode is fragile and very old. Add to this the factthat nobody at Epic except Tim Sweeney knowsor cares about VB, and you have a level designteam that is stuck with a tool that’s not easilyupdated. Several interface bugs have plaguedUnrealEd for some time and nobody on theteam had the time or inclination to fix them. Ifwe had a more easily extensible tool, the teamwould have been able to add extra features tothe editor for level designers to use. As it stood,the editor was considered “off limits” for newfeatures.Where We Go fromHereThe things that went wrong are, all in all, muchless significant than what went right. UNREALTOURNAMENT could have benefited from amore focused initial design and a more solidship date, but it turned out to be very polishedand a lot of fun. Many of the factors thatworked in our favor, like timing, also workedagainst us to some extent. “What went wrong”is a good way of looking at what we could havedone to make UNREAL TOURNAMENT even better.UNREAL TOURNAMENT served as a good learningtool for the team. We have a good idea ofwhat processes we need to adopt to producelarger, more story-driven games in the future.We see UNREAL TOURNAMENT as a good lessonin how to organize a team and produce a gamein a short amount of time. The team has grownsocially, and everyone is much more experiencedin the process of game development. We feelvery prepared to face the upcoming challengesand, hopefully, to continue to be seen as innovatorsin the industry.

103Westwood Studios’TIBERIAN SUNby rade stojsavljevicEver since the release of Westwood’s DUNE 2 in1992, real-time strategy (RTS) games havebecome the hottest-selling computer gamesaround. Countless RTS games were releasedsoon afterward including COMMAND & CON-QUER (C&C), RED ALERT, WARCRAFT II, AGEOF EMPIRES, and TOTAL ANNIHILATION. Thesegames have propelled the genre to new heightsand have drawn an increasing number of fans.After the success of C&C and RED ALERT, theteam at Westwood Studios started work onTIBERIAN SUN, the sequel to C&C. To build theBack-StoryCOMMAND AND CONQUER is one of the widest-sellingseries of all time for the PC, a real-time strategy gameset in a future history of Western allied nations, terroristcults, and rogue mutants. Like any good sequel, TIBE-RIAN SUN took the familiar formula up a notch with newunits, improved AI, and cinematics starring big-moneyactors, such as James Earl Jones.game, we assembled a team that consisted ofveterans from C&C and RED ALERT along witha couple of new faces, including me. We startedwith the goal of taking what made C&C funand expanding it even further. To begin thedevelopment process we reviewed what makes agreat RTS game and came up with one answer:tactics. Westwood doesn’t build games based ona specific technology and we never sell technologyover the game play. We have a firm beliefthat a great strategy game must have interesting,fun, and new tactics that afford players a multitudeof unique ways to play a game. We wantedTIBERIAN SUN to appeal to a broad audience, yetalso appeal to core game players and fans of theseries.Towards this goal, we continued to apply a“wide and deep” approach to designing the tacticswe created. Wide and deep essentially meansa nice assortment of diverse yet readily apparent

Westwood Studios’ TIBERIAN SUN 104tactics that, under the surface, contain an evengreater number of tactics. With this approach,you can provide first-time players with a numberof different things to do while letting moreexperienced players discover new and advancedtactics on their own. These design goals madeworking on the game more challenging—as ifGame DataRelease date: September 1999Genre: real-time strategy; science fictionIntended platform: Windows 95/98/NT 4.0Project length: 36 monthsTeam size: 25 full-time, 15 part-time developersCritical development hardware: Pentium Pro andPentium II machines, 200 to 450MHz dual-processorwith 128 to 256MB RAM,Creative Labs sound cards, Windows 95/98/NT, SGI02 workstations, BlueICE acceleratorsCritical development software: Microsoft VisualC++, Lightwave, 3D Studio Max, Discreet Flint, AdobePhotoshop, Adobe After Effects, Adobe Illustrator, AvidMedia Composer, Filemaker Pro, Deluxe Paintbeing the biggest project in Westwood Studios’history wasn’t enough.What Went Right1. Maintained C&C style ofgame playOne of the most difficult tasks we had to overcomeduring the development of TIBERIAN SUNwas to maintain the feel of the original. Whenmaking a sequel, the question that always has tobe answered first is, How far do you stray fromthe original game to make it compelling, yet stillfamiliar? The intent with TIBERIAN SUN was tomaintain, as much as possible, the feeling of theoriginal while providing new and interestingtactics for players to master. To aid in this goal,when adding a new feature we asked the questions,“Is this consistent with COMMAND &CONQUER?” and “How can we make it easierand even more exciting?”In this area, it really helped to have a developmentteam that worked on the previous games.They were able to draw from previous experiencesto create a consistency in the gamedynamics. This gave the team a great deal ofindependence since everybody already had agood idea of how the game was supposed tolook, play, and feel. The main areas we focusedon in order to be consistent with previous gameswere the user interface and unit behavior. Weknew we had to keep the sidebar metaphor forunit construction, but we wanted to update it toaccommodate new features, such as unit queuing,waypoints, and power/energy control.For unit behavior there was a set of rules thatwe had to conform to, specifically how a unitdeals with player commands so that its internallogic never overrides a player’s orders. One ofthe times we tried to change the rules was whenharvester threat-avoidance logic was introduced.I remember hearing lead designer AdamIsgreen screaming at his computer when his harvestersrefused to obey his orders to retreat. Wedecided to scrap that idea shortly afterward.

105SECTION II: SEQUELS AND SOPHOMORE OUTINGS105It was important for theoverall visual presentationof the game to bear a resemblanceto its predecessors inorder to maintain a consistentartistic style. Wedecided to alter the perspectiveslightly, rotating thecamera to create a threefourthsisometric perspectivethat afforded a bettersense of depth and realismin a 3D perspective. It wasat this point that we decided not to use a polygonalengine since it wouldn’t be possible for usto keep the system requirements low enough toachieve the mass-market appeal that we wanted.Also, at the time we planned to release TIBERIANSUN, 3D accelerator cards and systems weren’tfast enough for us to maintain the visual detailwe wanted for the hundreds of units and structureson-screen at once.2. Working on a sequel to asuccessful franchiseConcept sketch of an Orcabomber.Being the fourth RTS game Westwood has done,there were a lot of lessons learned that the teamwas able to carry forward into TIBERIAN SUN.First, we had an established and streamlineduser interface. This user interface has been acornerstone of Westwood RTS games sinceDUNE 2, and we’ve been gradually improving itever since. Anyone who has ever played a WestwoodRTS is immediately familiar with the controlsand can jump right into the action.Additionally, the interface is simple and intuitiveenough to let new users become comfortablewith it in a short time.Another nice benefit of makinga sequel is that we had aset of basic features we knewworked based on previousgames. These provided asolid foundation that couldbe expanded upon and modifiedas needed.We started with featuresfrom the previous games thatwe knew we wanted andupdated them to fit a world that was 30 years inthe future. Tanks evolved into two-legged mechanizedwalkers, soldiers could now use droppods launched from space, and cloaking technologyadvanced to yield a stealth generatorthat hid many units and buildings at once.When it came time to create the story, wealready had the basic framework in place. Therewas a very rich and fascinating world to drawupon when creating new characters for thisstory. The one difficulty encountered was makingsure the story could stand up on its own andbe accessible to new players without subjectingplayers familiar with previous games to mindnumbingexposition. To solve this problem, weset the story 30 years after the end of the original,which provided an opportunity to create anoutstanding introduction that showed playerswhat had been going on in the world.3. Team experience andcohesionThe TIBERIAN SUN development team is one ofthe most experienced and professional teams

Westwood Studios’ TIBERIAN SUN 106I’ve ever had the privilege ofworking with. For many ofthe team members, this wasthe fourth RTS game theyhad done (the previous beingDUNE 2, C&C, and REDALERT). This level of experiencewas key in allowing theteam to conquer all theobstacles thrown in theirpath.Even though I had worked onhalf a dozen titles before Istarted on TIBERIAN SUN, atfirst it was a little unnervingfor me to be working with ateam of this caliber. Severalmembers of the programmingteam had worked together onprevious Westwood RTSproducts and were accustomedto each other’s codingstyles. New programmerswere quickly assimilated intothe team and were able to adapt well. The codingrules and Westwood libraries allowed theprogrammers to familiarize themselves witheach other’s work with minimal difficulty.Concept sketch of a GDI Titan.could produce missions. Thedesigners worked welltogether and were friends;something that helped a lotwhen there were differencesof opinion. It proved to bevery beneficial to know thatyou could argue your pointand not have to worry thatthe person you were arguingwith would hold a grudgeafterward.Without the technical knowledgeand creativity of the artistson the project, we wouldhave suffered a great deal ofpain when integrating artwork.Like most projects,TIBERIAN SUN had a specificset of technical criteria thathad to be satisfied when creatingart for the game engine.On this front, we reaped therewards of having artists whohad done it all before. They had worked withour programming team and knew the tools wellenough that they were able to head off potentialproblems before they could get out of control.The designers had worked on previous RTSgames and were very familiar with the universebefore we started the project. This saved severalmonths since no one had to familiarize themselveswith anything except the design for TIBE-RIAN SUN. The tools used were derivatives of theC&C and RED ALERT editors, which also minimizedthe ramp-up time required before theyThe cinematic artists had much of the sameexperience; they didn’t have as many technicalrestrictions as the in-game artists, whichallowed them to be able to express unbridledcreativity. The cinematic artists didn’t have todeal with frame limitations or palettes. Also,compared to previous games, the movie playerin TIBERIAN SUN allowed for full-resolution

Westwood Studios’ TIBERIAN SUN 108The whole process took about three months forTIBERIAN SUN, compared to six months forC&C and four months for RED ALERT. Evenafter the countless games we played against oneanother, we still got into shouting matches duringclose multiplayer games. When this happens,you know you’ve got a winner on your hands.5. Mission designMission design is one of the most important elementsof RTS games. Based on experience withprevious games, Westwood has established aseries of processes that are used whenever a missionis created. We’vedesigned these processesto foster creativity,maximizeefficiency, and promotecommunicationbetween the design,programming, art, andmanagement groups.This process has beenrefined on everyproject, and we’vetaken it to the nextlevel with the upcoming FIRESTORM add-on.The process begins with a mission design proposalsubmitted to the lead designer and producer.The proposal is a two- to three-pagedocument that contains summary informationabout the mission such as name, side, difficulty,map size, mission type, and so on. The missionbriefing is included along with a description ofwhat the briefing movie should be and all of thecritical information that must be revealed to theplayer. Mission objectives are listed as theywould appear in the game, along with specificinformation on how to achieve the objectives.Win and lose conditions are created, as well asdescriptions of the victory and defeat moviesthat play at the end of a mission. The last thingsincluded are all of the new voice and text messagesused in the mission.Once this proposal has been approved, the mapfor the mission is sketched out on paper. We’vefound that this process can save a great deal oftime since it eliminatesdistractions and allowsthe designers to get anoverall view of the mapquickly. When thedesigners finish sketchingtheir mission, theyproceed to the editorand begin to create thebasic battlefield. Terrainis laid down first,followed by buildings,A Nod obelisk of light incinerates its attackers. roads, trees, and pavement.The final step tocomplete a mission is to take a map and addscripting, which takes approximately two-thirdsof the time to create a mission. One of the greatthings about TIBERIAN SUN is that the editor istied directly into the game, which alloweddesigners to switch rapidly between the editorand the game. This feature also proved to be aliability, however, because if a bug appeared thatprevented the game from running, we couldn’trun the editor, either.

109SECTION II: SEQUELS AND SOPHOMORE OUTINGS109TIBERIAN SUN features a good blend of production(such as building bases) and nonproductionmissions that keep the pace of the game interestingand challenging. We tried not to do the samemission twice and added variety by combiningmission types into nonproduction/productionmissions that switch from one to the other whenplayers reach specific objectives. Branching missionswere added to give players the option ofcompleting sub-missions before they tackled themain objective. By playing sub-missions first,the player makes the final objective easier and itgave the designers added granularity when creatingthe difficulty levels for the game.What Went Wrong1. Unrealistic expectationsThe degree of hype and expectations that TIBE-RIAN SUN had to fulfill was staggering. We had ateam of experienced developers who wanted tobeat their own expectations while simultaneouslybuilding a gamethat would be everythingthe fans of the seriesexpected and more. Thiswas not a realistic goalsince it’s just not possibleto make something thatwill meet everyone’sexpectations. One of thethings that we did not dowas explore all of the newfeatures to their logicalconclusions. This wouldOn location at Red Rock, Nev. Chandra,McNeil, and Brink pose on the KodiakBridge.have allowed us to do a lot more with a smallerfeature set and provide an even better game.A perfect example of a feature that was beggingto be used more is the dynamic-battlefield concept.The basic idea behind the dynamic-battlefieldconcept is that players’ actions alter thebattlefield. For example, a player could set fireto trees to burn a path into an enemy’s base. Wewound up cutting this particular feature becauseit caused path-finding problems. Also, battleswith heavy weapons would cause cratering ofterrain which hindered unit movement. Wecould have used it to create more new strategiesfor players, and since it was one of the moreexpensive features in the game, we could havesqueezed a lot more use out of it.Trying to fill the shoes left behind by RED ALERTproved to be daunting. If you had asked a dozenpeople what they expected out of TIBERIAN SUNbefore it was released, you would have heard adozen different answers. We devoted a lot ofeffort to add as many features into the game aspossible instead of just trying to make the bestgame we could. Gettinginto a feature war is oneof the worst things thatcan occur during developmentbecause it siphonseffort away from addingthe “fun” to the game.2. Feature creepTIBERIAN SUN startedstrong and we developeda robust and large feature

Westwood Studios’ TIBERIAN SUN 110set we intended to fulfill. The project startedsmoothly, but as we progressed, the temptationto add new features not included in the designdocument grew. These features arose out ofshortfalls in the original design, omissions fromthe original design, and input from fans. Everybodystresses the importance of working off of adesign document and not deviating from it.Unfortunately, this just isn’t realistic since everyproduct evolves during thecourse of developmentand sometimes the originaldesign proves to belacking. A team has to beable to incorporate newideas during developmentif the final project is to bebetter. However, the flipside of this idea is that theteam must be able to cutfeatures diplomaticallywhen it is in the best interest of the project.TIBERIAN SUN‘s development had many challengingmoments when features had to be cutfor one reason or another. A perfect example ofthis was the ability to order a limited number ofunits through a drop-ship loading screen beforea mission. This sounded like a great idea onpaper and we had already coded it and incorporatedit into the game. It wasn’t until we actuallyplayed with it that we realized it just didn’t fitand had to be removed.Looking back at the project, I think we couldhave been more aggressive in cutting or changingcertain features to make sure their returnswere really worth the development investment.I’m a firm believer in the idea that less is moreand that fewer but more fully developed featuresare the way to go. If a feature isn’t amazing,you should cut it or make damn sure itbecomes amazing before you ship the product.3. Post-productioncomplications, compositing woesTIBERIAN SUN features themost complex and highest-qualitycinematicsequences Westwood hasever done. These movieshelp drive the story elementsforward. However,these movies came at avery high price. Westwoodhas a soundstageUmagon prepares for a take.with a bluescreen and inhousepost-productioncapability that allowed us to handle the entireproduction ourselves. We’ve done several differentprojects with video, including RED ALERT,DUNE 2000, and RED ALERT RETALIATION forthe Playstation.Based on these past experiences, it was decidedthat we would push the limits of what we coulddo in TIBERIAN SUN. We started by fully storyboardingevery scene in the script. From the storyboards,we built concept sketches of the majorsets to be constructed (practical as well as computer-generated)and proceeded to build the setsBefore the shoot there was a three-month leadtime for our team of six 3D artists to build thesets. We wanted to have the sets 100 percent

111SECTION II: SEQUELS AND SOPHOMORE OUTINGS111complete so we would have camera and lightinginformation to match up with the live actors.For various reasons, the pre-production forTIBERIAN SUN was much shorter than it shouldhave been. If you’ve ever worked in film or televisionproduction, you’ve probably heard thephrase “we’ll fix it in post.” Believe me when Isay there’s a reason why this little phrase canspook even the most veteran members of anyproduction crew. Anythingyou have to fix after the factwinds up being ten times asdifficult and ten times moreexpensive than planning forit in the first place. Everybodyon the team knew this,and we tried as hard as wecould to work out all thedetails before we started theshoot. The problem was wedidn’t have enough time andcouldn’t change the date ofthe shoot because wewouldn’t have been able toget our two main actors,James Earl Jones andMichael Biehn.Going into the shoot, wehad a pretty good idea ofhow we were going to workout all of the technical details such as cameratracking on a bluescreen, matching lighting tocomputer graphics, compositing, and so on.However, we ran into difficulties because wedidn’t allow enough time for the more complexshots and were forced to edit on the fly duringConcept sketch of a GDI carry-all.the shoot. An unforeseen problem during thepost-production was that we dramaticallyunderestimated the storage and networkrequirements of working with 60 minutes ofdigitized video. Westwood has a very robust andfast network with a large amount of storagespace, but it was never designed to meet theneeds of video post-operation. An amazingeffort by the MIS staff and a couple of called-infavors got us enough storage space on the networkto keep going.From the start, the teamstruggled to get video fromdigital beta to the SGI– andPC–based compositing systems.Footage was digitizedon an Avid system and copiedto file servers for distributionto the PCs. The SGIsgrabbed the footage directlyfrom tape using built-in digitizinghardware. From thecompositing stations, variousshots were completedand transferred back to a fileserver to be compressed andput in the game. This, alongwith the fact that many individualscenes were workedon by several artists, multipliedthe storage requirementsseveral times over.In the end, the video assets were spread acrossfour separate file servers and took up well over500GB of space. Not only was space a problem,but moving hundreds of megabytes of files a day

Westwood Studios’ TIBERIAN SUN 112from machine to machine became a bottleneck.A few minutes here and there to transfer filesdoesn’t sound like much until you add it all up.If we had it to do over again, we could havealleviated the problem by building a very specialized(and expensive) network, by gettinghardware that allowed artists to digitize theirfootage directly from tape, or by reducing thescope of the project and sidestepping the problementirely.The only option available was to redesign themissions or add text to the missions to make theobjectives clearer. Redesigning the missionswould have added at least a month to thealready late schedule, so we quickly ruled thatoption out. We wound up going with text thatpopped up in the missions, although the originaldesign called for all text in the game to beaccompanied by a voice-over.4. Locked documents too earlyOne of the side effects of schedule slippage wasthat we locked our documents too early in orderto achieve the localization plan. We knew thiswas going to wind up causing us significantpain, but at the time there was nothing we coulddo to avoid it. The result turned out well, but alot of time and effort was spent to make everythingwork together. At the point when welocked the audio script, mission design and balancingwere not complete. As we playedthrough the missions, we realized that certainobjectives were not clear and needed to beexplained further.The previous method for doing this was to havethe in-game AI persona (Eva or Cabal) relay theinformation to the player through voice cues.This was not an option for TIBERIAN SUN, however,since we made the switch to professionalvoice talent for Eva and Cabal. Costs and schedulingdidn’t allow us to do as many pickuprecording sessions as we wanted. Also, thelocked audio scripts were already localized andrecorded, which made recording additional linesout of the question.Nod laser turrets repel a GDI horde.5. Scheduling problemsAs with most projects in development today,TIBERIAN SUN suffered from scheduling problems;ours resulted in a nine-month delay. Therewasn’t a single reason that caused the productto be delayed, but rather a series of seeminglyminor contributing factors. Brett Sperry has arule of thumb that we often refer to when schedulingprojects. When you add one fundamentalnew technology to a project, it can cause slippageup to 90 days. When you add two fundamentalnew technologies it can add a year to theanticipated release date. When you add three ormore new technologies it becomes impossible topredict the release date of the project accurately.

113SECTION II: SEQUELS AND SOPHOMORE OUTINGS113An Orca carry-all transports ahover MLRS.TIBERIAN SUN features threenew systems that resulted inan unpredictable schedule.First, we switched our coregraphics engine to an isometricperspective in order toenhance the game’s 3D look.This resulted in a cascadeeffect of broken systems thatweren’t anticipated. Bridgesthat could be destroyed andrebuilt, for example, woundup taking over ten times aslong to program as we originallyestimated. Adding bridges complicatedsystems such as path-finding, Z-buffering, rendering,unit behavior, and AI. Scripting wasanother area in which we added a slew of newfunctionality.We added an increasing number of triggers tothe game to allow the designers flexibility in creatingthe missions. Each new trigger added wasmore specific than the last and was used forincreasingly rarer conditions. Since triggerscould be used in combination, we ended up withan overwhelmingly large number of events thatneeded to be debugged. We would often fix onetrigger to work in a specific situation and inadvertentlybreak the same trigger in a differentsituation.AI and unit behavior was the third main areathat used new technology. We set out to create achallenging and fun AI that could react to theplayer’s actions and change tactics to compensate.We should have focused on fewer areas ofthe AI instead of trying to redesign the wholepackage from the ground up.Overall TipsWith TIBERIAN SUN, we builtthe game we originally setout to build over three yearsago. Almost all of the newengine features we designedwere implemented in thefinal product, and manymore were added along theway. We built a game that isas easy to play as its predecessorwhile offering up lotsof new units featuring interestingtactics. All of this was done while keepingthe system requirements low enough to run onmost systems: a 166MHz Pentium with 32MBRAM and a 2MB video card. We learned, orrelearned actually, a few more things aboutmaking RTS games that weren’t listed above.They are:• If the game has Internet or multiplayercapability, build this functionality as soonas possible since it will let you get into thegame and balance it early.• Don’t shield yourself from reality. If yourgame supports Internet play as well asLAN play, don’t play only LAN gamesand assume that Internet performance isacceptable.• Keep the story tightly focused on players’actions and don’t treat the story as a separateentity. Remember that the player isalways the main character.

Westwood Studios’ TIBERIAN SUN 114• Wherever possible, try not to mix disparatetechnologies (3D visual systems with2D, for example) that have inherent problemsworking together. Instead, go backand modify the design.After three years of working on TIBERIAN SUN,it was a great feeling to finally finish the gameand see it on the shelves. No matter how manyproducts you ship, that feeling never goes away.TIBERIAN SUN broke Electronic Arts’ salesrecord for the fastest-selling computer game inthe 17-year history of the company with morethan 1.5 million units sold so far. But best of all,the team is proud of the product they createdand can’t wait to get started on the next one.

115Ensemble Studios’AGE OF EMPIRES II:THE AGE OF KINGSby matt pritchardCatching UpTwo years ago in this very column (You canread the original AOE article on page 63.) I toldyou the story of Ensemble Studios, a scrappyupstart that overcame challenges to create thegame AGE OF EMPIRES (AOE). Since its releasetwo years ago in the great real-time strategy(RTS) wars of 1997, approximately three millioncopies of AOE have been sold worldwide,along with almost a million copes of the RISEOF ROME (ROR) expansion pack. The totalsdon’t give the whole story, though. AOE provedto be a consistent seller, hanging around the topof the PC Data charts, and even re-entered thetop ten a year-and-a-half after its release. Thedemographics of the buyers were another surprise.Sure, we had the sales to the 14- to 28-year-old male hard-core players, but we alsohad significant sales to older players, women ofall ages, and casual game players of all sorts.That is to say, we had a crossover hit on ourhands.Back-StoryAGE OF KINGS advances the historical timeline begun inthe first AGE OF EMPIRES, encompassing the thousandyears from the fall of Rome through the Middle Ages.Meanwhile nearly every aspect of the game wasupdated to deliver a worthy sequel—graphics and AIsaw improvement, and new units, technologies, andgame modes were added.If you have ever watched the VH1 show Behindthe Music, then you know the story of theupstart band that finds itself suddenly on top ofthe world—things change, and not always forthe better. I wouldn’t go so far as to say that wesank into a wild orgy of sex, fast cars, andmoney—despite the wishes of a couple of ourguys—but this change along with the benefits ofsuccess brought us a whole new set of challenges,making our next game no easier than thefirst.Designing a SequelIt was a surprise to no one that Ensemble Studios’next game would be a sequel to AOE,although most people probably didn’t know

Ensemble Studios’ AGE OF EMPIRES II: THE AGE OF KINGS 116that we had a contract with our publisher for asequel long before the original game was finished.Given our historically-based themes andtime periods in AOE, the chosen time period forAGE OF EMPIRES II: THE AGE OF KINGS (AOK),the Middle Ages, practically picked itself. Thatwas the only easy part, however.Like a band going back into the studio after ahit record, there were differing opinions of whatGame DataRelease date: October 1999Publisher: MicrosoftGenre: real-time strategy; historicalIntended platform: Windows 95/98/NTProject length: 24 monthsTeam size: 40Critical development hardware: Pentium II 450128MB, Dual Xeon 450 512MBCritical development software: Visual C++, 3DStudio Maxdirection to take next. Do we play it safe andstick tightly to the AOE formula, or do we getbold and daring and take the whole game genrein new directions? This is the million-dollarquestion every successful game is faced withwhen the topic of a follow-up is raised. But thesuccessful band I’m using as an analogy is fortunate.They don’t have to contend with the unbelievablyrapid pace of evolution in PC hardwareand games.Improvements to the game in every area fromgraphics to user interface are expected in thisbusiness as a matter of fact. Expectations can bea bitch sometimes. Take the vast demographicsof AOE players that I mentioned earlier—theyare the largest group of people most likely tobuy the sequel—and everyone is concernedabout making sure that this huge and diversegroup will like the next game so much they willrun out and buy it. We’ll just do more of whatwe did right in AOE, we said. That soundsgreat, but it’s almost impossible to quantify in ameaningful, detailed way. The game business isbrutal to those who fail to move forward withthe times, but it’s also equally brutal to thosewho experiment too much and stray from theexpectations of the players.When we started work on AOK, we thoughtthat we could make use of our existing code andtools, and that this would make the sequel easierto create than the original. Filled with theseoptimistic thoughts, we concluded that we coulddevelop AOK in a single year. This was alsogoing to be our opportunity to add all thosedream features and make our magnum opus ofcomputer games. So we set about to do justthat. To make enhancements for AOK, we hadpulled together a giant wish list of features andideas from inside and outside sources. To thegame design we added all sorts of neat new featuressuch as off-map trade, renewableresources, combat facings, sophisticated diplomacyand systems of religion, and so on. Ofcourse, the art, sound, and game content werealso going to be bigger and better and bolderand brighter and…well…you get the idea.Several months down the road, reality reared itsugly head in big way: we had bitten off more

117SECTION II: SEQUELS AND SOPHOMORE OUTINGS117than we could chew and the game’s design waslosing focus. Instead of sticking to the core ofwhat makes an RTS game great, we had goneoff in many contradictory directions. Alongwith that came the realization that there was noway that we were going to finish AOK in a singleyear and have it anywhere close to the qualityof AOE. This was a sobering time forEnsemble Studios staff and our publisher,Microsoft. While the EnsembleStudios crew adjustedquickly, it caused a few problemsfor some of the people atMicrosoft: “Uh, guys, we’vealready gone ahead and committedto our bosses that wewould have another AGE OFEMPIRES game this year,” isprobably a good way to paraphraseit.From this situation, a contingencyplan was born. We weregoing to take another year tofinish AOK, giving us time toget the game back on trackand to create the ambitiouscontent for it. We also had aplan to help our publisher out: we would createan in-house expansion pack for AOE. It wouldbe a significant addition to the game, yet requireonly a small amount of our resources, and mostimportantly, it would be ready in time forChristmas 1998, taking the slot originallyplanned for AOK. Thus was born the RORexpansion pack. ROR helped, but it didn’t takeall the pressure off us. Unlike the latitude wehad with AOE, which had also come out a yearA Turkish mosque shows off thegreater detail and improvedskills of our art staff.late, our new deadlines for AOK were very firmand hung over us the entire time. The pressurewas very much on.What Went RightWe did what it took to makeAOK a triple-A game. Whilethe decisions to take an extrayear and reset the units to anAOE baseline were tough inthe short term, they were theright decisions to make. Thecommitment of Ensemble Studiosto exceed the quality ofits prior games never wavered.To realize our goals, we addedthe additional programmers,artists, and designers that weneeded. When we needed tostop, take a hard assessmentof what we were doing, andkill our own children if needbe, we did just that. Wepushed ourselves hard and wecame together as a team.1. Addressed the majorcriticisms of the first gameDespite AOE’s success and generally glowingreviews, there were two things about the gamethat were repeatedly criticized: the artificialintelligence of the computer players and thepathfinding and movement of units. And to behonest, they were right. Because these issues got

Ensemble Studios’ AGE OF EMPIRES II: THE AGE OF KINGS 118so much press, we knew going inthat if we didn’t address them in avisible and obvious way, AOK wasgoing to be raked over the coalsby reviewers and users. It didn’tmatter that other popular RTSgames had pathfinding that wasjust as bad, or that our AIs didn’tcheat and theirs did—we weren’t going bejudged against them, but rather against ourselves.To handle the computer-player AI, we hiredMario Grimani, an industry veteran with significantAI experience under his belt. The computer-playerAI from AOE was thrown out, anda new, expert system, script-based AI was developed.While Grimani was doing the coding,Sandy Petersen led the design team in developingscripts for the new AI. Input from the wholecompany was encouraged, and various peoplecontributed scripts that were pitted against eachother in an evolutionary fashion to develop acomputer player that could race a human playerup through the ages and react to his tactics.For the pathfinding problems, nothing less thanan all-out blitz was ordered up. The gameengine’s movement system was redesigned andno fewer than three separate pathfinding andtwo obstruction systems were developed, requiringfive different people working on them at varioustimes. A high-level pathfinder computesgeneral routes across the world map, ignoringsuch trivial things as people walking, whichwere handled by lower-level pathfinders thatcould thread a path through a closely packedgroup of units. In the end, we were so successfulin ridding the movement problems that hamperedAOE that reviewers and players couldn’thelp but take notice and acknowledge theimprovement.2. We innovated within thegenreWhile in the end AOK stayed much closer to itsAOE roots than we had initially envisioned, wepushed the RTS gaming experience forwardwith a host of improvements. Some of thesewere interface-only improvements, such as the“Find Next Idle Villager” command, completelycustomizable hot-keys, and the extensive rolloverhelp. Other improvements changed thegame play itself, such as the Town Bell (ring itand all your villagers run inside the Town Centerto defend it), in-game technology tree, and ofcourse, Automatic Formations.One of the most praised features, AutomaticFormations caused a group of selected units toautomatically arrange themselves logically byputting the strongest units up front and theones needing protection in the rear. They stayin formation while traveling, replacing the“random horde” that players had becomeaccustomed to in RTS games. ProgrammerDave Pottinger originally set out to create a

119SECTION II: SEQUELS AND SOPHOMORE OUTINGS119formation system incorporating characteristicsof a turn-based war game’s formation system,but as the game progressed and our understandingand vision for the game matured, acomplicated formation system gave way to asimpler system that better served the game.When I wrote the graphics engine for AOE, Iused a 166MHz Pentium at work and tested onmy 486 at home. A 2MB video card was my target,but the game would run with only 1MB ofvideo memory. Today I have a 32MB TNT2card in my 500MHz Pentium III system.These changes in the typical gameplayer’s system are mirrored by theincrease in player expectations for agreat visual experience.For AOK, a whole new terrain system wasdeveloped, allowing us to mix terrains together,shade elevation in 3D, greatly increase the numberof textures, and even alpha-blend texturessuch as water. The highest compliments came atthe 1999 E3 show when we were unable to convincepeople from some of our biggest competitorsthat AOK was still a 256-color game3. Better use of bug trackingsoftware and crunch-timeIn AOK, I’m proud to say, we met andexceeded game players expectations.The first thing that you notice uponplaying AOK is the scale. The units inthe game are about the same size, butthe buildings and trees are no longericonic. They are large structures with ascale that looks as if the units couldcomfortably reside inside them. Castlesand Wonders are now gigantic, imposingstructures that fill the screen.And the art itself is just so much better.Our entire art staff gained a great deal of experienceand skill with AOE and ROR, and AOKbecame a showcase for their improved talent. Itwasn’t just the units and buildings, though. InAOE, the terrain had something of an Astroturffeel to it and the need to make transition tiles byhand limited the game to four terrain textures.A scene from one of the game scenarios. Theupdated graphics engine and building scale allowedus to create scenes much more impressive than inA0E.managementDuring the development of AOE, we had a singlemachine in the office that would connect up toRAID, a remote bug database in Redmond,Wash., via an ISDN modem. This was used tohandle bugs found by testers at Microsoft. Everyso often someone would fire the connection up

Ensemble Studios’ AGE OF EMPIRES II: THE AGE OF KINGS 120and, if the machine at the other end was in agood mood, make hard copies of new bugreports to pass around to people.We also had a different software package forcommunicating bugs and issues among ourselves,but there were not enough users on thelicense for everyone. Suffice it to say, this systemleft something to be desired, but it was all wehad. During the development of AOK, Thin-RAID was made available to us, allowing everyoneto access the bug database directly fromtheir web browser. Having only one system oneveryone’s desktop, available whenever needed,that was always up-to-date made a hugeimprovement in our ability to track bugs, stayon top of things, avoidredundancies, and just plainsave time.The last six months ofdevelopment on AOE werepretty much one continuousblur of people working nonstop.This took a heavy tollon people, sometimes evenstraining their health ormarriages. As a company,we vowed to not let thingsget that bad again. To furtherunderscore the need,the composition of EnsembleStudios had shifted dramatically away frombeing mostly young, single men (with presumablyno life) to being dominated by married menwith a growing number of children and babieson the way.A 3D Studio Max model of theMameluke character. Twentythousand polygons got reduceddown to several hundred pixels forthe final game.To protect ourselves, we scheduled crunch timewell in advance at multiple points in the developmentprocess. The hours were 10 A.M. tomidnight, Monday through Friday, withWednesday nights ending at 7 P.M. so we couldgo home to our families. We had weekends offand meals were provided during the week. Forthe most part this worked very well, althoughhaving a “family night” where family memberscould join us for dinner once a week proved tobe more of a distraction than we would haveliked. Producer Harter Ryan deserves muchcredit for making crunch time so much easier onAOK.4. Better use oftools andautomated testingAfter AOE was finished, wedeveloped several in-houseand in-game tools to makethe job of development easier.The most-used tool wasArtDesk, a multipurposeprogram that convertedgraphics from standard formatsto our proprietary formats,which allowed us toview and analyze the contentof our graphics data,and generated many of thecustom data files for the game. This easy-to-useGUI-based program replaced several antiquatedDOS command-line utilities and automatedmany tasks, saving a huge amount of time overthe development span.

121SECTION II: SEQUELS AND SOPHOMORE OUTINGS121In an effort led by Herb Marselas, programmingtools such as Lint, BoundsChecker, and True-Time were used to a degree never approachedduring AOE’s development and proved invaluablein improving the quality of our code.Finally, in-game utilities such the Unit CombatComparison simulator allowed the designers tobalance the game in a more scientific way. Everyeffort made in the tools area was rewarded witheither time saved or significant improvements inthe product. The only glaring omission in allthis was the lack of an art asset managementtool.5. We met our systemrequirementsA game that’s expected to sell in the millionsneeds to be able to run on most of the computersit will encounter. Requiring cutting-edge systemsor specific video cards won’t work. WithAOK being an 8-bit 2D game, meeting videocard requirements wasn’t going to be very difficult.But memory and processor speed targetswere another story. All the new systems in AOKwould put their demands on the computer.Optimization issues were worked on hard forthe last several months of development.The eleventh-hour addition of some clever tricksand a variable graphics-detail switch allowed usto hit our CPU target of a Pentium 166MHz,MMX-supported CPU. The minimum memoryrequirement of 32MB was also met, but withsome reservations. Large multiplayer games onhuge maps would need an extra eight or 16MBto be really playable. All in all though, the minimumsystem requirements for AOK are some ofthe lowest for games released in the Christmas1999 season, widening the game’s potentialaudience.What Went WrongI’d like to say that we had fewer problems developingAOK than we did for AOE, but it didn’tturn out that way. Some problems listed in theAOE Postmortem were addressed in AOK andothers weren’t. And like that band going backinto the studio to record a follow up to a hitalbum, we encountered a whole slew of brandnew problems, many of which we found wewere just as unprepared for as we were the firsttime around. I’ve tried to include some of theissues that became more important due to thefact that we were making a sequel to a successfulgame.1. We still don’t have a patchprocessThis was a problem area from the AOE Postmortem,and as of this writing it still has notbeen addressed. I outlined the reasons weneeded a process to issue patches for our gamein a timely manner in the AOE Postmortem.Additionally, a new reason reared its ugly head:cheating in multiplayer games. At first peoplefound bugs in AOE and exploited them to winunfairly. Then it got even worse. Programscalled “trainers” were developed that wouldactually modify the game’s code while it wasrunning to allow players to cheat.

Ensemble Studios’ AGE OF EMPIRES II: THE AGE OF KINGS 122Being the developer—notthe publisher—of AOE, wedon’t have the final decisionif or when a patch is to bereleased. As a result, allduring 1999 our reputationas developers wasassaulted by fans who sawus as uncaring about theproblems that were drivingpeople away from onlineplay of our games. Thetopic of cheating in multiplayergames is so extensive I hope to do an articleon it in the near future. We addressed thisproblem with our publisher and were promiseda patch process.Unfortunately, AOK shipped with a couple bugsthat seriously needed addressing in the shortterm. They’re not show stoppers, but if notaddressed soon, the game’s (and our) reputationmay suffer another black eye. If a patch forAOK is out by the time you read this, then youcan conclude that we finally established our process.2. Unfinished versions of thegame got outA 3D Studio Max model for a malevillager. For AOK, female villagerswere also added.This is a problem that is born of success. Prereleaseversions of nearly all games wind up circulatingin pirate channels known as “warez.”This happened with AOE. Imagine our surpriseat reading an entire review of the game (analpha version) eight months before it wasreleased. Fortunately, almost no one botheredwith it until the game wasproperly released becausenobody knew much aboutit. AOK was a completelydifferent story. It was ahighly anticipated sequel toa very successful game, andthe various warez sites weretripping all over themselvesto get a copy of the latestbuild. And get a copy theydid.They were usually only one or two weeksbehind our latest build. It seemed as thoughcopies were leaking out from every imaginablesource—play-testers at Microsoft, previews sentto magazines, even internal sources. Unfortunately,positively identifying and fingering theculprits was almost impossible.There were hacking attempts on our FTP serverand network, although the real rub came fromthe pirates in Hong Kong and Singapore. Theytook the warez versions of AOK, burned themonto CDs, added some cover art, and sold thegame throughout the Pacific Rim. In Korea, theCD vendors operating in front of Microsoft’sheadquarters had a warez version of AOK forsale. Warez versions were even turning up oneBay.Though we doubt bottom-line sales were hurtmuch, our pride certainly suffered. Any of ourfuture games will probably require connectingto a secure server of our own design to operate,even for single-player games.

123SECTION II: SEQUELS AND SOPHOMORE OUTINGS1233. Play-testing had a lot ofproblemsThis item is a catchall for several problems thatwe encountered. On the good news front, ournew offices have a dedicated play-test areaequipped with identically configured machines.The bad news is that we didn’t make the best ofit. Many of our play-tests were not organizedand focused enough, seriously reducing theamount of new and meaningful feedbackobtained. It wasn’t always clear when we weretesting for specific bugs and issues, and when wewere testing for “fun.”We had a schedule of participants which drewupon the whole company, but schedule conflictsand lax enforcement resulted in the same peopleplaying most of the games. We played too muchmultiplayer and not enough attention was givento the single-player game. And some peopletook it much too seriously, trash-talking otherplayers, celebrating wins at the loser’s expenseand storming off when they were losing.Play-test problems weren’t confined to Ensemble,though. At Microsoft, it was discoveredthat a play-tester had turned cheats on, playingto win not to test, in almost every game for overa month, which invalidated all the feedbackfrom that group for the prior two months.4. Art asset management wasnonexistentThe number of individual frames of graphics inAOK is in the tens of thousands, and we didn’tdo a good job managing it. The programmershad a source-control system to help coordinatetheir primary output of code and the designershad the game’s database system, but no suchequivalent existed for the game’s art assets. Artistscould be working on something with no ideathat anyone else was also working on it. Therewas no way to get a momentary snapshot ofwho was working on what, other than goingaround from office to office. Plus, there was noway to tell which files were actually live andbeing used and which ones were just taking upspace.A bird’s-eye view of the AOK game world.Compared to AOE, AOK has bigger worlds withmore objects and richer graphics.Also missing was a way to go back and findprior versions of art, or to guarantee that newversions wouldn’t be overwritten. As we havegrown as a company, this problem has growneven faster. To address this problem in thefuture, a source-control similar to the art assetmanagement system is being developed for usein all future projects.

Ensemble Studios’ AGE OF EMPIRES II: THE AGE OF KINGS 1245. Problems with third-partyAPIs and softwareAnother one of the items from the AOE postmortemreturns again. Microsoft’s DirectPlayAPI still has a number of issues that make it lessthan perfect. One of its biggest problems is documentationand testing of the lesser-used portionsof the API, or rather the lack thereof. Latein the development of AOK, our communicationsprogrammer, Paul Bettner, was able tocommunicate with the DirectPlay developersand an interesting scenario played out severaltimes: Paul would attempt to solve some problemand the developers would indicate that itwouldn’t work because of bugs in DirectPlaythat they knew about but that were not documented.DirectPlay wasn’t the only problem. We decidedto use DirectShow to handle our cinematics.The short version of this story is that it justdidn’t work. And then there was the Zone softwarefor Microsoft’s online Gaming Zone. TheZone software was developed too late in theprocess and had a number of problems, due to alack of time to test and correct. Unfortunately,this means that direct TCP/IP games are morereliable than those played over the Zone, whichis disappointing. This was not all the Zone’sfault because we did not get our requirements tothem soon enough.The Show Goes OnOne of the touchiest and most personal issuesconcerned letting success go to our heads. Thesuccess of AOE is something that a lot of peopleTOP ROW, from left to right: Jeff Goodsill (COO),Brad Crow (art lead), Brian Hehmann (artist),Angelo Laudon (lead programmer), SandyPetersen (designer), Dave Pottinger(programmer), Ian Fisher (designer), Harter Ryan(producer), Duncan McKissick (artist), Trey Taylor(programmer), Mario Grimani (programmer), PaulBettner (programmer), Chris Van Doren (artist),Jeff Dotson (artist), John Evanson (programmer),Doug Brucks (programmer), Roy Rabey (ISsupport), Paul Slusser (artist), Chea O'Neill(artist), Bob Wallace (strategic), Mike McCart(webmaster). BOTTOM ROW: Rob Fermier(programmer), Nellie Sherman (logistics),Stephen Rippy (music), Herb Marselas(programmer), Mark Terrano (lead designer),Chris Rippy (sound), Herb Ellwood (artist), ThonnyNamounglo (artist), Duane Santos (artist), DavidLewis (programmer), Sean Wolf (artist), BruceShelley (lead designer), Matt Pritchard(programmer), Brian Moon (CFO), Tony Goodman(CEO), Don Gagen (artist), Greg Street (designer).NOT PICTURED: Tim Deen (programmer) BrianSullivan (strategic), Chad Walker (artist), EricWalker (artist), Scott Winsett (lead artist).

125SECTION II: SEQUELS AND SOPHOMORE OUTINGS125in this business have not experienced. Itexceeded our wildest dreams and allowed ourcompany to take charge of our destiny. I rememberwhen we got our first AOE royalty check—Ihad never held a multimillion dollar checkbefore. That was great. We all got caught up inhow good we were doing. Over time an attitudeof invincibility set in. With a success like AOE,it’s easy to forget what it was like to wonder ifwe were going to be in business the next year.At some of the industry events such as the GameDevelopers Conference and E3, some of ourpeople behaved in ways that embarrassed us.With success comes a responsibility to behaveappropriately—the game industry is a small andincestuous one, and nothing lasts forever.Behaving in an exemplary manner and beingfriends with the industry at large is far moreimportant than chest-beating about our currentsuccess. Suffice it to say that people in theEnsemble Studios organization have steppedforward to address this and we have challengedourselves to be better people.All the early indications for AOK are that it’sgoing to be a blockbuster on the order of its predecessor,and maybe even greater. The reviewsfrom the press have been unbelievably positive.According to PC Data, AOK was the numberoneselling game in October. The great successof AOE made it possible for us to go to the nextlevel of making great games. Though it enabledus to grow and acquire greater resources, it alsoraised expectations for our next game andspawned a host of new challenges. Meetingthese new expectations has proved to be just astough and rewarding a journey as creating thefirst game. In the end we succeeded in creating agame to be proud of, and I feel privileged tohave been part of it.

This Page Intentionally Left BlankEnsemble Studios’ AGE OF EMPIRES II: THE AGE OF KINGS 126

127Presto Studios’MYST III: EXILEby greg uhler“Hello?”“Hi, Greg, this is Bret Berry from Mindscape.How ya doin’?”“Just great, thanks. What can I help you with?”“Well, I’m calling about a game proposal we’dlike you guys at Presto to put together for us.We’ve contacted several developers about this.Whoever gives the best proposal will get theproject.”“OK, what’s the project?”“MYST III.”Did he say MYST III? A new sequel in the MYSTseries that has sold almost 10 million copiesworldwide? After picking the phone up off ofthe floor and closing my gaping mouth, I couldonly say, “Wow!”“Yeah, I thought you’d be excited. The proposalwe require needs to include some story concepts,an analysis of MYST and RIVEN, a technologydiscussion, and, if at all possible, atechnology demonstration. Oh, and we needthis in five weeks.”Back-StoryMYST 3 is the second sequel to MYST, the phenomenallysuccessful work of the mid-90s, and the first MYSTgame to be produced outside the original developmenthouse, Cyan. The MYST games follow the model ofsome of the earliest text adventures, in which the playerssolve puzzles to find their way through beautifulstatic environments, revealing a story as they go. CD-ROM technology allowed these environments to berealized in splendid visual and auditory detail, and theirserene beauty drew many PC owners to enjoy their firstcomputer game ever.Needless to say, we hit the ground running.Presto Studios has been in the computer gamebusiness for more than 10 years. We began as agroup of friends working out of a home in SanDiego on an interactive CD-ROM game calledTHE JOURNEYMAN PROJECT. Since that time,we’ve shipped six other products, grown to asmany as 45 employees, and have enjoyed limitedsuccess with our games. MYST III: EXILE,however, had the potential to take Presto to awhole new level. Production of EXILE beganwith a very small team: a writer, a creative director,three conceptual designers, and me as producer.The first subject we tackled was an analysis ofMYST and RIVEN. What worked? What didn’t?

Presto Studios’ MYST III: EXILE 128Why were those particular games so phenomenallysuccessful? And what did we want to dodifferently?Our discussions eventually led to the formationof a few overriding goals for EXILE. First, wewould strive for great visual variety in the game.Game DataRelease date: May 7, 2001Publisher: UBI SoftGenre: adventurePlatforms: Macintosh and PC (hybrid)Staff: 22 full-time employees, 1 full-time contractor, 2part-time contractorsBudget: Multimillion-dollar budgetLength of development: Two and a half yearsDevelopment hardware: Mostly Dells, averaging dual700MHz Pentium IIIs with 1GB RAM and 30GB harddrivesDevelopment software: Discreet 3DS Max, DiscreetCombustion, Apple Final Cut Pro, Adobe Photoshop,Metrowerks CodeWarrior, Microsoft Visual C++,Microsoft Word, Microsoft Excel, Microsoft Project,Digidesign Pro Tools.Notable technologies: RAD Game Tools’ Bink andMiles Sound System, Apple’s QuickTimeProject size: A feature-length animated film like ToyStory uses 120,000 frames of animation; EXILE usedmore than 150,000We much preferred the varied worlds of MYSTover the more homogeneous chain of islandsfound in RIVEN. Second, we would need to providea way in which players could gauge theirprogress throughout the game.Players who had failed to complete MYST orRIVEN did so because they were unsure of howmuch remained of the game and what theirgoals were. We didn’t want that to happen withEXILE. Finally, we wanted an extremely satisfyingending to the game, one which drew uponall of the knowledge that players had acquiredthroughout their journey. With these goals inmind, we set out on a two-and-a-half-year journeyto create a worthy sequel to MYST andRIVEN.What Went Right1. Identifying the customerWho played MYST and RIVEN? What did theylike and dislike? What type of computer do theyown? We felt that answering these questionswould be instrumental in shaping what a MYSTsequel should be. So we obtained data from registeredowners of the two products, read all ofthe reviews and articles we could get our handson, and became active readers of the MYSTrelatedInternet fan sites and web boards. All ofthe information we gathered was used by thepreproduction team to evaluate every part ofour game—the visuals, story, puzzles, music,and technology.For example, the hottest debate in preproductionwas whether or not EXILE should use prerenderedor real-time 3D graphics. By usingprerendered graphics, we felt that we couldmeet or exceed the visual quality that RIVEN hadachieved, but our puzzles would be more limited

129SECTION II: SEQUELS AND SOPHOMORE OUTINGS129Spiney bridge in Voltaic.than if we used real-time 3D, because we wouldneed to precalculate all the possible states foreach puzzle from every viewable location. Conversely,real-time 3D would allow us to makethe worlds more active and constantly changing,but to achieve the graphic realism of the worlds,the customer would be required to have a veryfast CPU and a high-end 3D card.In the end, this debate was resolved by identifyingthe MYST consumer. Our research showedus that many MYST players only played a fewgames each year. They are not out buying newcomputer systems every few years, so they typicallyhave a slightly older computer, one thatwould have a hard time keeping up with anadvanced real-time 3D game. So, we decided touse prerendered visuals for EXILE, in order togive us the largest possible customer base.2. Preproduction and planningHaving created adventure games for eight years,you’d think that we would have been able toskip a lot of preproduction and just get to theproduction of the game very quickly. Actually,the opposite was true. For EXILE, we wantedmore preproduction and planning time thanwe’d had for any of our other products. We hadbeen burned too many times in production, anddidn’t want that to happen again. There is nothingmore disheartening for an artist than to seehis or her work go down the drain because oflast-minute changes or redesigns.With this foresight in mind, we convinced ourpublisher that we required a full nine months todesign EXILE on paper, before we would create asingle graphic. Though I’m sure it made ourpublisher quite nervous, we knew that this

Presto Studios’ MYST III: EXILE 130amount of preproduction time would helpensure a smooth production phase. Preproductionof EXILE began with two teams, one workingon story and the other on visuals. We didn’twant either team constrained by the other, so wekept them separate for the first month or so.Then we met together and began bouncing ideasaround. It was amazing to see the two teamsinspire each other—concept sketches led ourwriter down new plot lines, while story ideasand characters caused our artists to break outtheir sketchbooks during the meeting. Graduallythe two camps met more frequently until thestory and visuals became inseparable, ensuringcontinuity between the final game’s world, plot,and characters.Once the overall story and visual ideas begancoming together, we focused onwhat we call the gameplaystructure. This refers to thepuzzles or challenges and theiraccompanying solutions andrewards that the player experiencesduring the adventure.This gameplay structure neededto allow for the story to berevealed over the course of theentire game, the level of difficultyto increase during thecourse of the game, and nonlinearevents to be employed. Wecreated a flowchart of theto see the game at a glance and make sure that itmet our goals of gradual story revelation,increasing difficulty level, and a nonlinear experience.When the gameplay flowchart, visual conceptsketches, and story were complete, we had ourblueprint for the game. This 160-page documentwas required reading for the entire team. Butnow it was time to put our money where ourmouth was and develop the graphics for thegame.3. Using 3DS Max for artTo be honest, we were at a bit of a crossroadswhen it came to what 3D package to use for theart of EXILE. We had been using Electric Imageon Macintoshes for manyyears, but had also recentlybeen using Discreet’s 3DS Maxon PCs for our real-time 3Dwork. Could 3DS Max createthe type of prerendered photorealisticscenes we required forEXILE? And what else could itoffer? Our lead animator, MikeBrown, was convinced thatwith the right finesse, 3DS Maxcould rival any high-end renderingpackage, so he set out todo a few tests. In about a week,he re-created one of the smallgame, listing all of the challengesalong the way, what theyreveal when solved, and anyGameplay flowchart.islands in RIVEN and also builta prototype of one of our conceptworlds. The results wereinterdependencies between puzzles or areas of very encouraging. We also explored the workexploration. This flowchart was used as a tool

131SECTION II: SEQUELS AND SOPHOMORE OUTINGS131flow of an artist using 3DS Max and discoveredthat the benefits of it being an integrated packagewere tremendous. The ability to model, texture,light, and animate in the same packagesolved a huge production nightmare for us. Inthe past, if an animator found something wrongwhile he was lighting a scene, he’d have to tellthe modeler, who would fix the problem in a differentpackage and send it to the animator, whowould need to update his file with the fix. Talkabout a recipe for disaster when you’re dealingwith tens of thousands of objects.An example of EXILE’S Ocean water texture.Our evaluation of 3DS Max proved that it wasalso the right choice for many practical reasons.First, we knew that we would need to hire manymore artists to create EXILE. We found thatthere were many knowledgeable, talented 3DSMax artists available all over the world. Second,3DS Max’s open architecture and resulting litanyof third-party plug-ins meant we could pickand choose additional features for the programat a very low cost. Why spend huge R&D coststo develop realistic ocean water when you canbuy the plug-in for a few hundred dollars andhave the same water that was used in Titanic?We took great advantage of this not only forwater, fire, and hair, but also for productiontools that helped us model, texture, light, andrender much more quickly. 3DS Max proved tobe a great choice—loved by the artists and indiscerniblefrom more expensive packages by ourcustomers.4. TechnologyHaving decided to use prerendered graphics forEXILE, we were faced with the challenge of makingthese traditionally static images as immersiveas possible. In one of our previous games,we had licensed a technology that displayed stillimages as 60-degree panoramic views (similar toQuickTime VR) but were unhappy with its performanceand image quality. To overcome thesedeficiencies, we decided to write our own 360-degree technology. We developed a techniquethat took advantage of the speed and quality ofreal-time 3D cards. Quickly prototyping ouridea with existing imagery, we realized that itworked flawlessly, allowing for very high framerates without any degradation in image quality.We felt this was exactly the right technology toimmerse a player in the worlds of EXILE.With the basic technology complete, we pursuedhow to integrate animation, video, and watermovement into the panoramic views. For animationsand video, we wanted to avoid theQuickTime bounding-area rectangle and harshcompression artifacts that were typical of MYSTand RIVEN. So we investigated several othercompression algorithms and playback engines,

Presto Studios’ MYST III: EXILE 132finally deciding on RAD Game Tools’ Bink technology.Bink provides fantastic compression andhigh image quality, playback engines for bothMacintosh and PC, a fairly lowprocessor speed requirement,and a host of special features.For instance, using the alphachannel support inherent inBink, we were able to displayanimations and video in such amanner that only the changingpixels were drawn. This meantthat the bounding box rectangleof the movie was gone andthe compressed pixels weremuch less noticeable in thechanging image.The last piece of the technologypuzzle was the proceduraleffects, such as the movingocean water. The waves neededto move realistically, look correctfrom altitudes rangingfrom five to 400 feet, and fadeoff into perspective toward thehorizon.Villian’s costume conceptsketch.To accomplish this, we first generated alphachannels of the ocean water for each panoramicimage in the game. Next, we wrote an imagemanipulation algorithm (similar to a Photoshopfilter) that properly bent and twisted the waterpixels. The altered pixels were then applied tothe ocean water texture (using the alpha channel)15 or more times per second to give the water theillusion of movement. Variations of this techniquewere also used to simulate bubbling andebbing lava as well as one puzzle’s visible soundwaves.5. Web support andfan communityOne of our early concerns forEXILE was that MYST fansseemed to believe that onlyCyan (the creators of MYSTand RIVEN) could create a greatMYST game. We had to find away to convince theMYST/RIVEN/D’ni fan communitythat even though Prestowas creating the game, EXILEwould meet or exceed theirexpectations. Our solution wasthe Internet. First, we identifiedtwo leading fan sites on theInternet, and in May 2000 (oneyear prior to shipping) invitedtheir webmasters to come toPresto for a special sneak previewof EXILE. After viewingour teaser trailer, getting ahands-on demo, and browsingour concept sketches, both webmasters weresufficiently impressed and vowed to share theirpositive experience on their sites. Furthermore,we established such a good relationship withboth webmasters that we coordinated with themover the next year and worked with one of themto create the official Myst3.com site.Our second solution using the Internet was torelease a teaser trailer and early screenshots.The trailer was intended to evoke the spirit of

133SECTION II: SEQUELS AND SOPHOMORE OUTINGS133MYST and RIVEN while providing a sneak peekat what EXILE had to offer visually. Supportingthe trailer were numerous screenshots thatshowed the detail and beauty of the first worldof EXILE. The trailer was downloaded morethan half a million times in the first month, andthe screenshots were posted on numerous Websites and scrutinized by the diehard fans. Inshort, our underground public relations campaignwas working well, and the fans were rejuvenated,eager to follow EXILE’s progress overthe next year, culminating with the game’slaunch.What Went Wrong1. Video qualityThe live-action video shoot, and everythingleading up to it, was probably the game’s mostimportant development milestone. It was anextremely hectic time. The scriptwriting had tobe completed, the costumes designed and sewn,the props built, the CG backgrounds rendered,the actors hired and rehearsed, and the studioand personnel booked. All of these individualelements did come together, but one criticaloversight prevented our resulting video frombeing crisp and perfect: we didn’t use HDTVcameras.Months after the video shoot was complete, webegan compositing the video footage—removingthe blue backgrounds from the live-actionvideo and replacing them with our computergeneratedworlds. After running a de-interlacefilter on the footage (to remove the inherentNTSC scan lines), it quickly became evidentthat the lack of source video resolution (thenumber of pixels) was resulting in a blurryimage. Even with image-sharpening tools andthe latest filters in our compositing package, wewere unable to achieve the crisp video that wehad hoped for. This issue would have beenavoided entirely if we had used the vastly superiorimage resolution of HDTV. We certainlynow know the adage: Garbage in, garbage out.2. Underestimating the budgetHaving created many adventure games in thepast, we had a reasonable estimation of howmuch it would cost to develop EXILE. However,what we didn’t account for was how much extraeffort it would take to reach the image qualitylevel that was required. We were no longerworking under our own quality levels, butrather ones that MYST and RIVEN had established.This mistake meant that we underestimatedthe cost of the game, though we hadsigned a contract to produce the game for thatamount.Underestimating the budget translated directlyinto not being able to hire enough team members,which translated into an insane schedule.It really was as simple as that. We all had to,and did, work our tails off, but this onlyresulted in a general feeling of “Whew! Gladthat’s over” rather than “That was a blast! Let’sdo another one!”

3. Sacrificing future projectsUndermanned and underfunded, everyonehunkered down and focused solely on EXILE.Not just the team, but the entire company. Personally,I was producing the game, prototypingpuzzles, and programming many of our finalworlds. Our president was executive producerfor the title, technicaldirector for the videoshoot, and responsiblefor compositing all ofthe live-action footage.Clearly, we were wearingtoo many hats. Somany, in fact, that welost sight of some companygoals and, mostimportantly, landingmore projects. As aresult, we only had oneproject in developmentafter EXILE was complete,and we wereforced to lay off staff. Itwas very disappointingto me personally to seepeople who had slavedover the project be“rewarded” with being laid off. The devotionthat we all had to EXILE clearly had its cost.4. So we’ve made anotheradventure gamePrior to EXILE, Presto was already known as an“adventure game company,” having worked onsix of these games in the past. We were eager toshake this image and prove that we could doAmateria world from wireframe to final image.Presto Studios’ MYST III: EXILE 134much more. Obviously, the fantastic opportunityto create EXILE was something we could notresist. However, we are very concerned that thecompletion of EXILE will further brand us as an“adventure game only” company. Will EXILE’scompletion bring us many new opportunities?Or will we have to try even harder to avoid thismoniker? Only time will tell.5. The launch: It’s out of ourhands nowThe launch of any title is usually one of themost stressful times for the developer-publisherrelationship. The developer is exhausted, havingjust crunched through several years of production,yet hopeful and full of expectationsfor the success of “their” product. However,the publisher then takes the reins, promoting

135SECTION II: SEQUELS AND SOPHOMORE OUTINGS135the product, manufacturingthe boxes, selling as many copiesas possible, and handlingcustomer support. But wheredoes this leave the developer?In truth, the developer is stillfinancially tied into the productbut has absolutely no morecontrol over it. That is whythe launch is always so stressful,for it represents the transitionof power that has takenplace from the developer tothe publisher.This stressful launch periodwas no different for EXILE. Wewere exhausted. We obviouslyhad high hopes for the game.We felt that if EXILE was promotedas being “big,” it wouldbe big. After all, MYST andRIVEN are the best-selling PCgames of all time. Unfortunately,the purchase of ourpublisher by another publisherchanged the decision-makingprocess, the people in power, and the managementapproach. What we felt should have beena huge launch was, in our opinion, slightly disappointing.A great multilingual feature of thegame was cancelled in the last few weeks. Ourpresence at E3 was minimal, due to our producerbeing taken out of the loop on the decision-makingprocess. Advertisements wereAtrus’ costume sketch.scarce and short-lived. Andnegotiations for a possiblesequel ground to a halt.Even with these occurrences,however, we believe that timewill determine EXILE’s success,not the minor setbacks fromthe launch period of the game.Going forward, we expect thatthe launch will only be a bumpin the road, not a sign of thingsto come.ClosingThoughtsAs you’ve seen, some elementsof our production worked outperfectly, and probably savedus months of time and tens ofthousands of dollars. Othersdidn’t go quite as well as we’dhoped, and parts of the productsuffered because of them.Throughout the process, we tried to appreciatethe positives and learn from the negatives. I’veheard it said that good judgment comes fromexperience, and experience—well, that comesfrom poor judgment. Here’s hoping that weshowed a lot of good judgment and that the“experience” wasn’t too painful.

This Page Intentionally Left BlankPresto Studios’ MYST III: EXILE 136

137Poptop Software’sTROPICOby brent smithIn the spring of 1999, Poptop had just wrappedup development on the successful RAILROADTYCOON II (RT2) and its expansion, THE SEC-OND CENTURY. At the time, Poptop was staffedby the overwhelming count of four artists andtwo programmers. Being that small, we had hadno time to think about anything other than thecurrent project, and suddenly we found ourselvessitting around a table, eyes still slightlyglazed from the inevitable project-end rush wehad just gone through, looking for new ideas.These were uncharted waters for Poptop. RT2had been based very closely on Sid Meier’s classicRAILROAD TYCOON. The original RAILROADTYCOON had been an inspiration, a design manual,a blueprint for making a good game, and alaunching point for new ideas. The upside wasthat a good part of the design work had beendone for us. The downside,as we were to find out onour next project, was thatit left us a bit naïve aboutthe effort it would take tocreate a new game from anoriginal idea.As we sat around our companycard table, brainstormingideas, one ideaThe almanac.Back-StorySome games form their own mini-genre, and TROPICO isone. Players take the role of a petty dictator, el Presidenteof a Caribbean island, with control of its politicaland economic development. Poptop's previous gamewas the economic strategy game RAILROAD TYCOON II,but TROPICO is a much deeper, broader simulation of anentire mini-republic, reaching down to the level of individualcitizens and across the board from education totourism. Despite its depth and complexity, TROPICO alsomanages to convey the quirky, cynical humor of itsbanana-republic material.quickly jumped to the forefront. The idea oftaking a building game and putting a politicalgame on top of it had captured everyone’s imagination.With our creative energies renewed by afresh idea and the thrill of starting a new projectin our hearts, we rushed off to create TROP-ICO—each of us in our ownway. Actually, it wasn’tthat bad. We did discussmajor elements of thegame. We knew that itwould have buildings andpeople that the playerwould not control directly.We knew it would use theRT2 engine but would be

Poptop Software’s TROPICO 138more ambitious than RT2 had been. As werushed off to begin development, that was aboutall we knew—and, as we were to discover later,each person on the team didn’t even share thesame vision about the things we thought we didknow.Game DataRelease Date: April 2001Publisher: Gathering of DevelopersGenre: real-time strategy/”god game”Platforms: Windows 95/98/ME/2000/NT 4, MacNumber of Full-time Developers: 10 (7 artists, 3programmers)Number of Contractors: 1 musicianEstimated Budget: $1.5 millionLength of Development: 2 yearsDevelopment Hardware (average): 550MHz PentiumIIIs with 512MB RAM, 40GB hard drives, and a varietyof 3D cards running Windows ME or 2000(programmers) or Windows NT (artists)Development Software: Visual C++ 6.0, VisualSourceSafe 6.0, 3DS Max 3.1, Character Studio 2.2,Photoshop 5.5, Tree Factory plug-in for 3DS MaxNotable Technologies: Bink Video, Miles SoundSystemProject Size: Approx. 150,000 lines of code (plus20,000 for tools)During the project, Poptop grew to the bloatedsize of 10 employees—seven artists and threeprogrammers. It is a testament to the talent andhard work of this team that we ended up with astrong, fun product in spite of the pitfalls thatwe encountered along the way.What Went Right1. Created “deep” characterIt was obvious from the beginning that the mostimportant aspect of TROPICO would be the people.If we intended to have a game in which theplayer didn’t have direct control of the units onthe map, then we had better make sure that thepeople acted in a reasonable and somewhat predictablefashion.This was no trivial task. Each unit on the map(in the later stages of the game there can easilybe more than 500 units) has more than 70 characteristics,which determine its actions and reactionsto the player. This includes items as simpleas name, age, and what part of the island theunit was “born” on, to things as complex as theunit’s satisfaction with various aspects of theenvironment (religion, national pride, pay comparedto others in the same situation, and soon). Additionally, as units live their simlives—they are born, prance about as children,enter the workforce at a certain age, and eventuallyretire and die—we keep track of their families.Each unit potentially has a mother, father,spouse, and multiple children. Units also knowabout their grandparents, cousins, aunts, anduncles. What this means to the player is that therepercussions for treating one unit badly filterthrough their family tree much like you wouldexpect in real life. Send Juan Pablo Ramirez tojail, and not only are his parents, wife, and childrenupset, so are his five siblings, their 18 children,and so on down the line. This added a lotto the political atmosphere of TROPICO.

139SECTION II: SEQUELS AND SOPHOMORE OUTINGS139Our second goal with this system was hiding itscomplexity from the player. Part of the fun ofTROPICO is trying to see and understand whatresponse your actions will evoke from the populationof your island. Although we kept detailedinformation about each unit in the game, therewas a balancing act in taking advantage of itwithout flooding the player withinformation. I think we succeededhere. Our interface providesthe player with in-depthinformation about the people inthe game—making them comealive—without overwhelmingthe player with having to knowtrivial details about them.Unit development was not easy,but because we identified this asa critical area up front and spenta lot of time and manpoweraddressing it, it turned into oneof the strengths of TROPICO.2. Small, streamlined, andtalented teamBanker.Being as small as we are certainly has a downside,the most serious being that we are limitedin the things we can do in a given amount oftime by sheer lack of manpower. However, theadvantages to a team this small, at least in termsof developing a project such as TROPICO, outweighedthe disadvantages. Everybody at Poptopknows everyone else. Not just knows them,but knows what they are working on, what theirstrengths and weaknesses are, the name of theirsignificant other, and so on. There’s no hidinghere. If you screw up, people know it was you.If you do something brilliant, everyone knowsthat too.This kind of intimacy makes us very streamlined.Everybody knows where he stands andwhat his job is. There is no middleman; if youneed to talk to someone, youtalk directly to him. There is nodistraction of having team memberspulled off to work on a different,behind-schedule projector promotional material. We didone thing, TROPICO, and that’sall we did. Of course, this kindof team only works if everymember is talented, and that is,without a doubt, the case at Poptop.I see it every day, and I thinkthe players of RT2 and nowTROPICO have seen the result aswell.3. Homegrown toolsUpon the completion of RT2, we had accumulateda nice suite of tools for preprocessing andmanipulating art assets and interface elements.With TROPICO, we continued this work, bothimproving the existing tools and developing newones. Our most-used tool was a program writtento preprocess art assets into our custom format.It also had the ability to clip and scale theart, and also reduce animations to a keyframeand delta information for efficient storage.When TROPICO began, we further modified thistool to allow it do work with 24- and 32-bit

Poptop Software’s TROPICO 140TIFF files. A palette reducer/optimizer wasadded to create 8-bit palettes from one or morehigher color-depth images. We also included theability to add parameters to the instruction setthat the program used to process the files, allowingsuch things as tinting (which allowed us toconstruct placeholder art rapidly by simply takingan existing image and tinting it to anothercolor), and lightening or darkening of theimage.this tool into a format that could be used by theTROPICO code.A new type of tool that we developed and beganusing with TROPICO, and which turned out to bea real time-saver, was used for game datamanipulation. Using MFC (which I’d never recommendfor any software intended for release,but which is tremendous for quick developmentof tools such as these), we quickly built a veryrobust unit editor and building editor.These editors allowed us to manage all the dataassociated with a particular type of building orunit outside of the program.This capability was invaluable for balancing andtweaking the data, as it allowed us to changeinformation in a relatively safe way while thegame was running and see its effects immediatelyupon the game world.Tourists relax and sunbathe on the beach.Finally, we added support that allowed us toread image-depth information stored in RLAfiles and store it with the image. This informationcould then be used to tell us the Zorderinformation of the various parts of the image,which allowed us, for example, to handle unitswalking behind parts of a building while walkingin front of others. Another tool that weinherited from RT2 and improved upon duringthe development of TROPICO allowed us to create,size, and position interface elements outsideof the code. Using a simple scripting language,interfaces could be built and then compiled by4. Fun topicWithout a doubt, one of the key factors in thesuccess of TROPICO was the topic. During ourbrainstorming sessions, a number of ideas werethrown on the table, but the idea that becameTROPICO was the one that had everybodyexcited. While a lot of the elements of TROPICOcan be found in other games, the mixture ofthose elements and the setting itself had everyoneeager to see what we could make. Thisenthusiasm translated outside of the company,too. Nearly everyone to whom we showed thegame voiced their enthusiasm about the freshnessof the idea. Something about the idea ofruling an island full of sun-drenched beaches

141SECTION II: SEQUELS AND SOPHOMORE OUTINGS141and tropical beautiesstrikes a chord in mostpeople’s hearts.One of the most promisingindicators late in theproject that we hadsomething special on ourhands was that we werestill eager to play thegame, and were stillthrowing out new ideas,even after spending twolong years developing it.5. LocalizationWireframe and model of the hotel.Having been involved in the translation of RT2into a variety of different languages, includingdouble-byte handling for Asian languages, weknew up front that this was something that weneeded to be concerned with in TROPICO. Fortunately,a lot of the groundwork had been establishedduring RT2’s development. The codecontained home-grown string manipulationfunctions, which allowed us to maintain tightcontrol of many of the issues associated withlocalization. We also had a tool that allowed usto pull strings out of the code base for insertioninto a string table near the end of the project.The tool was very useful in that it not only recognizedstrings within the code, but it was smartenough to disregard strings within commentsand strings on lines which we tagged with a specialcomment telling the tool that it was O.K.for this string to remain in the code (formatstrings, for example).This meant that formuch of the project wedidn’t have to concernourselves with trying tokeep a string table up todate, but when the timecame, we were able todo it quickly and efficiently.Overall, localizationwas a breeze.Having seen what anightmare this step canbe on other projects, wewere dreading the workwe thought we wouldhave to do in this area, but the final tally wasless than a man-week of work spent getting thegame ready for foreign language translation.What Went Wrong1. Lack of up-front design workComing off the success of RAILROAD TYCOONII, we were excited to get the chance to work onsomething new and unique. A few companybrainstorming sessions and a game or two ofJunta, and we knew that we wanted to do atongue-in-cheek political game. We couldn’tjump into the project fast enough. Ideas wereflying hot and heavy. Everyone was excited.Unfortunately, we failed to realize at the timethat everybody was carrying a slightly differentpicture in his head of what the final game wouldbe. Some were envisioning the stab-your-neighbor,laugh-a-second antics of the Junta board

Poptop Software’s TROPICO 142game. Others were seeing the close-up, detailedview of people in action that ROLLERCOASTERTYCOON had done so successfully. Most of uswere somewhere in between.Having come from RT2, we really found ourselvesunprepared for this problem. With RT2,Poptop had the original as a blueprint anddesign document. Design was only an issue sofar as how the original game could be improvedupon and how current technology could be utilizedto improve the game. The game couldpractically write itself, with Poptop’smain concern being to re-createthe magic of the original gamewhile adding a few minor twists ofour own. Now we found ourselveswith a blank slate, an original ideawhere every gameplay detail hadto be created from scratch.Unfortunately, we approached thisin much the same way as we hadapproached RT2. Rather than settlingon a unified design, or eventrying to create one, each of us ranback to his workstation and beganto create what we thought thegame would be.It quickly became apparent that wewere not all moving in the samedirection. People had very differentviews of where the game shouldgo. Decisions had to be made onthe fly. Some people’s visions wereLuxury tourist.cut out entirely, while others had theirs alteredto the point that it became something entirelydifferent.This process was a very difficult growing painfor Poptop. People’s feelings were hurt whenthey realized the idea that they were so excitedabout was not the idea that we were creating.The game lost “buy-in” from people in the companyas it became something that they were lessinterested in or someone else’s idea that theydidn’t really understand. During this time westruggled onward, trying to createthis game that wasn’t really whatanyone had originally intended.Amazingly, we stubbornly refusedto stop and consolidate our ideas inmeetings or on paper so that theteam could be unified in the ideaand to rekindle the original excitementfor the game.Eventually, working on TROPICOstopped being a passion andbecame just a job for many on theteam, leading to low morale andloss of productivity. Hopefully,we’ve learned from this mistake,and on our next idea (original ornot) we will figure out what it iswe are creating before we start tocreate it and try to keep everyoneexcited about the direction inwhich we are moving.A tourist.

143SECTION II: SEQUELS AND SOPHOMORE OUTINGS1432. Modifying the existing codebaseOne of the givens, decided before any work waseven begun on TROPICO, was that we would usethe 3D engine from RT2. This would allow usto have working maps with many of the featureswe would need in TROPICO almost immediately,thereby giving us a huge jump start on development.The idea was a great one and paid hugedividends in getting us working almost immediatelyon the game itself rather than the engine.Unfortunately, in conjunction with this decision,we started from the existing RT2 codebase—not only the engine, but all the game codefrom RT2 as well. We were trying to “morph”RT2 into TROPICO, which led to all kinds ofproblems and slow-downs.An in-game overview of the island.First of all, a single programmer had developedalmost the entire RT2 code base. With TROPICO,the staff of Poptop had nearly doubled in size.Each new programmer immediately faced thedaunting task of getting a grasp of the RT2 codebefore he could even begin to make the modificationsnecessary to create TROPICO. Second,there were huge chunks of the code base thatbecame dead once TROPICO was started, such asthe multiplayer code. (We had decided prettyearly in TROPICO’s development to scrap multiplayerand concentrate on the single-playerexperience.) Of course, multiplayer code wasintegrated very tightly into many areas of theRT2 code, and at first we tried to work aroundit. Eventually we tore it out, once we becamefrustrated trying to determine which areas of thecode were dead and which were important.Finally, the process of working off the originalRT2 code base was inherently dangerous atbest. We automatically inherited any bug thathad managed to survive in RT2 and createdquite a few more just going through the processof weeding out what code was unnecessary forTROPICO. We would have been much better offstarting with a clean slate and then pulling overthose sections of the RT2 code base that wecould use. The RT2 code was not cleanly delineatedbetween engine code and game code.However, the process of untangling the usableengine code and importing it into a clean codebase would have been inherently more bug-freeand more comprehensible to those unfamiliarwith the RT2 code, and would have saved ustime in the long run.3. Fun factor versus gee-whizfactorBecause we started with an existing engine, oneof the errors that we made during developmentwas to see how far we could push the envelopewith the engine, working on “gee whiz”

Poptop Software’s TROPICO 144enhancements that would improve the look andthe technology of the game instead of featuresthat would enhance gameplay.The biggest example of this was what wedubbed “Zoom 0.” As the graphics in TROPICOwere much more detailed than RT2’s, we lookedfor ways to show off these gorgeous images inthe game. Allowing the engine to zoom in onelevel closer than it had previously been able to(Zoom 1) was one of the ways that we did this.In TROPICO, players can zoom in very close andget very detailed views of the people and thebuildings. Unfortunately, Zoom 0 is not veryuseful for gameplay, as it is almost impossible tosee enough of the map at that zoom level to geta feeling for how you should play. The majorityof players tend to stay zoomed out about twolevels, occasionally zooming in or out one levelas the situation warrants.OK, so we added a feature that allowed us toshow off the graphics even if it didn’t helpgameplay. What’s the big deal? The deal is thatwe pre-scaled all of the images for the variouszooms beforehand and stored them in the datafile, so these high-resolution close-up graphicsate up as much space as all the other zoom levels’graphics combined. We spent a full 50 percentof our graphics budget on this one feature.As we got deep into the project, it becameapparent that memory and CD file space budgetswere going to be tight, but we had investedtoo much into this feature to be comfortablewith cutting it.Ultimately, we had to cut other features to createspace, features which would have improvedThe dictator’s mansion.the game. Rotatable buildings, more unit animations,and repeating animations on the buildings(such as blinking lights and moving machinery)all had to be cut to make room. Looking back, itis apparent that tossing out Zoom 0 and puttingin more gameplay-friendly features would havebeen a big net improvement to the overall game.4. Waited too long for scenariosAfter the scenario-intense RT2 and its add-ons,we were more than happy to try creating a gamein which the strengths lay in randomly generatedmaps and sandbox-style open-ended play.From day one we worked on TROPICO with thisgoal in mind. A lot of effort went into creating amap generator that would create pleasing, logical,and most importantly playable maps. Wemodeled rainfall on what we knew and couldfind out about meteorology. We researched vegetation,not only to find flora indigenous to a

145SECTION II: SEQUELS AND SOPHOMORE OUTINGS145Caribbean setting but also to find out underwhat conditions a particular plant would thriveand how to represent that in the game.A significant amount of time wentinto creating realistic mountainsand series, even ranges, of mountains.We even went so far as tomodel the terrain under the water,so that shallow beach areas anddeeper waters would be accuratelycreated. As we neared the end of theproject, we had no doubt that ourmap generator could create somefabulous-looking maps, and, giventhe number of factors we allowedthe player to tweak during mapgeneration, an endless supply ofplayable maps.Pit boss.However, the game was missing clearly definedgoals. Using the map generator, there was noway to create a map that had a specific situationto solve, and only a very limited way to createmaps with unique obstacles to overcome. Inother words, the game and the maps were greatfor an open-ended, sandbox style of game, butwere lacking in goal-oriented, problem-solvinggameplay.While the sandbox mode allows players to createa wide range of different maps, much moredepth and many hours of play could have beenadded to the game if we had included a rich setof scenarios and the tools for the players to createeven more.As we realized this late in the project, we scrambledto create scenarios to include. Unfortunately,our tools in this area wereunderdeveloped, and time had to be squeezedout of people’s schedules even toproduce what we did. The resultwas that TROPICO included a verylimited number of scenarios (eightwith the game and two othersincluded in some promotional CDs)that weren’t nearly as involved asthey could have been, and certainlyweren’t up to the standard that wehad created in RT2.Another by-product of this oversightwas that we never spent timepolishing the map editor tools thatwe used in development.The original game design was oriented towardrandom-map play, so we never saw the need fora more sophisticated editor until late in theproject. These tools ended up being disabled inthe release version, disappointing many fanswho were hoping to create their own maps. Fortunatelyfor our fans, a map editor should beavailable in an upcoming patch.5. Lack of unified artistic visionAs I mentioned, one of the effects of essentiallybypassing the design phase of this project wasthat there was a lack of consistent vision amongteam members. One of the places that thisbecame most apparent was in the game art.Almost all of the artists at one time or anotherduring the project worked on creating buildings

Poptop Software’s TROPICO 146for the game. They were given only a vaguenotion of what type of building they were tocreate—a paper sketch or a very crude 3Dmockup—and left on their own to move forwardfrom there.Halfway through the project, the problems withthis became apparent. Scale varied wildly fromartist to artist, as did level of detail. The sameproblems were occurring with the character animations,as the two artists working on thosehad taken different approaches. One artist wasstriving toward very lifelike figures with complexanimations, while the other created morecartoonish parodies of TROPICO’s inhabitantswith more outlandish but less complex animations.Both artists had a clear idea of what theywere trying to do, and both accomplished theirrespective goals brilliantly, but the difference intheir approaches can still be seen in the releaseversion of the game if you compare, for example,the banker to the female luxury tourist.At this point we appointed a person to take onthe role of art producer. His job was to try tocoordinate the artists’ efforts and make surethey shared more or less the same vision. But thedamage had been done. Team members had tospend valuable time sifting through and reworkingart. Frustrations mounted as artists who previouslyhad been able to work toward theirpersonal vision now found themselves having tocompromise to a shared vision of the wholeteam. This problem could have been significantlyreduced with more up-front planning andmore ongoing feedback to the artists as theycompleted each task. We definitely learned fromthis process and will improve upon it in ournext game.In HindsightIt’s pretty much the experience with any gameproject, whether the developers will admit to itor not, that you look back and see mistakes thatyou made and bemoan the ways that the gamecould have been better if only those mistakeshad been avoided. TROPICO is certainly no differentin that regard. Every member of theTROPICO team felt the sting of loss at somepoint or another when a feature that they wereparticularly fond of was cut. Each of us canlook back and think of a hundred ways that wecould improve TROPICO. That, in itself, is agood sign. At the end of two years of development,we still cared about the game and wantedto make it better. Everyone was happy withwhat we had created, but no one was satisfiedwith the details. Art is never done.We learned a lot individually and as a teamabout how to approach a project and how tomanage it once it is underway. This was our firstattempt at a completely original idea, andalthough we encountered a lot of pitfalls alongthe way and stumbled more than a few times, Ithink the end result is pretty amazing—somethingthat we are proud of and that the game’sfans will enjoy. Considering that TROPICO wasdone with a team of only 10 people—tiny bytoday’s standards—the game’s success is a testamentto the Poptop team’s talent, creativity, andhard work.

147SECTION IIIManaging InnovationThe great thing about an innovative game is thatit starts with desire. A person or a developmentteam comes up with an idea for a game no onehas seen before, and they want to play it badlyenough that they’re willing to go through all therisk and work and inordinate hassle required tobring it into being.Suppose you have an idea for a game, somethingno one has seen before. There are many formsthis could take. It could be a clever piece of softwareyou’ve been toying with, a graphic style, ora method of telling a story, or a haunting image.It could be an untried subject like haberdasheryor whale-watching, or a dream you had (SPACEINVADERS, apocryphally, was based on adream), or just a strange indescribable feeling. Itcould be anything.This will not be easy. Someone has to fund thegame, to be convinced that the vision you andyour team share will one day be exchanged forhard cash. A marketing team has to understandwhat the game is, and why people will want it.The development team has to communicateeffectively enough so that they can be sure thatthey all share the same idea. And no one can seethis so-called “great idea”—it’s still a thought insomeone’s brain. Of course, it’s the very newnessof the thing that makes this process so difficult.Any game starts this way, but in theinnovative games, the radical departures, it’stoughest—you have nothing you can point toand say, “it’s going to be like this.”Over the next 18–36 months, there is the task ofconverting this invisible feeling, this hunch, intoa functioning piece of software that runs on anactual machine. This is the process that is unbelievablysubtle and difficult. It comes down to aseries of tiny decisions made daily, about interface,art direction, technology. Should such-andsucha command be made with the right or leftmouse button; should the heroine be blonde orbrunette; should we invest CPU cycles in AI orin rendering? All with the looming, crushingknowledge that a factory in upstate New York iswaiting to stamp your answer onto 400,000CDs.These are the kinds of choices that slowly convertthe charged, elusive vision within you intoan application on your desktop that anyone canrun and experience. It’s particularly difficult in

Section III: MANAGING INNOVATION 148this medium because you’re part of a group of8–40 people, practicing at least four differentdisciplines (programming, art, game design,audio, not to mention storytelling and projectmanagement) in an interdependent process thatis supposed to yield one unified coherent wholethat captures a feeling that 15 months into theproject you may well be unable to recollect. Alldone on a tight schedule and budget, as everyday and every penny cuts into the net profit.(The crowning irony, of course, is that otherpeople consider this a trivial amusement. Whenyou tell them what you do for a living, the inevitableresponse is, “Oh, so you get to play gamesall day?” Yes. Yes, that’s exactly right.)There is an art to this process. In an ideal world,making an innovative game would be as simpleas (a) getting a good idea, (b) writing a detailedtechnical and design document and makingsome concept art, and (c) getting a developmentteam to make it (this is sometimes called the“waterfall” development model). Then you wait24 months while they work, and on the last daythe game is complete and you sit down and playit and voila...fun.If this book teaches one lesson, it should be thatthis is not always possible. Game developmentis very complex, especially new kinds of games.Features take longer than expected, or interactin surprising ways, or suggest other exciting featuresthat suddenly seem worth implementingtwo weeks before beta, and so on. Experiencedteams expect surprises. They build something,play it, double back, rethink, cut features, holdmeetings, and try again. Shipping a successfulgame usually involves this iterative cycle ofbuilding features, testing them, and then revisingthem, repeated several times over the developmentperiod.Different games present different problems.Sometimes the initial idea proves too ambitious,and you have to decide which features to cutwhile keeping the core idea intact. Sometimesthe initial idea proves too vague, and part theprocess of building the game is refining andtightening the focus. Sometimes it’s a process ofdiscovery. As the game becomes a concretething, as it encounters reality, it works a littledifferently than it did in your head. Games arevery complex entities, and it’s impossible towork out in advance how everything in themwill behave. You may notice playtesters usingsome feature in ways you never imagined, todefeat obstacles or just as a kind of mini-gameby itself. They’re not playing the game youimagined, they’re playing the game you actuallymade, which is slightly different but perhaps noless fun.• Define a high concept.Have a clear sense of where you’re trying togo, even if you don’t know how to get there.Every week, you and the rest of your teamwill have to make decisions, you can use thehigh concept as a compass to check yourbearings against. If you can ask of any giventask, “does this bring us closer to our goal ofcreating the ultimate robot ninja jai-alai simulator,”it’s easier to make these judgmentcalls.

149Section III: MANAGING INNOVATION• Know when to cut features.A feature can be cool, but still not form anessential part of the game you’re making.• Build good tools for creating and editingcontent.It is essential to be able to test content in yourgame engine, and revise it if things don’twork the way you plan. The easier it is to editgame data, the quicker you can react to testingfeedback, and the more cycles of testingand revision you can go through.• Form a solid relationship with yourpublisher.If the game needs revision, someone on thepublishing side needs to understand why andhow it’s going to take place. If they can trustthat your development process is under control,and have a sense of the goal you’reworking toward, things will go much moresmoothly.• Create a clear chain of command, orsome other protocol for toughdecision-making.Not every decision can be made as a group,especially when it comes to setting the visionfor the game. If team members disagree onsome point, it has to be resolved so developmentcan continue.• Prototype early.Get the game and its core features runningand playable as soon as you can. Have peoplewho haven’t heard about the concept play itand tell you whether it’s fun, and why or whynot.Why make innovative games? They take appallingchances with the time and money of the peoplewho make them, all for the slim chance ofbecoming a breakaway win or at least a quirkycult hit.There are large-scale reasons to make them.Most people agree that digital games are animmature phenomenon and that we are far fromseeing what can be done in this medium. Ifsequels are the bankable projects that keep theindustry alive from year to year, it is the radicaldepartures that help it grow, that expand oursense of what the medium is. We are all waitingfor better games, and innovation is the only waythey get made. Of course, they play an economicrole as well as a creative one—games like MYST,and, yes, BARBIE FASHION DESIGNER, changedthe market as well as the medium, by bringingpeople who had never thought about it before tosit in front of a computer play games.

This Page Intentionally Left BlankSection III: MANAGING INNOVATION 150

151Lionhead Studios’BLACK & WHITEby peter molyneuxBLACK & WHITE is the game I always wanted tomake. From the days of POPULOUS I had beenfascinated by the idea of controlling and influencingpeople in an entire world. I was alsointerested in the concepts of good and evil astools the player can use to rule or change theworld. These themes crop up regularly in mygames, but I realize now that with every game Iwas heading toward my ultimate goal—the godgame BLACK & WHITE.I wanted the game to be more flexible, moreopen, and more attractive than anything I’d everplayed. I was determined that the player coulddo almost anything he or she wanted. Instead ofleading players deeper into a world of levels andtesting them with tougher and tougher monsters,I wanted players to be engaged by thestory but to take it at their own pace and decidewhich bits to tackle and when to tackle them.More technically, I didn’t want a panel of iconsor a set of on-screen options. With DUNGEONKEEPER I felt we overdid the control panel, and,while it worked, it didn’t add to the immersivesense of being this evil overlord deep underground.Frankly, it simply reminded you thatyou were playing a video game. Finally, Iwanted to place into BLACK & WHITE the abilityto select a creature (originally any creature fromBack-StoryBLACK & WHITE belongs to the god-game genre popularizedby Lionhead auteur Peter Molyneux in the POPU-LOUS series—the player is literally a god, helping his orher people prosper, through guidance and miracles. Theshowpiece is the Creature, which is a living animal avatarthat the player raises from childhood, shaping its personalityby reward and punishment. The Creature is acomplex, semi-autonomous artificial intelligence,whose nature changes as it grows—like the player-god,the Creature can become good or evil, black or white.BLACK & WHITE is an ambitious accomplishment—apartfrom its originality, it features fluid, epic-scale storytelling,gorgeous graphic presentation, and an elegant, versatilemouse-based interface.the landscape) and turn it into a huge, intelligentbeing which could learn, operate independently,and do your bidding when you wanted. I knewthat this would require an artificial intelligencestructure unlike any ever written. It had to bethe best.Of course, I needed a team for all this, but Iwanted the right sort of team and so had tobuild it slowly. A core team of about six wasformed, and at the start of Lionhead we workedat my house. Our first task was to create alibrary of tools, so we spent our time theredoing boring foundation tool-building. We

Lionhead Studios’ BLACK & WHITE 152started work on the game proper when wemoved into our offices in February 1998, atwhich time there were nine of us. By this timewe had begun thinking about the game in generalterms. We discussed what we could have init, what we should have in it, and what, in a perfectworld, we’d like to see. Funnily enough,Game DataRelease date: March 30, 2001Publisher: Electronic ArtsGenre: real-time strategy/ “god game”Platforms: Windows 95/98/2000/MEFull-time developers: 25Contractors: 3Budget: Approx. £4 million (approx. $5.7 million)Length of development: 3 years, 1 month, 10 daysHardware used: 800MHz Pentium IIIs with 256MBRAM, 30GB hard drives, and Nvidia GeForce graphicscardsSoftware used: Microsoft Dev Studio, 3DS MaxNotable technologies: Bink for video playback,Immersion touch sense for force-feedback mouseProject size: Approx. 2 million lines of codemuch of the last category did in fact make it in,things such as the changing atmosphere andbuildings if you change alignment between eviland good or vice versa. Also, ideas for somefully lip-synched characters were thrownaround. At that time, we didn’t seriously think itcould be done.During the first year of Lionhead we added peoplegradually, as I was very keen for the friendly,family-style atmosphere of Lionhead to remain,and it takes a certain sort of person to fit in andenjoy working with such a close-knit team. Thispolicy of only recruiting people whom we felthad the talent and a way of working which fit inwith Lionhead’s existing members meant thatour team had evolved their own way of working.They didn’t just carry out their tasks butquestioned, tested, and pushed both themselvesand each other. It’s labor-intensive, but youoften end up with more than you expected. Forexample, the art team divided up the tribalstyles for the villages and tried to outdo eachother in terms of design and effort put in. Theresult was better design work than we thoughtwe’d get.At Lionhead Studios, we all knew that BLACK &WHITE was going to be something special. Thisbelief became self-fulfilling as we were inspiredby each new feature and every neat, innovativesection of code. Naturally, this meant thateveryone worked exceptionally hard. Over thecourse of the project the team did the work of agroup twice their number. We regularly wenthome as dawn broke, and weekends becamesomething other people did.What Went Right1. It got finishedThis sounds stupid, but we encountered somebig problems, and there were times when wedoubted that the game (as it ultimately endedup) would get released. As a new company, wenot only had to work out the game we were

153SECTION III: MANAGING INNOVATION153going to create, but we had to write the toolsand libraries, create everything from scratch insoftware, and also gel together as a team. Wecouldn’t have a dress rehearsal for this, so welearned by trying things and then changing themif they didn’t work. As time rolled on, wecouldn’t afford to makeany mistakes or pursueblind alleys.For example, we talkedabout updating some of thegraphics at one point. Itdidn’t seem a big job, butonce we’d changed some ofthe buildings in the tribalvillages, they showed upany unchanged ones andmade them look lessimpressive, so we had toassign time to do them all.We got a much better set ofbuildings out of this, but ifwe’d known that we’d havehad to do all of them, wewould have said, rightly,that there wasn’t time.Render of the evil cow Creature.The programmers were likewise coming up withneater and neater ways of coding, and thus tryingto do more and more with the code theyhad. It says a lot about the talented and singlemindeddevelopment team at Lionhead thateverybody always wanted to make every elementthat little bit better. And as we fixed thebugs and sent the game to QA, we felt like peoplewho’d run a marathon and could see the finishline, but it didn’t seem to be getting anycloser. Perhaps this is a function of not gettingenough sleep over a period of several months.2. All the risks paid offWe wanted to do some pretty groundbreakingthings in BLACK & WHITE.One example was doingaway with the panel ofcontrols and using the Gesturesystem for casting Miracles.We tried and tried toget this feeling just right,and if we’d had to dump it,I’d have been so disappointed.But after research,testing, and simple trial anderror, we got it workingbeautifully, and we nowhave a feature no one elsedoes.Also, integrating the storyline into such a free-flowingstrategy game was a risk.We thought it would sitquietly behind the game, popping up to directyou if you hadn’t moved on, but the story camealive and started to draw the player through thegame in a way none of us, apart from perhapsscriptwriter James Leach, had envisaged. It alsogave us characters such as Sable, the Creaturetrainer, and those advisors whom we hear peoplenow quoting lines from, and who exist outsidethe game as recognizable characters.The huge, learning, intelligent Creature was alsomore of a gamble than he now seems. To go into

Lionhead Studios’ BLACK & WHITE 154AI in such an in-depth way required RichardEvans, our AI programmer, to consider whatlearning was, how practice works, and how thereinforcement of ideas comes about. Then hebuilt all this into a character which appeared tolive and learn like, say, a clever puppy. AI isalways a minefield, and I’m always disappointedWe’re also the first game (apart fromMicrosoft’s FLIGHT SIMULATOR) which enablesyou to import real weather in real time into theworld. We are also the first to enable unifiedmessaging, whereby you can send messages tothe web from the game, or receive them, using e-mail and mobile phones. This integrated twowaymessaging as well as the ability to take yourCreature out of BLACK & WHITE and onto theweb is brand-new. Also, the game can importnames from your e-mail package and assignthem to unique villagers in your tribe in thegame. I expect lots of games to do similar thingsin the future, but we took massive risks anddevoted huge amounts of effort to being the firstand to making it work properly.Good ape.by great strategy games which appear to havethe most simple, easy-to-predict AI runningyour enemies. We just wanted to advance thetechnology to its extreme.We also wanted to do more with graphics andanimation blending. The world changes dependingon whether you’re playing as a good or anevil god, and things take on subtle new looks.The Creature, the player’s hand, and many ofthe buildings change, and we used more animationblending to achieve smooth movement andchanges than anyone else has ever done, Ibelieve.3. The game looks so stunningWhen we started, we used a wireframe test bedand a couple of conceptual screenshots to providesome atmosphere. I first showed the testbed and these mocked-up screenshots to thepress at E3 in Atlanta in 1998, and I could seeon the assembled faces that nobody believed wecould accomplish anything like it in the finalgame. I was complimented on the depth andbeauty of preliminary efforts, but the complimentshad a slightly hollow ring. I could almosthear people thinking, “Yeah, it looks great, butanyone can draw pretty screens using an artpackage. What’s your game really going to looklike?”Not only did we manage to pull off the look wewanted, but we exceeded it by some margin.The sheer beauty of the lands is something Ihope won’t be matched for a while, and the fact

155SECTION III: MANAGING INNOVATION155that you can move, zoom, and rotate to view itfrom any angle, anywhere in the game, is againsomething we got spot-on. Looking back, Idon’t know whether we were insanely ambitious,because at the time westarted, you couldn’t havedone what we did. We neededso much custom-written software,and we also needed theminimum specification of thePC community at large to getbetter before this would beviable. When we startedBLACK & WHITE, most peoplehad 32MB of RAM in theirPCs. The game requires64MB, but that’s commonplacenow. So, if you like, weaimed beyond the horizon,and the world rotated andcaught up with us so we still hit our target.4. The artificial intelligenceConcept drawing for thetortoise Creature.The Creature AI, as I have mentioned, is absolutelyspot-on. Richard Evans worked tirelesslyon this, and it became something that surprisedeven him with its flexibility and power. The AIisn’t just restricted to the Creature. Every villagerin the game has it as well, and they are alldifferent in their wishes, desires, motivation,and personality. Because there is no upper limitto the number of villagers you can have, we hadto cap the AI slightly by giving some of the villagercontrol to the Village Center, which actslike a hive and farms out some of the cooperativeelements to the people. We couldn’t havethem interrogating each other, so this centralcontrol means that they do work as a unit butcan retain their individual characteristics. Thismakes the game much faster and still gives themminds of their own.The Creature himself is anastonishing piece of work.Once he starts learning, heforms his own personality ashe goes, and no two playerswill ever have the same Creature.The complexity is kept toa minimum to keep him fast,but we managed to steer completelyclear of using randomelements to make him seemlike he has a mind of his own.And there is nothing in thegame that you can do whichyou can’t teach your Creatureto do. It’s true to say that the Creature mirrorsyou and your actions, so in BLACK & WHITEwe’ve got a game in which part of the gameitself learns from everything you do and tailorsitself to you.5. The way the team cametogether to make BLACK & WHITEhappenThis is Lionhead Studios’ first project, andeverything started from scratch. The people, thesoftware, and the working environment were allnew. Although this was exactly what we neededto do a game so fresh and diverse, it also createdproblems which I was delighted to overcome.The lack of any precedent meant that thingstook a lot longer than they should have, and the

Lionhead Studios’ BLACK & WHITE 156open-ended nature of the game throughoutmuch of its development meant that team memberswere limited only by their own imagination.But the nice thing is, every member of the Lionheadteam gelled brilliantly, and although Iknow we picked the very best people, there is anelement of luck in whether they can all worktogether so well. We certainlylucked out with theteam, and every one ofthem contributed massivelyto making the gamewhat it is. The last fewmonths of the project werethe hardest any of us hasever had to work, butthanks to the people, theywere also some of the mostfun months we ever had. If The citadel.nothing else, we’ll alwaysremember the time we spent closeted togethermaking BLACK & WHITE. And I’ll never forgetthat without the right team, this game neverwould have happened. It’s as simple as that.What Went Wrong1. Planning the storyWe underestimated how long it would take toconstruct and write the story element of BLACK& WHITE. The free-form nature of the gamerequired an unfolding tale to give it some structureand lead it to a conclusion, and in October1999 we began to work on the story. Wethought it would take no more than twomonths, but after a while we realized that wedidn’t have the skill set needed to take care ofthis vital aspect of the game. I contacted JamesLeach, who’d been the in-house games scriptwriterat Bullfrog and had worked on SYNDI-CATE WARS, DUNGEON KEEPER, THEMEHOSPITAL, and many others. He was working asa freelance ad copywriterbut gladly came on board,again in a freelance capacity,and turned our ideasinto a fully plotted storyline, wrote hundreds ofchallenges and quests, andwrote all the dialogue in thegame. It ended up beingmore than 60,000 words,the size of a novel.Hiring James meant thatwe got a sense of continuity, consistency, andstyle throughout the game. It also meant that wecould describe what we wanted, or even writeplaceholder text, and he would rapidly turn itinto finished work. Sections of the game thatwere still at an early stage seemed more easy tounderstand, get a feel for, and work on when weused dialogue and text which seemed, to us, finished.Of course, another pass was usuallyneeded to make it accurate and sometimes topolish it, but having a dedicated scriptwritermade this a simple task.Storytelling in games, as elsewhere, is an art. If astory line flows easily and naturally, that’sbecause someone has worked incredibly hard at

157SECTION III: MANAGING INNOVATION157Tortoise morphs from evil to good.it. I’m a great believer in the emotion andimmersion that can be added to a game throughgood story and dialogue. It can’t make a badgame good, but it can make any game better.And when the script was looked at by Hollywoodscriptwriters and film directors from theBBC, we knew we were on to a winner.Another by-product of using a professionalscriptwriter was that we morphed the in-gameadvisors, the good and evil guys, from being justsources of information and guidance into stylish,popular characters who are now bankableproperties in their own right.2. Fixing the bugsAfter canceling our Christmas party on December26, 2000, we managed to hit Alpha, whichas any developer knows is a very loose definition,but at least we could say that all the gamefeatures were now locked.After a well-deservedChristmas break, we cameback to find that we hadmore than 3,000 bugs. Wehad six weeks to reducethis to zero, but the thingabout bug-fixing is that youcan solve one problem butin doing so create threemore. So although weworked as hard as wecould, the overall figurecrept down slowly ratherthan dropped at the rate atwhich we were actuallysorting out the bugs.By this stage the team was very tired. The onlythings that kept them going were the sense thatthe end was in sight and the fact that they couldnow play the game and actually experiencewhat we had created. Bugs, of course, couldhave killed the game, so there was no wayaround it but to fix each and every one. We hadbug lists circulated to every member of the staff,and we put up a chart on the wall which wasupdated daily. Some days we had more bugsthan the day before, and that was like looking ata mountain which was growing quicker than wecould climb it.But there came a moment three weeks into thisprocess when we felt we’d broken the back ofthe major bugs, and the numbers fell steadily.Of course, the irony was that the last 10 bugswere the hardest to fix, and with every one there

Lionhead Studios’ BLACK & WHITE 158were four more created. It was as if the gamejust didn’t want to be finished and perfected.3. The project was too bigBLACK & WHITE got to be so large that wealmost felt lost within the code. In fact there arewell over a million lines of code within thegame. Loading up even the most simple of thesmallest tools would take many minutes, andcompiling the entire game took over an hour.This meant that toward the endof the development phase even atiny change could take a wholeday to implement. Checking inchanges and rectifying errors wasa nightmare. We eventuallydecided to limit the checking-in toone machine, and we implementeda buddy system wherebynothing was done without anonlooker checking it at everystage. This put a stop to tiredpeople checking in changes atfour in the morning and findingthat, instead of fixing something,they’d actually caused furtherproblems.Another worry about theproject’s size was that we didn’tthink the game would fit on oneCD, although we were desperatefor it to. The audio files areimmense. Music, dialogue, and effects are allcompressed, but of sufficiently high quality thatwe refused to reduce them any further. And with15 language versions to get translated andrecorded, we had to do the biggest localizationjob I’ve ever seen. This landed on Lionhead Studiosat the very busiest time, and although ourpublisher did an excellent job of handling it, wewere needed to check and answer questions andto provide explanations for some of the morearcane elements of the game.4. Leaving things outThe idea of the game didn’t reallychange much over the course ofits creation. But I do have someregrets that features we thoughtwould be great proved unworkable.I expected this, as it happenswith every project, but I thoughtthe problems would be caused bysoftware or even hardware limitations.In fact, it came down moreto emotional issues.For example, the original idea ofthe Creatures was that a playercould choose to make any livingthing a Creature. We wanted theplayer to be able to select an antand grow that, or a human beingfrom a tribe, and raise him or her.Christian Bravery, one of the artists,spent a long time drawingConcept sketch of thegood Celt.concept work and sketchesdepicting what the Creaturescould look like at various stages of their development.This of course included humans.

159SECTION III: MANAGING INNOVATION159We soon realized that people would have certainexpectations from a human. Players wouldn’texpect a turtle to learn as quickly as a man, butif we dumbed down the people, they’d seem likea proto-hominid race from eons ago, and wedidn’t want that. Also, disciplinein the game involves slappingyour Creature. Wecertainly couldn’t have theplayer slapping a child or awoman or, really, even a grownman. The emotional feel ofraising a human, teaching himor her to eat what you want,and leading him or her aroundin a speechless environmentwas all wrong. Christian’s workin visualizing humans as playerCreatures was all for nothing inthe end, and we dropped theidea. We also dropped thenotion of turning any livingthing into a trainable Creature,as ants, butterflies, fish, andother non-mammals wouldhave caused big problems. Aflying Creature would change BLACK & WHITEinto a totally different game.Concept art of the evil Celt.I also regret that we couldn’t use color as adynamic concept a little more. The landscapesin the game are gorgeous, and our sound andmusic man, Russell Shaw, suggested that variousspells could drain the color out of areas, orspread different colors around. We liked thisidea for its surrealism, and we thought abouthaving color wars with other wizards (at thisstage you weren’t a god, you were a wizard battlingothers on a land). The idea lost momentumwhen we thought about how the land wouldactually look, and how it would seem like somethingdrawn by a preschooler. I still like the ideaof color wars, but I think children’s TV has alsocottoned on to the idea, whichmeans we won’t be going there.5. Talking aboutrelease datesI have to admit, ruefully, that Ihave a reputation for being,shall we say, optimistic aboutwhen the projects I’m workingon will be completed. I openedmy big mouth and announcedthat Lionhead Studios wouldfinish BLACK & WHITE and getit released at the end of lastyear. I just can’t resist talkingabout whatever I’m currentlyworking on. This has been aproblem I’ve experienced withevery game I’ve ever developed.But the thing is, when I think something is goingto be finished in December, I really do believe it.People at Lionhead were telling me that we hadto build in time for bug-fixing, and I knew thiswas true, but the truth is that there seems to beno formula for working out how long thingswill take. The best thing to do, I guess, is to takethe finishing date I first think of and move ittwice as far away—and then not announce ituntil we’re halfway there.

Lionhead Studios’ BLACK & WHITE 160It’s a function of working on products whichcould literally be endless. Unlike a film, whereonce the footage is shot, you edit it with an ideaof where you’ll end up, you can add completelynew features to a game and then balance it andchange it radically right up until the lastminute. I’m sure that there were many peoplewho didn’t believe me when I said we’d finishedmaking BLACK & WHITE and were only convincedwhen they saw a box with a CD in it.“Just More”BLACK & WHITE is unlike any other game everwritten. That was our goal, and we achieved it.We wanted something more beautiful, morecomplex, more emotive, more innovative, moreclever, and more, well, just more.As you’ve read, it was beset by problems. Wenearly drove ourselves crazy solving them.Nothing worthwhile is ever simple, though, andfor every minute spent thinking up wonderfulideas to include in the game, there were probably20 hours of sheer hard effort trying to getthem to work.We tried to make the micromanagement of thevillagers as user-friendly as possible.People told Lionhead we were perfectionists,but if we were, the game would never have beenfinished. It’s not a perfect game. Our next gamewon’t be, either. But because there’s no suchthing as a perfect game, we’ll just try to dosomething different, and do it as well as we possiblycan. Someone asked me recently whatdrove us to work so hard on this and to spendso much time thinking outside the box. The simpletruth of my answer only struck me afterwards.With BLACK & WHITE, we made thegame that we wanted to play.

161Bungie Software’sMYTH: THE FALLENLORDSby jason regierAs the team at Bungie Software put the finishingtouches on the MARATHON series of first-personaction games, our thoughts drifted to bringingour 3D game experience to the real-time strategygame (RTSG) genre. We were inspired bymovies such as Braveheart, with its close-upportrayal of bloody melees between large forces,and books such as Glen Cook’s The Black Company,in which gruesome tales of battle contrastwith engaging and intriguing characters. Weenvisioned a dark, amoral world where opposingsides are equally brutal and their unity istorn by power struggles within the ranks. Wedreamed of game play that combined the realismand excitement of action games with thecunning and planning required by strategygames.Our original design document, if you could callit that, was simply opposing lists of “Stuff thatRocks” and “Stuff that Sucks.” Anythingvaguely cliché, such as excessive references toTolkien novels, Arthurian legend, or “little boyscoming of age and saving the world,” went inBack-StoryMYTH: THE FALLEN LORDS uses the same overheadview as real-time strategy games, but brings the perspectivelower to portray the bloody details of tacticalconflict in a fantasy setting. The game follows the fortunesof one legion in an army of allied peoples fightinga desperate, losing war against the undead armies ofthe Fallen Lords. Well-balanced units and successfulmultiplayer make this a successful piece of gamedesign, and the grim atmosphere of this well-executedfantasy tale leaves a lasting impression.the “Sucks” category. The “Stuff that Rocks”list was filled with ideas that contributed to thevisual realism of the game: a true 3D landscape,polygonal buildings, reflecting water, particlebasedweather, “blood-spattered battlefields litteredwith limbs,” explosions that send shockwaves through the terrain, and “lightning fryingguys and their friends.”Our goals for the product were lofty: simultaneousrelease on Windows 95 and Macintoshplatforms, integrated Internet play, and a freeonline service to allow players from across theglobe to battle one another. From this vision,MYTH: THE FALLEN LORDS was born.

Bungie Software’s MYTH: THE FALLEN LORDS 162The Making of aLegend, er, MythGame DataRelease Date: November, 1997Genre: 3D real-time strategy; fantasyPublishers: Eidos, Pacific CoastPlatform: Windows and MacintoshThe project began in January 1996 with fourprogrammers, two artists, and a product manager.Midway through development, one programmerdropped out and an artist was added.Music, sound effects, and cut scenes were doneout-of-house, and a few artists were contractedto help with interface artwork. The roots of theMYTH programming team were on the Macintosh,so most initial coding was done on theMac with Metrowerks CodeWarrior. When PCbuilds were required, though, we usedMicrosoft Visual C/C++. MYTH was writtenentirely in C.In addition to creating the shipping product, wedeveloped four tools to aid in the constructionof the game. One utility, the Extractor, handledthe importing of sprites and the sequencing oftheir animations. Another tool, dubbed Fear,dealt with importing polygonal models such ashouses, pillars, and walls. The Tag Editor wasresponsible for editing the constants stored incross-platform data files, which we called tags.And finally, Loathing, our map editor, handledthe rest. Loathing was built around the MYTHengine and allowed us to modify the landscape,apply lighting, set terrain types, script the AI,and place structures, scenery, and monsters.The artists used Alias|Wavefront’s PowerAnimatorand StudioPaint on a single Silicon GraphicsIndigo 2 to create polygonal models and renderall the characters. At one point, the artistsworked separate day and night shifts so thatthey could maximize their time on the SGI.Models were brought into the game using Fear,while the sprites were cleaned up in Adobe Photoshopand imported with the Extractor. To createthe texture maps for the terrain, the artistsused Photoshop to draw what looked like anaerial photo and applied it to a 3D landscape inLoathing.If this sounds like a lot of work to you, you’reright. Most maps took at least a week or two tocreate. We considered using fractal-generatedlandscapes, but we were worried that the inherentrandomness of such terrain would make itextremely difficult to design good levels. As aresult, all maps were painstakingly constructedby hand. As the artists put the finishing toucheson the landscapes, the programmers, who doubledas level designers, scripted the AI for thelevels.MYTH took approximately two years fromstart to finish. It began as a six-degrees-of-freedomengine that allowed you to fly around alandscape. Soon, troops were added, headsstarted flying, blood was made to destructivelyalter the terrain’s color map, and the networkgame was born. Most of the first year was spentdeveloping the initial network/multiplayergame play. Almost the entire second year was

163SECTION III: MANAGING INNOVATION163spent developing the single-player game, refiningthe levels, and testing bungie.net, our freeonline service.What Went Right1. Bringing carnage to themassesIt’s a real trick to create a simultaneous, identical-look-and-feel,cross-platform release. It’seven harder to do so within the expected timeframe with only three programmers.Our experience portingMARATHON, our popular Macintosh-onlyaction game, to Windows95 was a valuable learningexperience, and we vowed whenstarting MYTH that, “This time,we’re going to do it right.”Doing it “right” meant designingMYTH from the ground up to becross-platform compatible.Ninety percent of the code in thegame is platform independent; theother ten percent is split evenly between routinesthat handle PC- and Macintosh-specific functionality.It was a programmer’s dream cometrue—we spent almost all our time implementingfeatures and solving real problems, rather thanwasting it fighting the OS.All of the data for MYTH, from animated cutscenes to the percentage of warriors who areleft-handed, is stored in platform-independentfiles called tags. Tags are automatically byteswapped when necessary and are accessed via across-platform file manager.One of our programmers worked in conjunctionwith Apple Computer Inc. to develop a crossplatformnetworking library code-named Über.One of the greatest things about Über is that itsupports plug-in modules for network protocols.Thus, although MYTH currently onlyallows games over TCP/IP, AppleTalk, andthrough TEN, it would be trivial to add supportfor new protocol modules. MYTH must providea user interface to set up the connection, butonce Über establishes that connection, gameplay over a LAN is the same asover the Internet.To keep the game’s appearanceidentical across platforms, weimplemented our own dialog andfont managers. This allowed us(actually, it required us) to usecustom graphics for all interfaceitems. We designed our font managerso that it supported antialiased,two-byte fonts, as well asa variety of text-parsing formats.Thus, our overseas publishersEidos and Pacific Software Publishing were ableto localize relatively painlessly. The German versionof MYTH was finished only a couple ofweeks after the English release, with Japaneseand French versions close behind. The onlygame experience that is different for the twoplatforms is the installation, and two players onbungie.net have no idea whether their opponentsare on Macintoshes or PCs.

Bungie Software’s MYTH: THE FALLEN LORDS 1642. bungie.net and beta testingMYTH was also released with integrated supportfor our first online service, bungie.net. This servicewas designed specifically for MYTH andwas developed simultaneously. Similar to onlineservices for other games, it allows players toconnect via the Internet to game rooms,where they can chat or play againstone another. The Linux-based serverthat runs bungie.net keeps track ofplayer statistics and gives everyonea score in our ranking system.The service’s Web site(www.bungie.net) has accessto this database and sports aleader board that lists thetop players.Our networking layer is based on aclient/server model. Once you advertisea game on the network, you become aserver, and other players join your game.Network traffic during a game is limited tothe commands issued by the players. All copiesof MYTH in a network game run deterministicallyand merely interpret the commands thatthey receive. This makes cheating difficult; ifyou hack the game to perform something illegal,such as making all your units invincible, you’llgo out of sync with other players. When portionsof the game data are periodically checksummedand compared, a message will indicatethat you’re out of sync (and out of luck). So far,the only form of cheating we’ve encountered isusers trying to exploit the bungie.net rankingsystem.To rigorously test our server load capacity andthe bungie.net code, we released a public beta ofthe network game. Initially we were apprehensivebecause it was our first public beta test of aproduct, but it was an amazing success. Whenerrors occur, MYTH alerts the player, logs theerror messages, and usually allows the user tosave a replay of the problem. Testers submittedthese detailed bug reports via e-mailand chatted about features and improvementsto levels on internal newsgroups.Best of all, the testers usedbungie.net to give instantfeedback to the developers.This interaction allowed usto gather even more usefulinformation about bugs, and itmade the testers really feelinvolved in the final product. By theend of the beta-testing cycle, we notonly had a clean product, but also had aloyal following of users who sang ourpraises when the NDAs were lifted.3. 3D graphics accelerationWhen the project started, 3D acceleration hardwarewas only just starting to become popular.Nevertheless, we tried to keep hardware accelerationin mind when designing our renderingpipeline. When the opportunity arose to addhardware acceleration, the implementationworked beautifully.We worked closely with people from 3Dfx andRendition and added support for their chipsets

165SECTION III: MANAGING INNOVATION165in about a week. It’s amazing how much theseaccelerators add to the smoothness of the terrain,the fluidity of camera movement, and therealism of the units and effects. These chipsrock, and great on-site developer assistancemade them easy to support.4. Getting back to the peopleOnce we had released MYTH, we definitely didthe right thing by waiting for player feedbackand then releasing a patch to address theirissues. Since our public beta test caught most ofthe bugs in the shipping product, nearly all ourpost-shipping efforts were directed towardsadding user-requested features.We scoured the newsgroups,read email, and talkedto customers about their complaints.From these disparatesources, we compiled a list ofimprovements for our 1.1patch.All major user complaints were addressed in thepatch. We added support for Rendition andVoodoo Rush cards. We extended the camera’smaximum zoom for a better view of the battlefield.We made our easy difficulty levels eveneasier. And we improved the unit AI. By thetime the early reviews came out, we’d alreadyreleased a beta patch that addressed almosteverything on the reviewers’ lists of MYTH’sfailings.5. Doing more with lessIt doesn’t take fifty people to create a majorcross-platform software title. Period. BungieSoftware has barely half that number ofemployees in the entire company, and we notonly develop all our games, but publish and distributethem as well! Macintosh and PC versionsof MYTH, all our internal tools, and ouronline service were essentially developed by onlysix people, and everything shipped on time withno major glitches. There’s no big quality assurancedepartment here at Bungie; the public didour testing for us, and we listened to them asseriously as if they were coworkers on theproject.We didn’t hire any game designers, writers, orlevel designers to come up with our game conceptand story line. MYTHtruly is the combined vision ofour team, and each of us feelsthat it was our game. We cameto work each day excitedabout the project, and we’redamn proud of what we managedto create.What Went Wrong1. Staffing problemsOn the flip side, it became clear very early in theproject that we were understaffed for such anambitious undertaking. Success or failure restedwith a handful of people, and that wasextremely stressful. Losing a programmer halfwaythrough development added still more pressureduring the final push to get the game outthe door. Additional programming tasks had to

Bungie Software’s MYTH: THE FALLEN LORDS 166be shouldered by the remaining developers, whowere already also responsible for level design.To alleviate the problem somewhat, we evenfound it necessary to ask our busy networkadministrator to aid in AI scripting and leveldesign.We did hire a third artist nearthe end of the project, but itwas almost too late. While hiscontributions to the finalproduct were by no meansinsignificant, it took a longtime to get him up to speed.Similarly, when we droppedthe services of our originalsound guy late in the developmentcycle, a new sound teamhad to rush to redo all thework.If you’re looking for goodanecdotes about how we blewoff steam with wild weekendtrips to Cancún, you won’t getany. We all worked incrediblyhard, and did so willingly because MYTH representeda two-year labor of love. All the greatpreviews and supportive feedback from betatesters kept us excited and made us realize thatwe really did have something special on ourhands. Nobody wanted to slack off and allowcompeting products to beat us to the shelves.The moral of the story: staff up as early as possibleand plan to weather the unexpected.2. ScriptingThe biggest announced feature that didn’t makeit into the final version of MYTH was a scriptinglanguage that would allow the player to modifyelements of the game. We had hoped that userscripts could be written for extensible artificialintelligence, as well as customformations, net game rules,and map behaviors. Weselected Java as a good basisfor the MYTH scripting languagebecause of its gainingpopularity, good informationhidingcapabilities, and relativelysimple byte code interpretation.After several months of work,early versions of the gameloaded, compiled, and rancode from tag files. A few simplescripts worked for presentationpurposes, including onethat instructed a unit to searchthe battlefield for the heads ofthe enemy and collect them in a pile. Unfortunately,when the programmer responsible forthe scripting language parted ways with Bungie,we were left with a number of features to implementand no library of user-friendly interfaceswith the game code. Given its incomplete stateat such a late stage of development, there waslittle choice but to drop this functionality.

167SECTION III: MANAGING INNOVATION1673. More frames of animationOne of the complaints most often voiced byplayers is that the sprite-based units’ animationsare not fluid enough. At the start of the project,when we planned for the number of frames ofanimation per unit, there was a good deal ofuncertainty regarding how much RAM wouldbe consumed by large texture maps, sounds,and other resources. As things were, it wasnot uncommon for our landscape textures toreach 5MB in size, and certain animationsalready consumed close to 1MB—our uncertaintieswere not unfounded. We erredon the conservative side. Though weimplemented caching schemes thatgreatly reduced our memoryrequirements, there wasn’tenough time to rerender the units.4. PathfindingPerfect pathfinding seems to havebecome the Holy Grail for games in theRTS genre, and MYTH is no exception.The game’s terrain is a 3D polygonalmesh constructed from square cells,each of which is tessellated into twotriangles. Cells have an associatedterrain type that indicates theirimpassability, and they may contain any numberof solid objects, including trees, fence posts,and units.Ah! Square cells, you say? Having read previousGame Developer articles (Bryan Stout, “SmartMoves: Intelligent Pathfinding,” Game Developer,October/November 1996; Swen Vincke,“Real-Time Pathfinding for Multiple Objects,”Game Developer, June 1997), your first thoughtmay be that the A* pathfinding should do thetrick.The first problem with a pure A* approach forMYTH is that impassable obstacles, such astroops and trees, may lie anywhere on the terrain.Penalizing the cells beneath impassableobstacles is a bad idea because the cells arefairly large and obstacles are not guaranteedto be aligned at the center of a cell.Furthermore, even if a tree did consumeexactly one cell, the A* path to avoidit would make a unit walk up to thetree, turn, and continue around it.Units that bump into trees and walkbetween the centers of large cellsappear extremely stupid; youreally want your group of troopsto avoid obstacles (including eachother) ahead of time, andsmoothly weave their waythrough a forest.To produce this effect, we created ourown pathfinding algorithm. First, weignore all obstacles and calculate the A*path based solely on the terrain impassability.For all intents and purposes,the terrain in MYTH never changes, sothis path can be calculated once andremembered. Now, we consider the arbitrarilyplaced obstacles and periodically refineour path using a vector-based scheme. If theplanned path would cause us to hit an obstacle,we need to deviate our path. We recursively considerboth left and right deviations, and choosethe direction that causes us to deviate least from

Bungie Software’s MYTH: THE FALLEN LORDS 168our A* path. Thus, we’ve considered terrainimpassability information and we can avoidarbitrarily placed (or even moving) obstacleswell before we bump into them.For every game, pathfinding is a pretty complexand sensitive beast. This method worked wellfor 90 percent of our cases, but rigorous testingrevealed certain cases that were not adequatelyhandled. As the ship date drew near, we wereforced to say “good enough” rather than handlethese problem cases and risk introducing newbugs. Our current algorithm works pretty welland provides the effect we sought, but there’sdefinitely room for improvement.5. Features that missed the cutWith a few exceptions, everything from our listof “Stuff that Rocks” made it into the finalproduct. Those features that didn’t make itcame so close and were so exciting that they definitelydeserve mention.Near the end of the project, we started addingsupport for 3D fire, which would be ignited byexplosions and flaming arrows. Our flames weresprite-based 3D particle effects, complete withtranslucent smoke. Fire could spread across thelandscape and move at different rates over thevarious types of terrain. To our dismay, when aspark in the woods spread into a raging forestfire (as it should), all the translucent smokesprites slowed even fast, 3Dfx-acceleratedmachines to a crawl. With little time to rectifythe problem, we had to put out the fire, so tospeak.We had also planned for wildlife to scamperacross the terrain and for birds to fly throughthe air, breathing life into our empty landscapes.Our attempt at ambient life started with a giantsquirrel created by one of our artists. Unfortunately,due to time constraints, we didn’t have achance to create very interesting behaviors forit. Just about the only AI that we had a chanceto code simply made the squirrels gravitatetowards the player’s units. We thought it best todrop ambient life rather than subject players tohordes of nuzzling squirrels.Post-ReleaseReactionsWith all the prerelease hype MYTH had received,we were very anxious to see how the publicwould receive the final version. The reactionsfrom beta testers were phenomenally positive, aswere the comments from customers and reviewers.Our swiftness in correcting problems andadding several user-requested features with a 1.1

169SECTION III: MANAGING INNOVATION169patch only earned us more kudos from the pressand public.But possibly the most satisfying result of thegame is the degree to which it lessens the appealof playing with a traditional isometric perspective.Working on MYTH so consumed our timethat we didn’t get a chance to play anything else;we looked forward to playing some old favoritesand the latest demos of our high-profilecompetition after we shipped. It was a real surpriseto discover that once we were accustomedto MYTH’s 3D camera and its associated freedom,playing isometric games was frustrating—theaction seemed distant and unrealistic,while the view of the world was annoyinglyrigid. This sentiment was echoed in both playercomments and reviews of the game.The MYTH development team. FROM LEFT toRIGHT: Mark Bernal (artist), Frank Pusateri(artist), Rob McLees (artist, holding statue ofa Trow), Jason Regier (programmer), JasonJones (programmer/project leader) MarcusLehto (artist). NOT PICTURED: Ryan Martell(programmer), Tuncer Deniz (productmanager), Jay Barry (level design).Since our MARATHON products were derided bysome as DOOM rip-offs, it was especially satisfyingto hear players say that MYTH pushes thegenre in a new direction, from which there’s nolooking back. It remains to be seen whetherMYTH will inspire other entries into the 3D realtimestrategy game genre. But if nothing else,MYTH is proof that a very small team with astrong product vision can still make a very biggame.

This Page Intentionally Left BlankBungie Software’s MYTH: THE FALLEN LORDS 170

171Looking Glass’sTHIEF: THE DARKPROJECTby tom leonardTHIEF: THE DARK PROJECT is one of thosegames that almost wasn’t. During the longstruggle to store shelves, the project faced thethreat of cancellation twice. A fiscal crisis nearlyclosed the doors at Looking Glass. During oneseven-month span, the producer, project director,lead programmer, lead artist, lead designerand the author of our renderer all left. Worsestill, we felt a nagging fear that we might make agame that simply was not fun. But in the end,we shipped a relatively bug-free game that wehad fun making, we were proud of, and that wehoped others would enjoy.The ConceptThe THIEF team wanted to create a first-persongame that provided a totally different gamingexperience, yet appealed to the existing first-personaction market. THIEF was to present alightly-scripted game world with levels of playerinteraction and improvisation exceeding ourprevious titles. The team hoped to entice theplayer into a deep engagement with the worldby creating intelligible ways for the world to beBack-StoryIn the early 90s, Looking Glass Studios helped inventfirst-person 3D gaming with ULTIMA UNDERWORLD andSYSTEM SHOCK and, in the late 90s, reinvented the formwith THIEF: THE DARK PROJECT. THIEF breaks out of thefirst-person shooter model and shifts the emphasis tostealth. Looking Glass developed lighting, AI, and audiotechnologies to allow players to use silence and shadowand sneak attacks rather than firepower to achieve theirgoals. In keeping with this new style of play, they gavethe game a cynical thief for a hero and set it in a halffantasy,half-Victorian steampunk world.impacted by the player. The central gamemechanic of THIEF challenged the traditionalform of the first-person 3D market. First-personshooters are fast-paced adrenaline rushes wherethe player possesses unusual speed and stamina,and an irresistible desire for conflict. The expertTHIEF player moves slowly, avoids conflict, ispenalized for killing people, and is entirely mortal.It is a game style that many observers wereconcerned might not appeal to players, and eventhose intimately involved with the game haddoubts at times.The project began in the spring of 1996 asDARK CAMELOT, a sword-combat action gamewith role-playing and adventure elements, basedon an inversion of the Arthurian legend.Although development ostensibly had been in

Looking Glass’s THIEF: THE DARK PROJECT 172progress on paper for a year, THIEF realisticallybegan early in 1997 after the game was repositionedas an action/adventure game of thieveryin a grim fantasy setting. Up to that point wehad only a small portion of the art, design, andcode that would ultimately make it into theshipping game.Game DataRelease date: December 1998Publisher: CyanGenre: first-person stealth/action; fantasyIntended platform: Windows 95/98Project budget: Approximately $3 millionProject length: 2.5 yearsTeam size: 19 full-time developers. Some contractors.Critical development software: Microsoft Visual C++5.0, Watcom C++ 10.6, Opus Make, PowerAnimator,3D Studio Max, Adobe Photoshop, AntimatorPro,Debabelizer, After Effects, and Adaptive Opticsmotion-capture processingFull development began in May 1997 with ateam comprised almost entirely of a differentgroup of people from those who started theproject. During the following year, the team createda tremendous amount of quality code, art,and design. But by the beginning of summer in1998, the game could not be called “fun,” theteam was exhausted, and the project was facedwith an increasingly skeptical publisher.The Looking Glass game design philosophyincludes a notion that immersive gameplayemerges from an object-rich world governed byhigh-quality, self-consistent simulation systems.Making a game at Looking Glass requires a lotof faith, as such systems take considerable timeto develop, do not always arrive on time, andrequire substantial tuning once in place. ForTHIEF, these systems didn’t gel until mid-summer,fifteen months after the project began fulldevelopment, and only three months before wewere scheduled to ship.When the game finally did come together, webegan to sense that not only did the game notstink, it might actually be fun. The release ofsuccessful stealth-oriented titles (such as METALGEAR SOLID and COMMANDOS) and more content-richfirst-person shooters (like HALF-LIFE)eased the team’s concerns about the market’swillingness to accept experimental game styles.A new energy revitalized the team. Long hoursdriven by passion and measured confidencemarked the closing months of the project. In thefinal weeks of the project the Eidos test and productionstaff joined us at the Looking Glassoffices for the final push. The gold master wasburned in the beginning of November, just intime for Christmas.In many ways, THIEF was a typical project. Itprovided the joys of working on a large-scalegame: challenging problems, a talented group ofpeople, room for creative expression, and theoccasional hilarious bug. It also had some of theusual problems: task underestimation, bouts oflow morale, a stream of demos from hell, anunrealistic schedule derived from desire ratherthan reality, poor documentation, and an insufficientup-front specification.However, THIEF also differed from a number ofprojects in that it took risks on numerous fronts,

173SECTION III: MANAGING INNOVATION173risks that our team underappreciated. Wewanted to push the envelope in almost every elementof the code and design. The experimentalnature of the game design, and the time it tookus to fully understand the core nature of thatdesign, placed special demands on the developmentprocess. The team was larger than anyLooking Glass team up until then, and at timesthere seemed to be too many cooks in thekitchen. Reaching a point where everyoneshared the same vision took longer thanexpected. A philosophy of creatinggood, reusable game engine componentscreated unusual challengesthat didn’t always fit well withschedule and demo pressures. Themany risks could have overwhelmedthe project, if not for thededication, creativity, and sacrificesof the team.Throughout the life of the project,more than 50 people worked in oneway or another on THIEF—some aspart of the CAMELOT project, othersas part of the Looking Glass audiovisualand technology support staff,some as helpful hands from otherLooking Glass projects. The core team consistedof a number of veterans of previous LookingGlass titles (UNDERWORLD I and II, SYSTEMSHOCK, FLIGHT UNLIMITED, TERRA NOVA,BRITISH OPEN CHAMPIONSHIP GOLF, and theunpublished STAR TREK: VOYAGER), as wellas some new industry arrivals. The project had anumber of very talented people and strong wills.Although it took some time for the team tounite as a tight-knit creative force, the final sixmonths were incredibly productive, spirited,and punishingly fun.What Went Right1. Designing data-driven toolsOur experience on previous titles taught us thatone of the impediments to timelygame development is the mutualdependence of artists, designers,and programmers at every developmentstage. One of the developmentgoals for the Dark Engine, onwhich THIEF is built, was to create aset of tools that enabled programmers,artists, and designers to workmore effectively and independently.The focus of this effort was to makethe game highly data-driven andgive non-programmers a highdegree of control over the integrationof their work. Media and gamesystems were to be easily and intuitivelyplugged in and edited by theteam members responsible for theircreation, without requiring the direct involvementof programmers.The Dark Object System stood at the heart ofour strategy. Primarily designed by programmerMarc “Mahk” LeBlanc, the Object System wasa general database for managing the individualobjects in a simulation. It provided a genericnotion of properties that an object might possess,and relations that might exist between two

Looking Glass’s THIEF: THE DARK PROJECT 174objects. It allowed game-specific systems to createnew kinds of properties and relations easily,and provided automatic support for saving,loading, versioning, and editing properties andrelations. It also supported a game-specific hierarchyof object types, which could be loaded,saved, and edited by designers. Programmersspecified the available propertiesand relations, and theinterface used for editing,using a set of straightforwardclasses and structures. UsingGUI tools, the designers specifiedthe hierarchy and compositionof game objectsindependent of the programmingstaff. In THIEF therewas no code-based gameobject hierarchy of any kind.Although the implementationof the system was much morework than we expected, andmanagement of the objecthierarchy placed significantdemands on lead designerTim Stellmach, it turned outto be one of the best things inthe project. Once the set ofavailable properties and relations exposed byprogrammers was mature, the Object Systemallowed the designers to specify most of thebehaviors of the game without scripting or programmerintervention. Additionally, the relativeease with which variables could be made availableto designers in order to tweak the gameencouraged programmers to empower thedesigners thoroughly.Concept sketches of Hammer anda burrick.The second major component of our strategywas our resource management system. Theresource management system gave the gamehigh-level management control of source data,such as texture maps, models, and digitalsounds. It helped manage the game’s use of systemmemory, and provided the data flow functionsnecessary forconfiguration management.Looking Glass’s previousresource management systemprovided similar functionality,but identifiedresources by an integer IDand required a specialresource compilation step.This technique often requiredrecompilation of the gameexecutable in order to integratenew art, and requiredthat the team exit the gamewhen resources were publishedto the network.The new system referred to aresource by its file name withoutits extension, used a filesystem directory structure fornamespace management,didn’t leave files open while working, andrequired no extra compilation step. Developerssimply dropped art into their local data tree andstarted using it. To expose art to the rest of theteam, lead artist Mark Lizotte just copied artinto the shared project directories. Compoundresources were treated as extensions to the filesystem and were built using the standard .ZIPformat. This allowed us to use off-the-shelf tools

175SECTION III: MANAGING INNOVATION175for constructing, compressing, and viewingresource files.The system facilitated content development byallowing programmers, artists, and designers toadd new data to an existing game quickly. Thedata-driven approach worked so well thatthrough much of our development, THIEF andSYSTEM SHOCK 2 (two very different games)used the same executable and simply chose adifferent object hierarchy and data set at runtime.2. Sound as a game designfocusSound plays a more central role in THIEF than inany other game I can name. Project directorGreg LoPiccolo had a vision of THIEF thatincluded a rich aural environment where soundboth enriched the environment and was an integralpart of gameplay. The team believed in andachieved this vision, and special credit goes toaudio designer Eric Brosius.As an element of thedesign, sound playedtwo roles in THIEF. First,it was the primarymedium through whichthe AIs communicatedboth their location andtheir internal state to theplayer. In THIEF we triedto design AIs with abroader range of awarenessthan the typical twoHand-to-hand combat is sometimesnecessary.states that AIs exhibit: “oblivious” and “omniscient.”Such a range of internal states would bemeaningless if the player could not perceive it,so we used a broad array of speech broadcast bythe AIs to clue in the player.While very successful for humanoid AIs, we feelthe more limited expressibility of non-humancreatures is the heart of why many customersdidn’t like our “monster levels.” Second, thedesign used sounds generated by objects in thegame, especially the player, to inform AIs abouttheir surroundings. In THIEF, the AIs rarely“cheat” when it comes to knowledge of theirenvironment. Considerable work went into constructingsensory components sufficient to permitthe AIs to make decisions purely based onthe world as they perceive it. This allowed us touse player sounds as an integral part of gameplay,both as a way that players can reveal themselvesinadvertently to the AIs and as a tool forplayers to distract or divert an AI. Moreover,AIs communicated with each other almostexclusively through sound. AI speech andsounds in the world,such as the sound ofswords clashing, wereassigned semantic values.In a confrontation,the player could expectnearby AIs to becomealarmed by the sound ofcombat or cries for help,and was thus encouragedto ambush opponentsas quietly aspossible.

Looking Glass’s THIEF: THE DARK PROJECT 176In order for sound to work in the game asdesigned, we needed to implement a sound systemsignificantly more sophisticated than manyother games. When constructing a THIEF mission,designers built a secondary “room database”that reflected the connectivity of spaces ata higher level than raw geometry. Although thiswas also used for script triggers and AI optimizations,the primary role of the room databasewas to provide a representation of the worldsimple enough to allow realistic real-time propagationof sounds through the spaces. Withoutthis, it is unlikely the sound design could havesucceeded, as it allowed the player and the AIsto perceive sounds more as they are in real lifeand better grasp the location of their opponentsin the mission spaces.3. Focus, focus, focusEarly on, the THIEF plan was chock full of featuresand metagame elements: lots of playertools and a modal inventory user interface tomanage them; multiplayer cooperative, deathmatchand “Theft-match” modes; a form ofplayer extra-sensory perception; player capacityto combine world objects to create new tools;and branching mission structures. These andother “cool ideas” were correctly discarded.Instead, we focused in on creating a singleplayer,linear, mission-based game centeredexclusively around stealth, with a player toolsetthat fit within the constraints of an extension ofthe QUAKE user interface. The notion came intofull force with two decisions we made aboutseven months before we shipped.First, the project was renamed THIEF from theworking title THE DARK PROJECT, a seeminglyminor decision that in truth gave the team aconcrete ideological focus. Second, we decidedpreemptively to drop multiplayer support, notsimply due to schedule concerns, but also toallow us as much time as possible to hone thesingle-player experience. In the end, some missionsdidn’t achieve the stealth focus wewanted, particularly those originally designedfor DARK CAMELOT, but the overall agenda wasthe right one.4. Objectives and difficultyOne of the THIEF team’s favorite games duringdevelopment was GOLDENEYE on the N64. Wewere particularly struck by the manner in whichlevels of difficulty were handled. Each level ofdifficulty had a different overlapping set ofobjectives for success, and missions were subtlychanged at each level in terms of object placementand density. Relatively late in the developmentof THIEF, we decided such a system wouldwork well in our game. Extending the concept,we added a notion that as difficulty increased,the level of toleration of murder of humanbeings decreased. We also allowed players tochange their difficulty level at the beginning ofeach mission.The system was a success in two ways. First, itmade clear to the player exactly what “difficulty”meant. Second, it allowed the designersto create a very different experience at each levelof difficulty, without changing the overall geometryand structure of a mission. This gave the

177SECTION III: MANAGING INNOVATION177game a high degree of replayability at a minimumdevelopment cost.5. Multiple, narrow-purposescripting solutionsAlthough the Object System provided a lotof flexibility, we also needed a scripting languageto fully specify object behaviors.Rather than create a single all-encompassingscripting system, we chose to develop severalmore focused tools for scripting. Thistiered scripting solution worked well. In creatingour core “high-end” object scriptingtechnology, we wanted to allow designerswith moderate programming skill to createcomplex object behaviors easily. Scriptswere event-driven objects attached at runtimeto game objects, and contained data,methods, and message handlers. The gameprovided a election of services to allow thescript to query the world state and the gameobject state, and also to perform complextasks.Though used by both programming-savvydesigners and programmers, the fact that it wasa real programming language prevented widespreaduse by all of the designers. Most designerswere interested in customizing AI behaviors.For the AI we created a simpler scripting system,“Pseudo-scripts,” that were implemented asproperties within the Object System. Pseudoscriptstook the burden of coding scripts off ofStealth is one of your best weapons in THIEF. The game’sdesigners made sure that expert players would have tomake effective use of silent weapons such as theblackjack and the bow and arrow.Our goal was to create a scripting language thatoffered source-level debugging, was fast, andwas dynamic. The solution was essentially C++in .DLLs, compiled by the C++ compiler, using acombination of classes and preprocessor macrosto ease interface publishing, handle dynamiclinking, and provide designers a clear programmingmodel.the designers. The AI provided a stock set oftriggers, such as “I see the player near anobject” or “I see a dead body;” the designerprovided the consequence of the trigger. EachPseudo-script was edited in a dialog box presentingparameters to tweak the “if” clause ofthe trigger, and space for a list of simple, unconditionalactions to perform when the triggerfired. In this way, the custom behavioral possibilitiesof the AI at any moment were describedby the aggregate of Pseudo-scripts that wereattached to that AI.

Looking Glass’s THIEF: THE DARK PROJECT 178This approach had three benefits. First, it wassimple enough so that designers with no programmingexperience were comfortable using it.Second, it narrowed the range of triggers adesigner could use to a good pre-selected set,rather than giving them an open-ended systemthat might not have worked as well. Finally,when and how to evaluate AI triggers, a potentialrun-time expense if not carefully constructed,could be custom built by a programmer.The final scripting system built into THIEF wasthe Tagged Schema system. When the gamerequired motions and sounds, it requested themas concepts modified by optional qualifiers,rather than directly. Forexample, an AI who had justheard the player wouldrequest the concept “moderatealert,” qualified with anoptional tag like“+sense:sound.” A potentialset of resources was thenchosen using a patternmatcher; in this example, itwould choose all samples inthat AI’s voice expressing ageneric “something’s notright,” all samples expressing“I heard something fishy,”but no samples expressing “Isaw something fishy.” Fromthis set, the specific resourcewas then chosen using aweighted random selection.The tables used were specified by the designersusing a simple language. Specifying motion andsound selection this way, designers created aninteresting variety of randomized environmentsand behaviors without changing the code of thegame.What Went Wrong1. Trouble with the AIIf one thing could be called out as the reasonTHIEF’s gameplay didn’t come together until latein the process, it would be the AI. The AI as afoil to the player is the central element of THIEF,and the AI we wanted wasn’t ready until late inthe spring of 1998. As leadprogrammer and author ofthe final AI, I take fullresponsibility for that.The original AI for THIEF wasdesigned by another programmerbefore the requirementsof the revised stealthdesign were fully specified.Six months after it wasbegun, the project directorand overseer of the systemleft the team, and the most ofthe programming staff wastemporarily reassigned tohelp ship another game thatwas in trouble. During thefollowing months, developmenton that AI continued without any oversightand without a firm game design. Soon after, theprogrammer working on the AI also left.

179SECTION III: MANAGING INNOVATION179While the core pathfinding data structures andalgorithms were basically sound, the code thatgenerated the pathfinding database wasextremely buggy. The design of the AI decisionprocess was geared towards an action fightinggame requiring little designer customization,rather than a stealth game that needed muchmore customization. Even worse, the high-leveldecision process in the AI had drifted away froma rigorous design and the code was extremelybrittle. The whole situation was a disaster.These might not have been serious issues, exceptfor one key mistake: I didn’t realize the depth ofthe problem quickly enough, and despite concernsexpressed by programmer/designer DougChurch, I didn’t act fast enough. I think highlyof the programmer involved with the initial AIand wanted to avoid the natural but often misguidedprogrammer reaction within myself thatI should just rewrite it my way. So, I took theposition that, while buggy, the system as awhole was probably sound. Several months andmany sleepless nights later, I concluded that Ihad been sorely mistaken.By November 1997, I had the basics of a newdesign and began working on it. But all workhad to stop in order to pull together an emergencyproof-of-concept demo by the end ofDecember to quell outside concerns that theteam lacked a sound vision of the game. Thisturned into a mid-January demo, followed by anearly February publisher demo, followed by alate February make-or-break demo. During thistime the only option was to hack features asbest we could into the existing AI.While better than losing our funding, constructingthese demos was not good for the project. Inthe end, work on the new AI didn’t begin untilmid-March. Despite the fact that our scheduledship date was just six months away, we threwaway four-fifths of our existing AI code andstarted over. After a hair-raising twelve-weekstretch of grueling hours, the AI was ready forreal testing. Had I committed to a rewrite twomonths earlier the previous autumn, I believethe AI would have been ready for real use threeto five months sooner.2. An uncertain rendererThe project was started because of the renderer,rather than the reverse. The basic core of therenderer for THIEF was written in the fall of1995 as an after-hours experiment by programmerSean Barrett. During the following year, therenderer and geometry-editing tools werefleshed out, and with DARK CAMELOT supposedto ship some time in 1997, it looked like wewould have a pretty attractive game. Then, atthe end of 1996, Sean decided to leave LookingGlass. Although he periodically contracted withus to add features, and we were able to addhardware support and other minor additions,the renderer never received the attention itneeded to reach the state-of-the-art in 1998.The possibility that we might not have a pointprogrammer for the renderer weighed heavilyon the team. Fortunately, Sean remained availableon a contract basis, and other members ofthe team developed sufficient knowledge of therenderer so that we shipped successfully. In theend, we shipped a renderer appropriate for our

Looking Glass’s THIEF: THE DARK PROJECT 180gameplay, but not as attractive as other highprofilefirst-person titles.This may prompt the question of why we didn’tsimply license a renderer. When the projectstarted a few months into 1996, the avalancheof QUAKE licenses hadn’t really begun andUNREAL was still two years away. By the timelicensing was a viable choice, the game and therenderer were too tightly integrated for us toconsider changing.the doors would be locked when you got there.The company shed half of its staff in a span of sixmonths, and while the active teams tried to stayfocused, it was hard when one day the plantswere gone, another day the coffee machine, thenthe water cooler.Some of the THIEF team couldn’t continue underthese conditions. We lost two programmers,including the former lead programmer, and adesigner. When we were forced to close our Austinoffice, we lost our producer, Warren Spector,as well as some programmers who made valuabletechnology contributions to our engine. Allof these individuals are now on Ion Storm’sDEUS EX team. Although it took some monthsto fully restore the spirit of the rest of the team,we held together and the company eventuallyrebounded. Perhaps it bestowed a stoicism thatcomes from knowing that however bad thingsmight seem, you’ve already seen worse.One of the featured weapons is the fire arrow.3. Loss of key personnel amidcorporate angst beyond ourcontrolMidway through 1997, THIEF was just starting togather momentum. We were fully staffed and thestealth design was really starting to get fleshedout. Unfortunately, Looking Glass’s financial situationwas bleak. Few emotions can compare tothe stress of heading to work not knowing whomight be laid off, including yourself, or whether4. Undervalued editorOne of the boils never lanced on the project wasour editor, Dromed. Although it was sufficientlypowerful and provided the essential functionalitywe needed to ship the game, Dromed was apoorly documented and sometimes disagreeableeditor. Dromed was first developed as a demonstrationeditor when the target platform of thegame was DOS. As a demo, it never received thekind of formal specifications and designs onewould expect for the central experience of thedesign team. As a DOS application, it lacked theconsistent and relatively easy-to-use user-interfacetools of Windows.

181SECTION III: MANAGING INNOVATION181An early mistake was our failure to step backand formally evaluate the editor, and thenrebuild it based on our experience constructingthe demo editor. We also should have designed aproper editor framework, and hired a dedicatedWindows user-interface programmer to supportit through development. In retrospect, the timelost cleaning up the editor probably would havebeen saved on the back end of the project.5. Inadequate planningAlthough it is a cliché in the software industryto say our scheduling and budget planning werewoefully inadequate, the THIEF project sufferedgreatly from this malady. There were several elementsto our deficient planning. During DARKCAMELOT, and continuing through the first halfof THIEF, we staffed the team before the designand technology was sufficiently mature. InTHIEF, this led us to rush towards finishing thedesign, when we didn’t necessarily understandthe design and technology. With insufficientspecifications of both the code systems and missiondesigns, we ended up doing lots of contentthat was essentially wrong for the game we weremaking. Code was written and spaces were builtthat weren’t well-directed towards the goals ofthe project.To make matters worse, we failed to reassesscore scheduling assumptions carefully once theschedule began to slip. Captives of a series ofunrealistic schedules, we didn’t leave enoughtime for the sort of experimentation, dialogue,and prototyping a project like THIEF needs. Latein the winter of 1998, many of our schedulingmistakes had been corrected. Still, during theremainder of the project, the legacy of our earliermissteps required cutting missions thatrelied on technology we didn’t have, andreworking missions not focused on the coregameplay.Stepping Back fromthe ProjectTHIEF was constructed as a set of appropriatelyabstract reusable game components designed forcreating object-rich, data-driven games.Although increasing the cost of development,this approach allowed Looking Glass to leveragevarious technologies across disparate typesof games, from the first-person action game SYS-TEM SHOCK 2 to our combat flight-simulatorFLIGHT COMBAT. In our next-generation technology,some of the systems, such as the AI andthe Object System, will merely be revised, notrewritten.We intend to continue with this developmentphilosophy in our future games. The next timearound, our approach to constructing the enginewill differ. The engine will be scheduled, staffed,and budgeted as a project in its own right. Theeditor will be treated as more of a first-class citizenthan was the case in THIEF. Finally, a contentdevelopment team will not be geared upuntil the technology is sufficiently mature toallow for an informed game design process.Oh, and we’ll get our schedules right—really.

This Page Intentionally Left BlankLooking Glass’s THIEF: THE DARK PROJECT 182

183DreamWorks Interactive’sTRESPASSERby richard wyckoffOne seldom hears the true story of what happenedat the place where the world changed.How it began. What were the reasons? Whatwere the costs?—John Parker HammondThis quote from TRESPASSER’S opening movieserves just as well to open the real story of agame development team’s struggle to create abreakthrough dinosaur game as it does to openthe fictional story of Hammond’s struggle todevelop a biotechnological breakthrough andclone dinosaurs.An Ambitious ProjectThe parallels between the TRESPASSER projectand Hammond’s cloning project were numerous:ambitious beginnings, years of arduouslabor, and an eventual tragic ending. Hammond’sdiary, as related in the game itself,dwells on the past and never attempts to explainHammond’s future direction now that he hasfailed so grandly. This postmortem is intendedto be much more forward looking.TRESPASSER was begun by two former employeesof Looking Glass Technologies: SeamusBack-StoryIn the history of game development, TRESPASSERstands as an ambitious but failed experiment. The gameis set in the world of Jurassic Park and portrays a youngwoman named Anne exploring the abandoned islandlaboratory, learning its secrets and the past of its creator.The vision for TRESPASSER is a game that pushedthe envelope in several areas at once. Foremost is thephysics-based gameplay that would allow players moreflexibility in combat and puzzle-solving and give thegame-world a heightened realism. The team also createdoutdoor environments that broke shooter gameplayout of the rooms-and-corridors mold, as well asinnovations in graphics technology and storytelling. Inthe end, the project proved overambitious but makes fora fascinating case study.Blackley and Austin Grossman. By the time thegame was rolling, two more ex-Looking Glassemployees would join the team, and our commonbackground was instrumental in setting thedirection for the project.The ConceptThe pie-in-the-sky concept for TRESPASSER wasan outdoor engine with no levels, a completerigid-body physics simulation, and behaviorallysimulatedand physically modeled dinosaurs.

DreamWorks Interactive’s TRESPASSER 184The underlying design goal was to achieve arealistic feel through consistent looks andbehaviors. Having an abandoned island settingwas a useful way to exclude anything which didnot seem possible to simulate, such as flexiblesolids like cloth and rope, wheeled vehicles, andthe effects of burning, cutting, and digging.Game DataRelease date: December 1998Publisher: Electronic ArtsGenre: first person, outdoor physics-basedaction/adventureIntended platform: Windows 95/98/NTProject budget: Estimated $6–7 millionProject length: 32–36 monthsTeam size: 39 Including a full-time staff of 7engineers, 5 game designers, and 10 artists.Critical development hardware: 266MHz Pentium IIwith 128 0r 256MB RAMCritical development software: 3D Studio Max 1.2and 2.5, Photoshop 4.0, Microsoft Visual C++ 6.0,Visual SourceSafe 5.0The game would play from a first-person perspective,and you would experience the environmentthrough a virtual body to avoid the“floating gun” feeling prevalent in the WOLFEN-STEIN breed of first-person games. Combatwould be less important than in a shooter, anddinosaurs would be much more dangerous thanthe enemies in traditional first-person shooters.The point of the game would be exploration andpuzzle solving, and when combat happened, itwould more often involve frightening opponentsaway by inflicting pain than the mercilessslaughter of every moving creature.The original plan for TRESPASSER certainlyseemed like a good one. It was very ambitious,but the team made tradeoffs on implementationand execution time from the very beginning. Forinstance, the team wouldn’t attempt to do multipleor moving light sources or QUAKE-styleshadow generation in order to accommodatearbitrary numbers of moving objects and long,wide-open views. Unfortunately, there is a differencebetween having a plan and successfullyexecuting it, and the product that we eventuallyshipped was as disappointing to us as it was tothe great majority of game players and gamecritics.Some have dismissed TRESPASSER altogetherbecause it was such a visible failure. Respectedindustry columnists and editors use it as a reasonwhy physics is bad, or make it the butt oftheir jokes (“at least it wasn’t as bad as TRES-PASSER!”). However, from a project perspectivethere were a number of successes. Before we getinto the problems which ended up sinking theship, let’s look at these successes.What Went Right1. Use of licenseMaking a new story with someone else’s licensedproperty is often creatively stifling for designersand ultimately disappointing for fans of the originalwork. The Jurassic Park license could havebeen an especially limiting one, representingsome of director Spielberg’s and novelist Crichton’sweakest work. However, TRESPASSER’s

185SECTION III: MANAGING INNOVATION185Hammond diary actually contains lots of interestingtidbits about the early days of characterslike Henry Wu (the scientist from the beginningof the first movie) and Dennis Nedry (WayneKnight’s character who basically caused the firstdisaster), which made the game world a richerenvironment. The player can also check outlocations on the island which imply backstorywhich isn’t explicitly told, like Henry Wu’s housewith its 1980s executive bachelor stylings,Nedry’s office with its poster for the fictionalcomputer game series “Swords of Kandar,” andHammond’s lavish mansion.Concept art for TRESPASSER.The settings and the diary itself serve to revealmuch of Hammond’s motivation and personalreactions to the building of Jurassic Park, creatingmore of a character than exists in either thebooks or the movies. (Crichton killed Hammondoff in the first book, anyway.) The overallplot of our game is as simplistic as most others(the character must find a way to escape a deathtrap), but the details revealed about the JurassicPark world extend it in a way which is faithfulto the originals.Although it is quite likely that the next JurassicPark movie to be released will make TRESPASSERnon-canon, for now it stands as the only realextension of the series published. If there aresuch things as Jurassic Park fanatics and theywere able to look past the game play flaws, theyhopefully enjoyed our development of theworld.2. Art and musicOn an individual basis, the models created forTRESPASSER rank with the best-looking workdone for computer games. We limited the largesttexture size to 256×256 pixels, and at modelimport time textures were converted to 8-bitpaletted images. But artists worked with theirmodels using 24-bit art in 3D Studio Max,applying the textures using any mapping methodsthat Max supported. We had the standardlimits on visible polygons, so most models weremade with as few as possible: dinosaurs rangedfrom 300 to 500 polygons and trees from 50 to120, for example. But this still gave our artistsmore complexity than was standard at the time.Many of TRESPASSER’s artists had never workedon games or done 3D modeling before, andsome had never even used computers at all. Thiswas a fairly deliberate decision, in an attempt toachieve a much higher standard of art than wewere used to seeing on previous products. Thenumber and resolution of textures we were ableto support called for painting skills far beyondthe average game-trained artist.

DreamWorks Interactive’s TRESPASSER 186The music is one of TRESPASSER’s best accomplishments.Originally, we were slated to useJohn Williams’s score, but the cost proved to beexcessive. Fortunately, our sound effects company,SounDelux, put us in touch with one oftheir stable of composers who specialized in“imitation” music. With very little prompting,he recorded about 30 minutes of music for uswhich in some parts far exceeds the rather forgettablework Williams himself did for theJurassic Park movies.Some reviews still accused us of having spotty orinappropriate music, but this was more animplementation problem than a problem withthe music itself.The music was recorded as a couple dozen shortsections which were scattered through the worldon location-based triggers. Much like the voiceovers,more attention could have been paid totheir placement so that they only played atappropriate and regular intervals. Even moredesirable would have been a system with theability to play tension or combat music loopsand fade them in and out of the special-eventsongs to make it seem more like a continuousmusical score.3. Innovative systemsOur artists were able to paint textures with neartotaldisregard for common memory-conservationpractices, thanks to the texture caching systemwhich one of the last programmers to behired created fairly late in the project. Texturesfor our game were MIP-mapped by our helperapplication, GUIApp, as part of the process ofbuilding level data (curved bump maps were alsocreated at this time). A level could have a nearlyunlimited amount of textures, and once MIPmapswere created, all textures and their MIPmapswere saved into a single swap file. GUIAppautomatically organized the swap files into pagesbased on texture size, with the lowest couple ofMIP levels for all textures on a set of pageswhich were always committed.As the player moved through the level andobjects came into view, the appropriate pagesfrom the swap file were accessed. In any circumstanceswhere an appropriate texture hadn’tbeen loaded in yet, the always-committed MIPmapscould be used until the higher-resolutiontexture had been loaded. In theory, this couldresult in a frame or two where an object wastextured at a lower resolution than desired, butin practice it rarely happened, even on the mosttexture-intensive levels.Another major system for TRESPASSER was itsaudio system, which we described as “real timeFoley” because of its ability to generate collisionand scraping effects between differing soundmaterials in real time. Although the systemcould have used more sound material data, evenwith what it had it resulted in some wonderfullyimmersive sound effects which most othergames do not duplicate—things like scraping aboard down a concrete surface or hitting an oilbarrel with a metal bat sound almost perfect.The system doesn’t just play two stock effectsbut actually chooses from several samples andsets volumes based on the strength of the underlyingphysics collision, with very natural-soundingresults.

187SECTION III: MANAGING INNOVATION187Finally, our image caching system, which renderedgroups of distant objects into single 2Dbitmaps to speed rendering, while responsiblefor the most disturbing visual anomalies in thegame, was also by its own right an amazingpiece of work. Image caching allowed sceneswith tens of thousands of polygons to be renderedin near-real time, and it is the first technologywhich has allowed outdoor scenes tohave a reasonable fraction of the complexity ofthe real outdoors.4. Outdoor level designWhen we created our terrain geometry, we weredeliberately trying to avoid the “marbles in rubber”look of a lot of bad fractally-generated outdoors.To this end, we decided that we neededto base our island on real-world terrain ratherthan build it from scratch. Luckily, we had areal-world model to go from: Costa Rica’sCocos Island, the same island which Crichtonused as his inspiration for Site B. Unfortunately,no relief maps of sufficient detail existed for theisland, so we ended up having our lead artistsculpt a large model of the entire island, had itlaser scanned, and did all our final work on it in3D Studio Max.Modeling was only the first step to creating alevel. After most of the terrain was established,it took significant time to populate the levelswith objects. There were 10–15,000 trees,shrubs, and rocks in most levels, and a fewthousand man-made objects as well. Everyobject could be placed individually, but for timesavingreasons we generally used groups ofobjects for areas off the gamepath and onlyspent a lot of time hand-placing items in placeswe knew the player would go. The rolling terrainand a random-delete tool we often ran foroptimization generally kept the repetition fromseeming obvious.In the end, although our levels didn’t quite fulfillour personal expectations, they usually lookmore like real environments than previousgames. Starting from a real map seemed to bethe most useful tactic for this, and looking for areal-world starting point for vegetation placementis the next obvious step for outdoorgames.5. Realistic physics in a firstpersonperspectiveThe first discovery we made as our physics simulationwas slowly implemented was that it wasan engrossing toy. When we finally got supportfor compound object physics (so that a benchcould consist of a top and two legs instead of asingle block, for instance), it was possible tospend an hour just dropping the bench ontothings to see how it would catch on edges andflip and slide around. Toys do not make games,however, and trying to establish game play thatwould work with our simulation was our majorchallenge.Due to the vagaries of our particular physicssimulation and interface, we eventually arrivedon game play that primarily involved knockingthings over rather than stacking things up.Knocking over will probably be the first applicationof realistic physics to see widespread use, asit will work even with a less-than perfect physics

DreamWorks Interactive’s TRESPASSER 188What Went WrongIt might seem as though TRESPASSER deservesmore entries in its “what went wrong” sectionthan the usual project postmortem. However,TRESPASSER’s failings are actually few in number.Unfortunately, the failings that we did havewere serious enough to more than outweigh oursuccesses.Level design in Max was tolerable, notenjoyable, for the TRESPASSER team.model (such as TRESPASSER’s). It is also a behaviorwhich easily shows off the differencebetween realistic physics and what we usuallyreferred to as “fake” physics—compare pushinga box off a ledge or hill in any game which actuallylets you move boxes to the same action inTRESPASSER.Since our game play was supposed to revolvearound the physics, however, we needed toapply that knocking-over behavior in slightlymore sophisticated ways than just using it as eyecandy. The best uses that we found in the smallamount of time we had involved knockingstacks of boxes down to fill holes, or unbalancingsomething resting on a high ledge in order toget it or use it as a step. It also quickly becameapparent that building even a seemingly simpleknocking-down puzzle required a much morehighly refined sense of physical laws than manyof us had.1. Software-oriented rendererTRESPASSER was begun before the original Voodoostarted the wave of 3D hardware popularity.The TRESPASSER engineers set about tocreate an engine in the old-school manner: theypicked some previously-unseen rendering technologiesand implemented them, ignoring anyissues of compatibility with hardware cards.Our engine’s two most incompatible featureswere its bump mapping (which used a true geometricalalgorithm that could take surface curvatureinto account) and its image caching.Image caching was intended to allow real-timerendering of huge numbers of meshes, but it wasalso the system almost solely responsible for thegraphical anomalies of popping, snapping treesin the game. The other primary visual artifact ofthe game was the frequent sorting errors, butthis was a result of poorly-constructed levelswhich continually handed our depth-sort algorithmmore polygons than its limit, and not adirect result of image caching itself.The image cache system worked by renderingdistant objects into 2D bitmaps on the fly, and

189SECTION III: MANAGING INNOVATION189then updating them when the angle or distancechanged enough so that the 2D representationwas no longer sufficiently accurate. This maysound familiar to those who rememberMicrosoft’s Talisman architecture, and therewas a hope at one time that our game would bea “killer app” for Talisman accelerators, butresistance from key figures in the industry and3dfx’s sudden popularity pretty much put anend to Talisman.TRESPASSER ended up slipping by more than ayear, as did many games of its time. Our hardwareprogrammer put in a valiant effort in thelast half year of the project, and managed to getmuch more use out of 3D hardware than we initiallythought possible. We ended up with afairly unique mixed-mode renderer which drewany bump-mapped objects in software and therest of the scene with hardware. Unfortunately,the large number of bump-mapped objectspresent in our game, such as all the dinosaursand nearly every crate, meant that the fill rateadvantages of accelerators were often negated.In addition to being a costly software-only renderingmethod, our bump mapping was neververy evident: we could have used multiple, movinglight sources and had the art staff make betteruse of bump maps in their objects. Many ofthe bump maps were created by simply convertingthe original texture to grayscale, an artist’shack that works for rendered images and animationsbut not in real-time 3D. Image cachingwas an even bigger problem than bump mapping,because although it was the key technologythat we were using to try to improve scenecomplexity, the game’s visual quality was alsothe source of most people’s complaints.It seems clear in retrospect that we should havemade a tradeoff somewhere along the line andeither dropped the physics technology andphysics game play in favor of the renderingtechnology, or more likely dropped the renderingtechnology and the ability to do complexscenes in favor of the physics technology.2. Game design problemsThe biggest indication that TRESPASSER hadgame design problems was the fact that itnever had a proper design specification. For along time, the only documents which describedthe game play were a prose-style walkthroughof what the main character would do as shewent through the game, and a short designproposal listing the keys which would be usedand some rough ideas of what game play mightactually be.Our experiences on TRESPASSER made it clearthat it is worse not to have a design specificationat all than to have one which becomes out ofdate and is frequently rewritten. TRESPASSERstarted and finished weak in the game design,and this affected every other part of the project.When it became clear that the technology wasnot going to exist to support the initial highconceptdesign, it would have been best tothrow out all our existing notions and reinventthe game.Unfortunately, our license made it all but impossibleto throw out the original TRESPASSER con-

DreamWorks Interactive’s TRESPASSER 190cepts. The only major deviations from theoriginal idea were the change from constructive,stacking-based physics puzzles to destructive,knocking-over puzzles, and an attempt to makecombat more prevalent in order to shore up theweakness of the destructive physics puzzles. Sinceno part of the TRESPASSER code was written to begood at doing first-person shooter game play, thisattempt to make shooting a more important featureonly ended up flaunting some of the weakerpoints in the game, like the lack of an inventorysystem and the slow frame rate.3. Tools problemsTRESPASSER was built entirely in 3D StudioMax. There was no level editor, only the generically-titledGUIApp, which was the game with adebugging shell—not really a tool at all. Ourlevel creation procedure consisted of arranging20–25,000 meshes in Max,using dummy meshes torepresent game play objectslike triggers, and typingtrigger code into theseobjects’ “object properties”buffer.There were two unexpectedand incredibly severe drawbacksthat we discoveredonly after it was far too late to change ourmethod of building the game world. The firstproblem was that Max is basically unfit to workwith more than about 5,000 objects at a time.TRESPASSER levels averaged 40MB in size, andcould take a couple minutes to load on the systemsour designers used (Pentium II-266 with256MB RAM). When all objects in a level werevisible, it could take from 30 to 60 seconds torespond after clicking on an object to select it,making fast work difficult (to say the least).The second problem with the Max method wasour use of the object properties text buffer. Thebuffer seems to be one of those features whichno one ever used before, because we discoveredthat if more than 512 characters were typed intoan object’s properties buffer, Max could becomeunstable. If Max didn’t crash outright and a filewas saved with one of these bad objects, itwould become unloadable. TRESPASSER’s technicalartist wrote many design tools in MaxScriptand also coded warning scripts to guard againstproblems such as properties buffer overflows,but these solutions only made designing in Maxtolerable—not enjoyable.There was an additionalwrinkle to the process ofusing Max to create levels,and this was the exportstep. A Max plug-in converteddata into the gameformat, but our particularexporter caused a lot ofproblems. It was developedby a programmer whoworked from home, an hour away from theoffice, and used a separate code base withunique classes and a different version of thecompiler. This was also his first project in 3D,and it became the second-most delayed part ofthe project after physics. Until the last year of

191SECTION III: MANAGING INNOVATION191the game, there were significant bugs in theexporter which required time consuming workarounds.Important functionality, such as the ability toexport object properties, also was not delivereduntil very late in development, which preventeddesigners from implementing game play. In theend, the exporter was assigned to another programmerand rapidly brought up to usability,but it had already delayed level building significantly.4. AI problemsThe largest problem with theAI system was that itsprogress was blocked by alack of dinosaurs with whichto test it. The first time adinosaur made the transitionfrom a separate test applicationinto the game was inearly 1998, with significantmissing functionality whichprevented the completion ofvisually important AI behaviors,like howling and glaring.The first quadrupedwent in around the earlysummer of 1998, about fourmonths from the thenintendedship date (as itturned out we slipped byabout another month). Thedinosaur AI was a state-based system, based onthe creatures’ emotions.It became apparent once dinosaurs were workingwell enough to put into levels that the differencesbetween the activity states were notdiscrete enough. Dinosaurs were governed by aset of emotions which theoretically wouldprompt them to pick appropriate responses atany time. However, in practice they would endup oscillating rapidly between many activities,sometimes even literally standing still andtwitching as they tried to decide what to do.Making a usable dinosaur required disabling allbut one or two of their activities. This allowedaggressive dinosaurs to really be aggressive, butit also meant that most dinosaurs were as singlemindedas the traditional video game monsterswe were trying to one-up.The AI system suffered fromthe lack of a clear gamedesign. There are two scenesin the Jurassic Park movieswhich demonstrate quintessentialdinosaur game play:the scene in Jurassic Parkwhere the kids hide from raptorsin a kitchen, and thescene in Lost World whereJeff Goldblum deals with severalcautious raptors in theruins of the town. Both ofthese scenes rely on dinosaurswhich can be fooled byducking behind objects andwhich can home in on or bedistracted by localized noises.Neither of these two fundamental abilities isactually present in the TRESPASSER dinosaur AI.

DreamWorks Interactive’s TRESPASSER 192Instead, the dinosaurs have a simpler and moreindustry-standard detection radius which doublesas sight and hearing and is not blocked byobjects in any way. Without a design specificationcalling for these kind of behaviors, though,the AI development went in directions whichended up being largely unsuitable for game play.This problem wasn’t even discovered until a fewmonths before we shipped, when there was onlytime to work around it rather than completelyrework it.5. Physics problemsThe box model was TRESPASSER’s most significantphysics innovation: it was intended to be acomplete simulation of any arbitrarily-sized boxinteracting with a number of other boxes. Theapproach used in TRESPASSER was what isknown as the “penalty force” method. Inincredibly simple terms, when boxes collide,they are allowed to intersect with each other(mathematically), and then they push each otherapart until they are no longer intersecting.The penalty force model is generally believed tobe an unworkable one by the few other peoplein the industry attempting real-time solids models,but our physics programmer believed hecould make it work. There were several notableflaws with TRESPASSER’s solids model asshipped: it ended up only working well whenused with roughly cube-shaped boxes withdimensions between 0.5 and 1 meter on a side,it did not model friction well, it was extremelyslow, and it was not free of interpenetrationeven within the size constraints.We were aware that physics would be slow, andthat ten boxes at once would represent the practicalupper limit, but we had not expected thatso much of that physics overhead would beeaten up by the dinosaur body physics, whichused five boxes in the worst cases: head, body,tail, and two feet. Although the dinosaur physicsboxes executed faster because they did notinteract with each other, it turned out that incommon cases (like a scene displaying two raptorsand the player holding a gun), the physicsbudget was completely consumed and therewere no were no processor cycles left to handleknocking over a stack of boxes.Physics speed was an issue, but other problemswere more severe. The game design dependedon boxes of sizes other than small cubes, and weended up including many objects outside thatsafe range. Unfortunately, all objects outside thesafe range, even large cubes, were more prone toreveal the most egregious problem with thephysics system: interpenetration. At best, theseinterpenetration bugs completely blow the consistencyof simulation we tried to set up, and atworst they make the game unplayable. If it wasnot clear before shipping TRESPASSER, it is clearnow: no amount of interpenetration is acceptable,and preventing it absolutely should be thenumber one concern of any physics coder. TRES-PASSER’s dinosaurs and the arm itself wereinverse-kinematic (IK) systems controlled byphysical models. Originally, the dinosaurs weresupposed to be full physically-modeled bipedswhose physics actually knew how to use legs tostand, walk, run, and jump. They ended up withmore standard game movement physics and an

193SECTION III: MANAGING INNOVATION193IK animation system very similar to LookingGlass’s TERRA NOVA.Just like in TERRA NOVA, the dinosaur legs frequentlystretched, bent, and popped as the IKsystem struggled to handle the physically impossiblemovements that the simplified physics generated.This movement problem was a case oflacking realistic boundary conditions. The jointsof the arm never had realistic limitations put ontheir rotation or even limitations on the distancesbetween joints. A system written by a differentprogrammer sat on top of the underlyingarm system and continually tried to make sure ithad not moved into an impossible position, butas a separate system it could only be partiallysuccessful at best.The arm as shipped would often go almost outof control for a few frames, stretching or spinningin impossible ways. During this time thefragile feeling of connection between the playerand their character would be shattered. The armsuffered not only from its unbounded model butalso from bad design choices. Its creatorintended it to be wholly context-insensitive. Thefact that guns, unlike other objects, get heldfairly steadily and away from the body was onlya result of some key members of the test staffadding their voices to the cries which had beencoming from within the team to fix shooting sothat it was easy to hit a desired target. It shouldhave been obvious from the mere fact that a 2Dinterface was being used to move in 3D spacethat an even larger amount of context sensitivitywas needed.If a truly successful virtual arm is ever to beimplemented, simple mouse movements willhave to be translated into complicated armmovements based on what is in or near thehand, or it will be as impossible to use as TRES-PASSER’s arm. That there was a conscious decisionto avoid context sensitivity in our project isindicative of the larger problems with physics inour project. The physics code was largely writtenin a vacuum and tested in separate applicationsand non-representational levels, and notenough attempts were made to analyze it from aplayer’s perspective and design it to supportgame play in every way.Lessons LearnedHow did TRESPASSER end up shipping with thenumber of problems that it had? TRESPASSERwas a project with management problems at alllevels. It suffered from being an innovative,technologically ambitious project produced by ateam with little previous management experienceat a company which had not yet gainedinstitutional experience from publishing significant,less-ambitious projects.That TRESPASSER shipped at all is a testament tothe strength of the individual members of itsteam. In looking back at my own experience, Ifind that I learned a lot about game development,and I’m already putting that knowledgeto work. Although the game does not fulfill themany high hopes I had for it (or even my baseexpectations), I am happy with the work I putinto it. I also hope that every other person whocontributed to the massive effort is equallyproud of their work, and that sometime in the

future we all have a chance to make a majorproject that succeeds where TRESPASSER failed.DreamWorks Interactive’s TRESPASSER 194

195Ion Storm’sDEUS EXby warren spectorFictionally, DEUS EX is set in a near-future versionof the real world (as it exists if conspiracybuffs are right). For some real shorthand, call it“James Bond meets The X-Files.” Conceptually,DEUS EX is a genre-busting game (which reallyendeared us to the marketing guys)—partimmersive simulation, part role-playing game,part first-person shooter, part adventure game.It’s an immersive simulation game in that youare made to feel you’re actually in the gameworld with as little as possible getting in theway of the experience of “being there.” Ideally,nothing reminds you that you’re just playing agame—not interface, not your character’s backstoryor capabilities, not game systems, nothing.It’s all about how you interact with a relativelycomplex environment in ways that you findinteresting (rather than in ways the developersthink are interesting), and in ways that moveyou closer to accomplishing your goals (not thedevelopers’ goals).It’s also a role-playing game in that you play arole and make character development choicesthat ensure that you end up with a unique alterego. You make your way through a variety ofminute-to-minute gameplay experiences (whichBack-StoryIf the mid-90s were the era of stripped-down, no-frillsshooters, DEUS EX, released in 2000, is the logical backlash.It features both high-speed action and familiar roleplayingelements—plot twists, conversations, inventory,and a large cast of characters. As superagent J. C. Denton,players navigate a complex story of intrigue andconspiracy, traveling the world and changing sides atleast once. DEUS EX was designed to support a range ofplay styles, from full-on assault to stealth, and to allowplayers to solve problems creatively, using a wide arrayof gadgets and abilities.add up to a story) in a manner that grows naturallyout of the unique aspects of your character.Every game system is designed to differentiateone player-character from another, and to allowplayers to make decisions that reflect their ownbiases and express character differences in obviousways in the game world.It’s a first-person shooter because the actionunfolds in real time, seen through the virtualeyes of your alter ego in the game world. Tosome extent, your reflexes and skill determineyour success in combat. However, unlike thetypical FPS, DEUS EX doesn’t force you to shootevery virtual thing that moves. Also unlike theaverage FPS, in which gameplay is limited topulling a virtual trigger, finding blue keys to

Ion Storm’s DEUS EX 196open blue doors, and jumping to reach seeminglyinaccessible locations, DEUS EX offersplayers a wide range of gameplay options.And finally, DEUS EX is like adventure games inthat it’s story-driven, linear in narrative structure,and involves character interaction and itemGame DataRelease date: June 23, 2000Publisher: Eidos InteractiveGenre: first-person action/role-playing game; sciencefictionIntended platforms: Windows 95/98/NT/2000 plusthird-party Macintosh and Linux portsNumber of full-time developers: Approx. 20: 1 ofme, 3 programmers, 6 designers, 7 artists, 1 writer, 1associate producer, 1 tech.Number of contractors: Approx. 6: 2 writers, 4testers.Length of development: 6 months of preproductionand 28 months of production.Critical development hardware: Ranged from dualPentium Pro 200s with 8GB hard drives, to Athlon800s with 9GB fast SCSI, and everything in between.More than 100 video cards were cycled throughduring development.Critical development software: Visual Studio,Lightwave, Lotus Notes.Notable technologies: Unreal engine and associatedtools such as UnrealEd and ConEdit (our proprietaryconversation editor).accumulation to advance the plot. However,unlike most adventure games (in which youspend the bulk of your time solving clever puzzlesin a search for the next static, but verypretty, screen), DEUS EX asks players to determinehow they will solve game problems andforces them to deal with the consequences oftheir choices.DEUS EX combines elements of all of thesegenres. But more important than any genre classification,the game was conceived with the ideathat we’d accept players as our collaborators,that we’d put power back in their hands, askthem to make choices, and let them deal withthe consequences. It was designed from the startas a game about player expression, not abouthow clever we are as designers, programmers,artists, or storytellers. Which leads naturally toa discussion of having clear goals—the firstthing I think we did right.What Went Right1. A clear high-level visionIt’s pretty self-evident that you can’t achievegoals if you’re not clear about what they are. Weknew with a high degree of confidence whatkind of game we wanted to make. This was possiblefor two reasons. First, DEUS EX is a naturaloutgrowth of work done by and in some caseswith the late, lamented Looking Glass Technologies.We were inspired as well by games madeat Valve, Origin, and a host of other places.Many of the things we wanted to do were areaction to things they (or we) didn’t do, didn’tdo well, or couldn’t do at all in earlier games.We weren’t building from scratch, but rather

197SECTION III: MANAGING INNOVATION197building on a foundation already laid forus. Second, and on a personal level, DEUSEX is a game I’ve been thinking aboutsince right around the timeUNDERWORLD 2 shipped. I’ve tried to get agame like this started several times (asTROUBLESHOOTER at Origin; in somerespects, as JUNCTION POINT, for LookingGlass). Those games didn’t happen for avariety of reasons, but I never stoppedthinking about them and, despite the failureof those games to reach production,they laid much of the conceptual groundworkfor DEUS EX. The lesson here is thatif there’s a game you really want to make,don’t give up on it. Someone will be foolishenough to give you the money eventually.Several years passed. I left Origin to go work forLooking Glass, but TROUBLESHOOTER stayed onmy mind. In the fall of 1997, before Ion Stormentered the DEUS EX picture, I drafted a manifesto—adescription of an ideal game—and alsoa set of “rules of roleplaying.” Much of thatmaterial ended up in an article published inGame Developer (“Remodeling RPGs for theNew Millennium,” February 1999), which isstill available online on Gamasutra.com.The details of DEUS EX—plot, character lists,game system designs and so on—changed radicallyin the years following the original TROU-BLESHOOTER proposal and writing my manifestoand rules list. Conceptually, however, the gamestill plays much the way I hoped TROUBLE-SHOOTER would play, and it definitely fulfillsmost of the ideals I had outlined in that GameDeveloper article.Real-world spaces, such as the Statue of Liberty in NewYork City, can be compelling game spaces, but offerunique challenges to game developers.Quite simply, with a solid concept of what wewanted to achieve in mind, we were able toassess every design decision and every game systemspecification in light of our ultimate goals.2. We didn’t skimp onpreproductionWe spent the first six months of DEUS EX (beforewe licensed a game engine), with a team ofabout six, just thinking about how we couldturn our high-level goals into a game. We hammeredon the setting and decided to move thegame into the near future to buy ourselves someroom to play around—the real world, as wequickly discovered, was very limiting.Ultimately, we settled on a conspiracy-orientedbackground. We did a vast amount of researchinto “real” conspiracies—the Kennedy assassination,Area 51, the CIA pushing crack in East

Ion Storm’s DEUS EX 198L.A., Dwight Eisenhower’s UFO connection,and of course Freemasons tunneling below theDenver airport and building abducted-baby cafeteriasfor alien invaders at George Bush’s direction.Only a fraction of this stuff ended up in thegame, but it gave us a peek into the minds ofconspiracy buffs that was both scary and useful.We worked on back-story stuff so we’d knowwhat was going on in the world, even in placesthe player never got to visit. Some of this stuffmay come to the forefront in DEUS EX 2 but, forDEUS EX, it was just a way of making sure weknew enough to include the kinds of smalldetails that make a fictional world convincing.We also created a cast of more than 200 characters,many of whom didn’t yet have specificroles in the game. Ultimately, this list proved tobe both a help and a hindrance to designers asthey fleshed out the missions. Characters sometimessuggested missions or subquests, but justas often ended up being filler we were reluctantto cut, even though their missions or story purposeschanged during our storyline focusingpasses.We hammered on game systems. We conceived askill system that didn’t depend on die-rolls ortracking skills at a fine level of granularity. Wecame up with a system of “special powers”(nanotech augmentations) that differentiated theplayer character from ordinary humans. Wedesigned a conversation system with some cinematicelements and some elements borrowedfrom console RPGs. We mocked up 2D inventory,skill, and augmentation upgrade screens,map screens, even a text editor so players couldtake notes. We conceived several player rewardsystems, including skill point awards, augmentationupgrades, weapon availability timelinesand tool/object availability timelines.By March 1998, we had 300 pages of documentationand thought we knew everything we’dneeded to know to make a game. Were we everwrong. In the time between March 1998 andour Alpha 1 deadline of April 1999, that 300-page document mushroomed into more than500 pages, much of it radically different fromwhat we thought of and wrote initially.Clear goals and a detailed script are all well andgood, but goals change, thinking changes, andgame designs have to change, too. Which leadsnicely into the next thing that went right.3. Recognizing that gamedesign is an organic processWhy did our thinking and goals change? Therewere lots of reasons. First, new people joinedthe team, with new ideas. Our staff grew fromsix people to roughly 20. I hired a bunch of people,of course, but we had the added excitementof integrating an entire art team assigned to us,in Austin, by an art director a couple of hundredmiles away in Ion Storm’s Dallas office.As we brought on new people, we found ourselvesto be a team of hardcore ULTIMA geeks,hardcore shooter fans, hardcore immersive simfans, strategy game nuts, and console gamers.Some of our new team members proved to be“maximalists”—wanting to do everything, special-caselots of stuff, and stick as close to realityas possible. Other team members proved to beminimalists—wanting to include fewer gameelements but implementing them exceptionally

199SECTION III: MANAGING INNOVATION199well, in ways that could be universally appliedrather than special-cased. Also, we made a pointof letting select friends and colleagues play thegame at various points along the way. We wereinterested in well-reasoned opinions from folkswho understood the kind of game we were makingintimately and who had a handle on thedevelopment process that was at least as good asour own.With all the new folks contributingand all the feedbackfrom our chosencritics, well, let’s just say wehad some interesting debatesat Ion Storm, Austin. Out ofthose debates new ideasarose, and the game changedas a result. Technologyforced design changes, too.It took time to becomefamiliar with the Unrealengine. Months of experimentationwere necessary toreveal how best to do thingsin Unreal and what thingsnot to do at all.A detailed weapon sketch.A third area that influenced the changing natureof the game’s design was when the game systemsdidn’t work as we intended them to. We quicklyfound that descriptions of game systems are nosubstitute for prototypes and actual implementation.We prototyped every game system as itwas documented relatively early on. We alsobuilt some test missions, not quite early-onenough, but still early. These test systems andmissions revealed gaping holes in our thinking,or things that we thought would be true andwhich turned out not to be true at all.For instance, once implemented, our augmentationand skill systems proved dry and ratherdull, despite looking really good on paper. Ithought the tension of standing outside a lockeddoor, not knowing if a guard was going to showup while you picked the lock, would providesufficient excitement. I thought knowing youcould leap across a chasmbecause you had the Jumpaugmentation at Tech Level3, and opening up new pathsthrough maps that wereinaccessible to players withoutthat augmentation,would be cool enough tokeep players interested.We took this criticism, andwith it in mind, leaddesigner Harvey Smithrevised the skill and augmentationsystems prettythoroughly, increasing thetension level, providing newrewards, and allowing players to think andmake informed decisions. None of this wouldhave happened without the prototype missionsand some harsh (but fair) criticism they elicited.Another big reason for changes from our originaldesign document was our realization thatthe idea of a real-world RPG, with real-worldlocations and real-world weapons, was cooler insome ways than it turned out to be on thescreen. When we started building places like the

Ion Storm’s DEUS EX 200Statue of Liberty, a few square blocks of NewYork City, the White House, Parisian streets,and so on, we found that most of the real worldis not all that interesting as a gaming environment.We also found it difficult to live up topeople’s expectations of places they’ve actuallybeen.We created an object-rich environment, only tohear things like, “Hey, why can’t I use that telephoneto call anyone I want whenever I want?”and had to cut some objects whose real-worldfunctionality we couldn’t capture in the game.Finally, we had to ask ourselves whether humannon-player characters (NPCs) are interestingenough to carry an entire game. We were abouta year into development when designers and artistsbalked at a game entirely about humanbeings. Movies don’t need non-humans to becool but the same cannot be said, apparently,for games. People want monsters and bad guys.The feeling was so pervasive that it changed mythinking completely. The original design speccalled for a couple of robots, but the teamdemanded that they be made a more importantpart of the landscape, and we introduced geneticallymanipulated animals and some alien-lookingcreatures. (Luckily, our game fictionsupported all of this.) The game benefited, butthis was a radical change from the original plan.4. Creating “proto-missions”It’s a truism that milestones should be testable,showing visible progress, whenever possible,and we lived up to that standard. We couldalways pull a version together, always show offfor press or our publisher. Most importantly, wealways knew where we were (even if thatknowledge was sometimes painful). But theproto-mission idea is something beyond simplyvisible, testable milestones. The proto-mission iscritical in the process of design, as well as inmilestone and schedule setting.One example of where our proto-mission ideawas successful was in May 1998, when ourmilestone was to have prototypes of criticalgame systems in place and two test maps running,in this case the White House and part ofHong Kong. The maps were crude, the conversationsraw, and the game systems hacked, butwe could see—and show—the potential.To our advantage, we resisted the temptation todo just the stuff we knew would work and thestuff that would look the prettiest, and prototypednew, risky stuff first. Conversation, interface,inventory, skills, and augmentations wereall at least hacked in so we could see them inaction. The White House was likely to proveour toughest map challenge, so we built it first.(Almost unbelievably, I missed what may havebeen the riskiest, most critical game system in allof our early prototyping, NPC AI. I should haveinsisted on early prototyping of our AI but Ididn’t.)With the proto-mission system, we could immediatelysee some of the limitations of our technology.For example, we had some serious speedproblems with areas as big as the White Houseand Hong Kong. After this, we knew we’d haveto break maps up into small pieces. And we

201SECTION III: MANAGING INNOVATION201began to suspect, though I couldn’t quiteembrace the idea, that we’d eventually have tocut maps and missions from the game—mostnotably the White House.In May 1999, we had a milestone calling for thedelivery of the first two missions of the game,playable start to finish. All of our game systemswere implemented (not hacked) as originallydocumented. You could start a game, create acharacter, upgrade skills, solve problems in avariety of ways, manipulateinventory, acquire augmentations,talk to NPCs, getand accomplish goals, saveyour game, and so on. Tothe team’s chagrin, I had atendency to call this the“Wow, these missions suck”milestone.Our earlier demos hadshown the potential of whatwe were doing. This demoshowed us how far we hadto go before we reached thatpotential. This milestonealso benefited us in that itshowed us all the steps necessaryto create a mission,and revealed the elementsthat really made the game work. That knowledgeallowed us to go through our 500-pagedesign document and cut everything that wasextraneous, winnowing it down to a svelte 270pages. Less game? Not at all. What was left wasthe best 270 pages—the stuff that worked.“Less is more” was something Harvey Smithhad said over and over, from the day he signedon as lead designer. While some team membersresisted this notion outright, I took a middleroad, which just frustrated everyone. In the end,we cut a lot, left a lot, and made a game thateveryone on the team was happy with (I think).This milestone made it clear that the time hadcome to make cuts, while giving us enoughknowledge to cut intelligently. If we had waiteduntil beta to make cuts, with just a few monthsto go before our ship date(as many developers do), itwould have been a disaster.5. LicensingtechnologyWe went into DEUS EX hopingthat licensing an enginewould allow us to focus oncontent generation andgameplay. For the most part,that proved to be the case.The UNREAL TOURNAMENTcode we ended up goingwith provided a solid foundationupon which we wereThe DEUS EX player’s alter ego, J.C. able to build relatively easily.Dropping in a conversa-Denton, strikes a heroic pose.tion system, skill andaugmentation systems, our inventory and other2D interface screens, major AI changes, and soon could have been far more difficult. We wereable to make what I hope is a state-of-the-artRPG-action-adventure-sim with only threeslightly overworked programmers, which

Ion Storm’s DEUS EX 202allowed us to carry larger design and art staffsthan usual.However, to my surprise, licensing technologydidn’t save us all the time I’d hoped it would.You’d think cutting a year or more of enginecreationoff a schedule would result in an earlierrelease date. On DEUS EX, that didn’t prove tobe the case. Time that would have been lost creatingtools was lost instead to learning the limitationsand capabilities of “foreign” technology.The biggest downside to licensing was that wewere just never going to understand the code aswell as we would have if we’d created it ourselves.That led to two distinct kinds of problems.First, there were areas where we ended uptreating the engine as a black box. I think it’spretty well documented by now that we shippedDEUS EX with some Direct3D performanceissues. Once players started reporting troubles,we were kind of in a lurch—we couldn’t verywell go in there and mess with the Unrealengine—we just didn’t understand it wellenough to do that safely. We had built aroundthe edges of Unreal without ever getting toodeeply into the nuts and bolts of it.Second, because we didn’t know the code insideout, and because we’d shelled out a fair amountof money for it, we tended to be conservative inour approach to modifying it. There were timeswhen we should have ripped out certain parts ofthe UNREAL TOURNAMENT code and startedfrom scratch (AI, pathfinding, and sound propagation,for example). Instead, we built on theexisting systems, on a base that was designed foran entirely different kind of game from what wewere making. It’s not that UNREAL had bad AIor pathfinding or sound propagation, but thosesystems were designed for a straightforwardshooter, which was not what we were making.I guess the fact that we’ll be licensing technologyfor our next round of projects, DEUS EX 2 andTHIEF 3, says the price was right. But it remainsan interesting dilemma, and we will be able toapproach our next licensed engine with the wisdomgleaned from using UNREAL for thisproject.What Went Wrong1. Our original team structuredidn’t workYou’d think after 17 years of making games andbuilding teams to make games, I’d have a clueabout team structures that work and those thatdon’t. Ha! When I started pulling the DEUS EXteam together I had a core of six guys fromLooking Glass’s Austin office. Having tappedChris Norden to be lead programmer, I neededto find a lead designer and a lead artist. As Istarted casting about for the right person for thedesign job, something really good, but ultimatelyreally bad, happened—two guys camealong with enough experience to expect a leadershipposition.Instead of doing the sensible thing and pickingone of them, even if that meant the other chosenot to sign on, I got cute. I created two designteams, each with its own lead. I put together

203SECTION III: MANAGING INNOVATION203two groups of people with differing philosophies—atraditional RPG group and an immersivesim group. We were making a gamedesigned to bust through genre boundaries, andI thought a little competition and argumentationwould lead to an interesting synthesis of ideas. Ithought I could manage the tension between thegroups and that the groups and the game wouldbe stronger for it.My plan didn’t work. Thedesign team was fragmentedfrom the start. We had toname one of the groups“Design Team 1” and theother “Design Team A.”(Neither group would settlefor “2” or “B.”) It becameapparent—later than itshould have—that I wasgoing to have to merge thetwo groups and have a singlelead designer. When I finallymade that change I disappointedsome folks, but thegame was the better for it, and that’s what’simportant in the end.There were also challenges on the art side. DEUSEX suffered dramatically because for over ayear, the artists “on the team” worked not forme or for the project, but for an art director inIon Storm’s Dallas office. Don’t misunderstand—theart director was a talented guy. Buttalent doesn’t make up for a matrix managementstructure (wherein resources in a departmentor pool are “lent out” to a project untilthey’re not needed anymore) ill-suited to theA genetically manipulated creaturecalled a “Greazel” was added toDEUS EX in response to the team’sfeeling that human interactionmight not be enough to carry theentire game.game business, and it doesn’t make up for beingoff-site.During this time, the art department drifted abit. It was unclear whether the artists workedfor me or for the art director in Dallas. Icouldn’t hire, fire, give raises to, promote, ordemote anyone on the art team. We wereassigned some artists whoweren’t interested in thekind of game we were making.Matrix managementmay work in some circumstances,at some companies,in some businesses. But I’venever seen it work in gaming,and I’ve seen itattempted at three differentcompanies. It especiallydoesn’t work when one ofthe department managersisn’t on-site.I argued for a year thatmatrix management hadfailed at Origin and at Looking Glass. I had nodoubt it would eventually fail at Ion. EventuallyI got my way, and things got much better on theart front once the artists were officially part ofthe DEUS EX team. Still, I can only imagine howDEUS EX might have looked if we’d been one bighappy team, including the artists, from the start.If the experience of DEUS EX taught me onething, it’s the importance of team dynamics. Youhave to build a team of people who want to bemaking the game you’re making. You have todeal with personnel issues sooner rather than

Ion Storm’s DEUS EX 204later. And there has to be a clear chain of command.Many decisions can be made by consensus,but there can only be one boss for a project,there can only be one boss for each department,and department heads have to answer to theperson heading up the project.2. Clear goals are great…whenthey’re realisticWe started out thinking very big. That in itselfisn’t bad—it’s necessary to advance the state ofthe art—but we were unrealistic, blinded bypromises of complete creative freedom, and byassurances that we would be left alone to makethe game of our dreams. A really big budget, noexternal time constraints, and a marketing budgetbigger than any of us had ever had beforemade us soft.Let me give you some specific examples of waysin which we outreached ourselves in the originaldesign of DEUS EX (before we made significantcuts). For one, there’s no way, in a first-personRPG, to stage a raid on a POW camp to free2,000 captives. Also, there’s no way to re-createall of downtown Austin, Texas, with any degreeof accuracy. Third, blinded by the power ofUnrealScript, many of our original mission conceptsdepended upon special-case scripting andlots of it. We discovered the need for generalsolutions rather than special-case solutions laterin the project than we should have (this despitemuch harping on the subject by some teammembers).Find your focus early and maintain that focusthroughout. General solutions are better thanEverything in DEUS EX is about choices—whoyou are in the world, how do you interact in theworld, what are you carrying, and so on. In thiscase, the player has clearly decided to gothrough the game as a heavy weaponsspecialist, despite the fact that this will leavelittle room in inventory for anything else.special casing. Give players a rich but limitedtool set that can be used in a variety of ways,not a bunch of individual, unpredictable solutionsto every problem. Always work within thelimits of your technology rather than trying tomake your technology do things it wasn’t meantto do. Big budgets, lots of time, and freedomfrom creative constraints are seductive traps.Don’t settle for less than greatness, but don’tthink too big. Balance should be the goal.3. We didn’t front-load all of ourrisksIn fact, we missed a big one. We were smartenough to realize we’d have to prototype andimplement our new game systems early so we’dhave time to tweak and refine them sufficiently.

205SECTION III: MANAGING INNOVATION205We did our conversation system and our complex2D interface screens early, which was agood thing, too—they required as much tweakingas we feared. And in the end, they turnedout pretty well, I think.Unfortunately, we missed one huge riskarea—artificial intelligence. I don’t know howwe missed it, but we did. It’s not that we didn’tspend time on AI. We started thinking about AIearly in preproduction. Unfortunately, what thatmeant was that the AI was, to a great extent,designed in a vacuum, and as is often the case,we didn’t really know what the game requiredwith respect to AI until relatively late in development.And that meant implementing AI featuresearly on that ended up being unnecessarylater, once our design had evolved into its finalform.In addition, building on the base of UNREALTOURNAMENT’s pure shooter AI meant that,instead of designing a system specifically for ourneeds, we ended up adding stuff and tweakinguntil the bitter end, causing NPC behavior tochange constantly, right up to the last day ofdevelopment. We ended up with some prettycompelling AI, but the problem of convincingpeople they’re interacting with real people isimmense, particularly when you’re talkingabout characters whose reactions have to runthe gamut from fear to friendliness to violentenmity. Our sin was, I think, giving people ahint of what human AI could be in games, butdelivering the goods inconsistently.4. Proto-missions reduxGame Developer’s Postmortems typically focusin on things the team clearly did right and thingsthe team clearly did wrong. It sure is nice whenthings are that clear. Maybe it’s just me, but Ialmost never see things in such black-and-whiteterms. Most of the time, problems are knottyand solutions are far from obvious or clear-cut,which is where the final two “What WentWrongs” fall.As I already mentioned, we recognized the needfor proto-missions relatively early on, and builtour schedule around the idea. We implementedtwo such missions, which helped us identifymany things that didn’t work (and many thatdid). With proto-missions in hand, we foundourselves at a critical juncture with two possiblechoices to make, the implications of which I stilldon’t entirely understand.On one hand, I could have gone off with somesubset of the team and tweaked our proto-missionsuntil they were absolutely right and modelsfor all subsequent mission implementationbefore turning the rest of the team loose onimplementation of the rest of the missions. Onthe other hand, I could have kept the entireteam in implementation mode, getting all of themissions to the level of the proto-missions,meaning none of them would be exactly rightbut we’d be able to see the shape of the entiregame and all of the missions would be ready fortuning at about the same time.The first approach would have left large portionsof the team in thumb-twiddling or makeworkmode for some unspecified period of time.

Ion Storm’s DEUS EX 206This promised to prove that we could create aground-breaking, compelling game, but couldleave us without a finished game to ship. Thesecond approach would have kept everyone productivethroughout the project and at least putus in position to decide whether or not to shipthe game at some foreseeable point in the future.The question was whether we would be able toturn all of the bare-bones missions into somethingfun or not.I chose the latter approach and told everyone toget the game “finished” and playable at a bareboneslevel. We’d worry about fleshing out allthe missions, making the game as interestingand fun and dense and exciting as it needed tobe during the inevitable gameplay tuning,tweaking, and balancing phase at the end. Thisprobably isn’t so much of a “What WentWrong” as it is an open question of whetherthat was the right call.I think so, and the plan clearly worked to theextent that we shipped a game that people seemto like pretty well. But it’s unclear to mewhether using our proto-missions to fine-tunemight not have resulted in an even better game.1999. The company did the same things allgame companies do, went through the sameproblems, but because we painted a big ol’“suck it down” target on our chests, the gamingpress and a fair number of hardcore gamerswent after us with a vengeance.Not too surprisingly, this had an effect on thoseof us working away in the Austin office. Moralehits were frequent and problematic. It simplyisn’t possible to be bombarded by negative pressabout the company you work for and not take itsomewhat personally. Trust me when I say thatseeing your personal and private e-mails postedon the Internet is a devastating experience.Also, recruiting was more difficult than itshould have been. We were able to put togetheran incredibly talented team for DEUS EX, buttoo many talented people told us that while theywould like to work on DEUS EX, they couldn’twork for Ion Storm. Eventually, a “we’ll show5. Is it true that any publicity isgood publicity?This wouldn’t be a complete or accurate pictureof the development of DEUS EX if we didn’t takea look at the Sturm und Drang that was IonStorm. In case you you’ve been living under arock, there’s been a lot of hype surrounding thecompany. On the negative side, Ion Storm washeaped with bad press for much of 1998 andBringing believable human characters to lifeis no easy task. The artists, whether workingon concept art, 3D models, or texturing, hadtheir work cut out for them.

207SECTION III: MANAGING INNOVATION207them” mentality became prevalent in Austin. Idon’t know that anyone who worked on DEUSEX thought of him- or herself as part of thesame company making DAIKATANA andANACHRONOX up in Dallas. That kind of usversus-themthinking is rarely good in the longrun.Now that we’ve shipped, the reviews seem tofall into two categories—those that begin withsome statement implying that Warren Spectormakes games all by himself (which is silly), andthose that begin with some statement proclaimingthat DEUS EX couldn’t possibly have beenmade by Ion Storm (also silly). Silly or not,there’s a level on which we’re still trying to livedown our past, at least in terms of the media’sperception of our game and the company thatpaid the bills here.But, for all the problems, being associated withIon Storm wasn’t all bad—far from it. On theplus side, it isn’t as if anyone from RollingStone, Entertainment Weekly, the New YorkTimes, the L.A. Times, USA Today, MotherJones, the Wall Street Journal, Forbes, Fortune,Time, Architectural Digest, CNN, or the BBCever banged down the doors at Origin or LookingGlass to talk to me or anyone on any of myteams. In reality, the bad publicity was almostentirely limited to the gaming press. The mainstreammedia, which barely notice anythingabout gaming (other than the fact that we supposedlyturn normal kids into vicious killers),didn’t seem to care about the bad stuff. But theysure did take notice of us. Ultimately, Ion’s abilityto attract attention to itself, even if it wassometimes in negative ways, probably workedto our advantage. Whether publicity at any costis good or bad is still an open question for me.The Bottom LinePart of the challenge of game development ismaking the tough decisions along the way, themany difficult junctures when you have to determinethat something that can’t be done right inthe game shouldn’t be done at all. It’s all welland good to have design goals and an idealgame pictured in your head when you start, butyou have to be open to change and realisticabout what can and can’t be done in a reasonabletime frame, for a reasonable amount ofmoney, with the personnel and technology availableto you. And if you don’t have time to dosomething right, cut it and do everything that’sleft so well that no one notices the stuff thatisn’t there.I’m not saying we did that perfectly on DEUS EX.We certainly didn’t ship a perfect game. But ifwe hadn’t gone into development with the attitudethat we’d do things right or not at all, wewould have fallen far shorter of perfection thanwe did. How close we did get is something all ofyou can decide for yourselves. All I know iswe’re going to get closer next time.

This Page Intentionally Left BlankIon Storm’s DEUS EX 208

209Naughty Dog’sJAK & DAXTER: THEPRECURSOR LEGACYby stephen whiteBy the end of 1998, Naughty Dog had finishedthe third game in the extremely successfulCRASH BANDICOOT series, and the fourth game,CRASH TEAM RACING, was in development for a1999 year-end holiday release. And though Sonywas closely guarding the details of the eagerlyawaited Playstation 2, rumors—and our ownspeculations—convinced us that the systemwould have powerful processing and polygonalcapabilities, and we knew that we’d have tothink on a very grand scale.Because of the success of our CRASH BANDI-COOT games (over 22 million copies sold), therewas a strong temptation to follow the sametried-and-true formula of the past: create a linearadventure with individually loaded levels,minimal story, and not much in the way of characterdevelopment. With more than a little trepidation,we decided instead to say goodbye to thebandicoot and embark on developing an epicadventure we hoped would be worthy of theexpectations of the next generation of hardware.Back-StoryA flagship title for the PlayStation 2, JAK & DAXTER isthe latest in a line of third-person, platform-jumping,item-collecting games featuring charismatic lead characters.To this venerable formula, Naughty Dog broughttheir experience and prestige as creators of CRASHBANDICOOT, one of the PlayStation's signature titles. JAK& DAXTER features new-generation graphics and, notably,a huge, sprawling world that unfolds continuouslyrather than in discrete levels.For JAK & DAXTER, one of our earliest desireswas to immerse the player in a single, highlydetailed world, as opposed to the discrete levelsof CRASH BANDICOOT. We still wanted to havethe concept of levels, but we wanted them to beseamlessly connected together, with non-obviousboundaries and no load times betweenthem. We wanted highly detailed landscapes, yetwe also wanted grand vistas where the playercould see great distances, including other surroundinglevels. We hoped the player would beable to see a landmark far off in the distance,even in another level, and then travel seamlesslyto that landmark.It was important to us that Jak’s world makecohesive sense. An engaging story should tie the

Naughty Dog’s JAK & DAXTER: THE PRECURSOR LEGACY 210game together and allow for character development,but not distract from the action of thegame. The world should be populated withhighly animated characters that would give Jaktasks to complete, provide hints, reveal storyelements, and add humor to the game. We alsowanted entertaining puzzles and enemies thatwould surpass anything that we had donebefore.Game DataRelease Date: December 2001Publisher: Sony Computer EntertainmentGenre: 3D fantasy platformer/adventurePlatform: Playstation 2Number of Full-time Developers: 35Length of Development: 1 year of initialdevelopment, plus 2 years of full production.Operating Systems Used: Windows NT, Windows2000, LinuxDevelopment Software Used: Allegro Common Lisp,Visual C++, GNU C++, Maya, Photoshop, X Emacs,Visual SlickEdit, tcsh, Exceed, CVSTo achieve these and many other difficult tasksrequired three years of exhausting work, includingtwo years of full production. We encounteredmore than a few major bumps in the road,and there were times when the project seemedlike an insurmountable uphill battle, but wemanaged to create a game that we are quiteproud of, and we learned several important lessonsalong the way.What Went Right1. SchedulingPerhaps Naughty Dog’s most important achievementis making large-scale games and shippingthem on time, with at most a small amount ofslip. This is an almost unheard of combinationin the industry, and although there is a certainamount of luck involved, there are valid reasonsto explain how Naughty Dog has managed toachieve this time and again.Experience will tell you it’s impossible to predictthe precise details of what will be worked onmore than a month or two in advance of doingit, yet many companies fall into the trap of tryingto maintain a highly detailed schedule thattries to look too far into the future. What can’tbe effectively worked into these rigid schedulesis time lost to debugging, design changes, overoptimism,illness, meetings, new ideas, and myriadother unpredictable surprises.At Naughty Dog, we prefer a much more flexible,macro-level scheduling scheme, with milestoneaccomplishments to be achieved by certaindates. The schedule only becomes detailed fortasks that will be tackled in the near future. Forexample, a certain level will be scheduled tohave its background modeled by a certain date.If the milestone is missed, then the team makesan analysis as to why the milestone wasn’tachieved and changes plans accordingly: thebackground may be reduced in size, a futuretask of that artist may be given to another artistto free up more time, the artist may receive

211SECTION III: MANAGING INNOVATION211guidance on how to model more productively,or some future task may be eliminated.In the case of JAK & DAXTER, we used theknowledge we’d gained from creating theCRASH BANDICOOT games to help estimate howlong it should take to model a level. As we modeleda few levels, however, we soon realized thatour original estimates were far too short, and sowe took appropriateactions. If we had attemptedto maintain a long-term, rigidlydetailed schedule, wewould have spent a lot oftime trying to update somethingthat was highly inaccurate.Beyond this being awaste of time, the constantrescheduling could have hada demoralizing effect on theteam.2. EffectivelocalizationtechniquesWe knew from the start thatwe were going to sell JAK &DAXTER into many territories around the world,so we knew we would face many localizationissues, such as PAL-versus-NTSC, translations,and audio in multiple languages. Careful structuringof our game code and data allowed us tolocalize to a particular territory by swapping afew data files. This meant we only had to debugone executable and that we had concurrentdevelopment of all localized versions of thegame. All of our animation playback code wasExtensive character sketches andcolor key/ concept design work weredone in advance of actual modeling.written so that it could automatically step animationsat a rate of 1.2 (60fps/50fps) whenplaying in PAL. We also used a standardizednumber of units per second so that we couldrelate the amount of time elapsed in a gameframe to our measure of units per second. Onceeverything was nice and consistent, then timingrelatedcode no longer had to be concerned withthe differences between PAL and NTSC.Physics calculations wereanother issue. If a ball’smotion while beingdropped is computed byadding a gravitational forceto the ball’s velocity everyframe, then after one secondthe ball’s velocity hasbeen accelerated by gravity60 times in NTSC but only50 times in PAL. This discrepancywas big enough tobecome problematicbetween the two modes. Tocorrect this problem, wemade sure that all of ourphysics computations weredone using seconds, andthen we converted the velocity-per-second intovelocity-per-game-frame before adding thevelocity to the translation.3. Seamless world, grandvistas, and no load timesWe knew very early on in the development ofJAK & DAXTER that we wanted to immerse theplayer within one large expansive world. We

Naughty Dog’s JAK & DAXTER: THE PRECURSOR LEGACY 212didn’t want to stall the gamewith loads between the variousareas of that world. JAK &DAXTER’s designers had toovercome many obstacles toachieve our open environments.They had to lay out thelevels of the world carefully sothat levels could be moved inand out of memory withoutstalling gameplay or causingugly visual popping. They alsohad to create challenges thatwould engage the player andmaintain the player’s interest,even though the player couldroam freely around the world.And they had to tune the challengesso that the difficultyramped up appropriately,without giving players theimpression that they werebeing overly directed.The programmers had to createtools to process interconnectedlevels containingmillions of polygons and createthe fast game code thatcould render the highlydetailed world. We developedseveral complex level-of-detail (LOD) schemes,with different schemes used for different typesof things (creatures versus background), and differentschemes used at different distances, suchas simplified models used to represent farawaybackgrounds, and flats used to represent distantgeometry. At the heart of our LOD system wasA frame from Jak’s victoryanimation displaced as IK,textured, and textured with colorshading.our proprietary mesh tessellation/reductionscheme, whichwe originally developed forCRASH TEAM RACING andradically enhanced for JAK &DAXTER.The artists had the burden ofgenerating the enormousamount of content for theseenvironments. Their task wascomplicated by the very specializedconstruction rules theyhad to follow to support ourvarious renderers. Supporttools and plug-ins were createdto help the artists, but werelied on the art staff to overcomemany difficulties.4. Camera controlFrom the initial stages of JAK& DAXTER, we looked at thevarious camera schemes usedin other games and came tothe depressing conclusion thatall existing camera schemeshad serious issues. We suspectedthat making a wellbehavedcamera might be anunsolvable 3D problem: How could one possiblycreate a camera that would maneuverthrough a complex 3D world while behavingboth unobtrusively and intelligently? Only foolswould believe that all problems have a solution,so, like idiots, we decided to give it a try.

213SECTION III: MANAGING INNOVATION213The resulting camera behaved extremely well,and although it had its limitations, it proved theproblem does indeed have a solution. Jak canjump through trees and bushes, duck underarchways, run between scaffolding, scale downcliffs, and hide behind rocks, all with the cameraunobtrusively keeping the action in view. Wewanted the player to be able to control the camera,but we did not want to force the player todo so. Players can use the second joystick tomaneuver the camera (rotating the camera ormoving it closer to or farther from Jak), but wewere concerned that some people may not wantto manipulate the camera, and others, such aschildren, may not have the required sophisticationor coordination.Therefore, we worked very hard at making thecamera do a reasonable job of showing playerswhat they needed to see in order to complete thevarious challenges. We accomplished thisthrough a combination of camera volumes withspecially tuned camera parameters and specializedcamera modes for difficult situations. Also,creatures could send messages to the camera inorder to help the camera better show the action.This may sound funny, but an important featureof the camera was that it didn’t make peoplesick. This has been a serious problem that hasplagued cameras in other games. Wespent a bit of time analyzing why peoplegot sick, and we tuned the cameraso that it reduced the rotational andextraneous movement that contributedto the problem. Perhaps the greatestsuccess of the camera is that everyoneseems to like it. We consider that amajor accomplishment, given the difficulty ofthe task of creating it.5. GOAL rules!Practically all of the run-time code (approximatelyhalf a million lines of source code) waswritten in GOAL (Game Object Assembly Lisp),Naughty Dog’s own internally developed language,which was based on the Lisp programminglanguage. Before you dismiss us as crazy,consider the many advantages of having a customcompiler. Lisp has a very consistent, smallset of syntactic rules involving the constructionand evaluation of lists. Lists that represent codeare executed by evaluating the items that are inthe list; if the head of the list is a function (orsome other action), you could think of the otheritems in the list as being the parameters to thatfunction.This simplicity of the Lisp syntax makes it trivialto create powerful macros that would be difficultor impossible to implement using C++. Writingmacros, however, is not enough justification forwriting a compiler; there were features we feltwe couldn’t achieve without a custom compiler.GOAL code, for example, can be executed at alistener prompt while the game is running. Notonly can numbers be viewed and tweaked, code

Naughty Dog’s JAK & DAXTER: THE PRECURSOR LEGACY 214itself can be compiled and downloaded withoutinterrupting or restarting the game.This allowed the rapid tuning and debugging,since the effects of modifying functions and datastructures could be viewed instantaneously. Wewanted creatures to use nonpreemptive cooperativemulti-tasking, a fancy way of saying thatwe wanted a creature to be able to execute codefor a while, then “suspend” and allow othercode to execute. The advantage of implementingthe multi-tasking scheme using our own languagewas that suspend instructions could beinserted within a creature’s code, and state couldbe automatically preserved around the suspend.Consider the following small snippet of GOALcode:(dotimes (ii (num-framesidle))(set! frame-num ii)(suspend))This code has been simplified to make a point,so pretend that it uses a counter called ii to loopover the number of frames in an animationcalled idle. Each time through the loop the animationframe is set to the value of ii, and thecode is suspended. Note that the value of ii (aswell as any other local variables) is automaticallypreserved across the suspend. In practice,the preceding code would have been encapsulatedinto a macro such as:(play-anim idle;; Put code executedfor each time..;; through the loophere.)There are other major compiler advantages: aunified set of assembly op-codes consistentacross all five processors of the Playstation 2,register coloring when writing assembly code,and the ability to intermix assembly instructionsseamlessly with higher-level code. Outer loopscould be written as “slower” higher-level code,while inner loops could be optimized assembly.What Went Wrong1. GOAL sucks!While it’s true that GOAL gave us many advantages,GOAL caused us a lot of grief. A singleprogrammer (who could easily be one of the topten Lisp programmers in the world) wroteGOAL. While he called his Lisp techniques andprogramming practices “revolutionary,” othersreferred to them as “code encryption,” sinceonly he could understand them.Because of this, all of the support, bug fixes, featureenhancements, and optimizations had tocome from one person, creating quite a bottleneck.Also, it took over a year to develop thecompiler, during which time the other programmershad to make do with missing features, oddquirks, and numerous bugs.Eventually GOAL became much more robust,but even now C++ has some advantages overGOAL, such as destructors, better constructors,and the ease of declaring inline methods. Amajor difficulty was that we worked in such isolationfrom the rest of the world. We gave up

215SECTION III: MANAGING INNOVATION215third-party development tools such as profilersand debuggers, and we gave up existing libraries,including code previously developed internally.Compared to the thousands ofprogrammers with many years of C++ experience,there are relatively few programmers withLisp experience, and no programmers (outsideof Naughty Dog) with GOAL experience, makinghiring more difficult.GOAL’s ability both to execute code at the listenerand to replace existing code in the game atrun time introduced the problem of memoryusage, and more specifically, garbage collection.As new code was compiled, older code (andother memory used by the compiler) wasorphaned, eventually causing the PC to run lowon free memory. A slow garbage collection processwould automatically occur when availablememory became sufficiently low, and the compilerwould be unresponsive until the processhad completed, sometimes taking as long as 15minutes.Screenshot showing highest level ofdetail of in-game geometry for theForbidden Jungle level.2. Gameplay programmingBecause we were so busy creating the technologyfor our seamless world, we didn’t have timeto work on gameplay code until fairly late in theproject. The situation caused no end of frustrationto the designers, who were forced to designlevels and creatures without being able to testwhether what they were doing was going to befun and play well. Eventually programmerswere moved off of technology tasks and ontogameplay tasks, allowing the designers to playthe game and make changes as appropriate. Butwithout our designers’ experience, diligence,and forethought, the results could have been adisaster.3. AudioWe were plagued with audio-related problemsfrom the start. Our first indication that thingsmight not be going quite right was when oursound programmer quit and moved to Australia.Quickly hiring another sound programmerwould have been the correct decision. We triedseveral otherschemes, however,The same shot displayed withtextures.made some poorchoices, and hadquite a bit of badluck. We didn’t recognizeuntil fairlylate in developmentwhat a monumentaltask audio was goingto be for this project.

Naughty Dog’s JAK & DAXTER: THE PRECURSOR LEGACY 216Not only did JAK & DAXTER contain originalmusic scores, creature and gadget noises, ambientsounds, and animated elements, but thereare also over 45 minutes of story sequences,each containing Foley effects and speechrecorded in six different languages. Our audioissues could be broken up into four categories:sound effects, spooled Foley, music, and localizeddialogue. Due to the large number of soundeffects in the game, implementing sound effectsbecame a maintenance nightmare. No singlesound effect was particularly difficult or timeconsuming;however, creating all of the soundeffects and keeping them all balanced and workingwas a constant struggle. We needed to havemore time dedicated to this problem, and weneeded better tool support.We used spooled Foley for lengthy sound effects,which wouldn’t fit well in sound RAM. Spoolingthe audio had many advantages, but wedeveloped the technology too late in the projectand had difficulty using it due to synchronizationissues. Our music, although expertly composed,lacked the direction and attention todetail that we had achieved with the CRASHBANDICOOT games. In previous games, we had aperson who was responsible for the direction ofthe music. Unfortunately, no one performed thatsame role during JAK & DAXTER.Dialogue is a difficult problem in general due tothe complexity of writing, recording, editing,creating Foley, and managing all of the audiofiles, but our localization issues made it especiallychallenging. Many problems were difficultto discover because of our lack of knowledge ofthe various languages, and we should have hadmore redundant testing of the audio files by peoplewho were fluent in the specific languages.4. Lengthy processing timesOne of our greatest frustrations and loss of productivitycame from our slow turnaround timein making a change to a level or animation andseeing that change in the actual game. Since allof our tools (including the GOAL compiler) ranacross our network, we ran into severe networkbandwidth issues. Making better use of localhard drives would have been a smarterapproach. In addition, we found extreme networkslowdown issues related to reading filetime/date stamps, and some tools took severalminutes just to determine that nothing neededto be rebuilt.When we compiledsome of our toolsunder Linux, wenoticed dramaticimprovements innetwork performance,and we areplanning on usingLinux more extensivelyin our nextproject. We implementedthe processing of the lengthy storysequenceanimations as a hack of the systemused to process the far simpler creature animations.Unfortunately, this bad system causedlengthy processing times, time-consumingdebugging, and a lot of confusion.

217SECTION III: MANAGING INNOVATION217If we had initially hidden the processing complexitybehind better tools, we would havesaved quite a bit of time.We used level-configuration scripts to set actorparameters and other level-specific data. Thescript processing was done at an early stage inour tools pipeline, however, so minor datachanges took several minutes to process. Welearned that tunable data should instead be processedas close as possible to the end of the toolspipeline.5. Artist toolsWe created many tools while developing JAK &DAXTER, but many of our tools were difficult touse, and many tools were needed but never written.We often didn’t know exactly what weneeded until after several revisions of our technology.In addition, we didn’t spend a lot oftime polishing our tools, since that time wouldhave been wasted if the underlying technologychanged. Regrettably, we did not have time toprogram tools that were badly needed by theartists, which resulted in a difficult and confusingenvironment for the artists and caused manyproductivity issues. Since programming createda bottleneck during game production, the addedburden given to the artists was considered necessary,though no less distasteful.We lacked many visualization tools that wouldhave greatly improved the artists’ ability to findand fix problems. For example, the mainmethod artists used to examine collision was adebugging mode that colorized a small sectionof collision geometry immediately surroundingJak. A far better solution would have been tocreate a renderer to display the entire collisionof a level.We created plug-ins that were used within the3D modeling package; however, for flexibility’ssake most of the plug-ins operated by takingcommand parameters and outputting results astext: not a good interface for artists. Eventually,one of our multi-talented artists created menusand other visualization aids that significantlyimproved productivity. Many of our tools werescript based, which made the tools extremelyflexible and adaptable; however, the scripts wereoften difficult for the artists to understand anduse. We are replacing many of these scripts witheasier-to-use GUIs for our next project.The LegacyCreating JAK & DAXTER was a monumentaleffort by many hardworking, talented people. Inretrospect, we were probably pretty foolish totake on as many challenges as we did, and welearned some painful lessons along the way. Butwe also did many things right, and we successfullyachieved our main goals. At Naughty Dog,there is a strong devotion to quality, which attimes can border on the chaotic, but we try tolearn from both our success and our failures inorder to improve our processes and create a bettergame. The things that we learned from JAK& DAXTER have made us a stronger company,and we look forward to learning from our pastas we prepare for the new challenges ahead.

This Page Intentionally Left BlankNaughty Dog’s JAK & DAXTER: THE PRECURSOR LEGACY 218

219SECTION IVBuilding on a LicenseA license game is a game based on an existingcreative property borrowed from some othermedium. A game could be based on nearly anything—we’veseen adaptations of books, films,television shows, magazines, dolls, rock bands,comic books, basketball players, and softdrinks. For any work under copyright, somebodyholds the interactive rights and may partwith them for a price.The prospect is enormously tempting. Whatgame developer hasn’t dreamed of adaptingsome cherished work, of building their own personalvision of the Mines of Moria or Gormenghast,of Dickensian London, Chiba City, orNeo-Tokyo? It’s part of the basic lure of themedium, being able to enter into and interactwith imagined worlds.And why not? It also makes business sense. Economically,licensing games is a method forreducing financial risk. The licenser takes a feeor a cut of the profits, but the combination ofname-recognition, added marketing muscle, andan established fan base guarantees a minimumlevel of sales.From a production standpoint, the licensemeans you have original content you don’t haveto develop yourself, most of it probably firstrate.Character design, world design, and storyare taken care of. If it’s a film or televisionlicense, you may be able to pick up actual audio,texture, and voice acting from the originalsource.There are downsides to licensing games, however.Of course, whoever owns the license isgoing to receive a portion of the profits. Licenserscan also be extremely protective of their creativeproperty, and not without reason. Acreative property can be damaged by improperhandling. A licensed game that is poorly done,that fails to convey the spirit of the original creativework, or alters its fictional continuity insome way can change how the public sees thatproperty. All this tends to make the owner of thelicense quite nervous, quick to demand oversightof the project.Licensers may set rules and limits on what theproject team can do, which may hinder theircreative freedom, especially when the licenser isunfamiliar with interactive media. The licenser

Section IV: BUILDING ON A LICENSE 220can even deny access to crucial resources (suchas actors for voice acting) or revoke the licenseentirely.The flip side of name recognition is high expectationsfrom fans of the original work. Peoplewho are genuinely invested in a work may beunhappy to see a video game based on it. Peopleinvest emotion in works of art, and they don’tlike having their emotions messed with. Audiencesmay not trust interactive adaptations, andthere is some justice to that attitude. If youscrew up, the potential for backlash is enormous.In any case, the original creative teambehind the property may not be participating inthe production process, so even if you do a reasonablejob, your effort won’t bear the seal ofauthenticity.Any game released on a license bears the burdenof reproducing the thrill of the original work,while adding interactivity. In a sense, they arecompeting with the license on its home turf. Forexample, a property that originates in a novel cantrade on the strengths of that medium—witty,nuanced dialogue, direct perception of characters’thoughts, large-scale scenes, descriptive languagethat inspires the imagination. The gameversion has to give players an equally good renditionof the property, but using totally differenttools. Few enough licensed games live up to thechallenge—most manage to remind us of theoriginal work, but don’t deliver equally. Afew—Totally Games’ X-WING, Rare’s GOLDEN-EYE—equal or even surpass their source material.The challenge of adapting works from othermedia can tell us an enormous amount aboutour own. When a film or a book or a comicbecomes a video game, everything changes, andthose changes reflect the nature of the interactivemedium itself. Just ask yourself why thegame industry hasn’t adapted Jane Austen,Shakespeare, E. M. Forster, or Henry James?Their books have been adapted into a numberof successful movies recently. They aren’t evenunder copyright, so they’re available for free.Why hasn’t anyone scooped them up? The factthat the game industry hasn’t done so illustratesthe weaknesses of interactive media.Every year computer game graphics improve,but even so, no game has approached the qualityof the cinematic image in a real-time interactiveformat. This is especially true when it comesto the human form—our ability to simulatehuman faces and body language is primitivecompared to what film can do.Films and novels show characters talking toeach other, having intimate, nuancedexchanges—it’s one of the basics of those forms,but computer games can’t do it interactively, noton the same level. Natural language, facialexpressions, and body language are unsolvedproblems for computers. Real people are toohard to simulate—the best we can do at thispoint is to produce consistent-looking worlds,stylized and perhaps cartoonish, but successfulon their own terms.Adapting story is almost as big a problem. Novelsand films have become the storytelling mediapar excellence of the twentieth century, with awell-understood body of techniques. Again, it’sa basic part of those media, something you

221Section IV: BUILDING ON A LICENSEdon’t even think about, but we are still learninghow to do it in interactive media. Instead, westretch out narratives with long episodes of runningthrough sewers or jumping around onledges, situations we do know how to showextremely well.We face so many obstacles—the relative clumsinessof character interaction, the difficulty ofintegrating gameplay with narrative exposition—thatour efforts may look clumsy in directcomparison to a film’s smooth exterior. Howmany early licensed games bore almost noresemblance to the original? The grand promiseslaid out on the back of the box gave way tostilted little cartoons within. What was a vividand taut action sequence on film, became hoursof jumping over boxes on a TV screen. No oneis going to forget E.T. on the Atari 2600.But these failures at least show us how muchbetter we’re getting. Along the way we havelearned a few things. Aside from the advantageslisted above, the main lesson about licensedgames is this: there is more than one way toadapt a license, so play to your strengths. Youdon’t have to limit yourself to simply recreatingthe original—you can use the license in differentways to suit the style of game you’re ready tomake. You can expand a small part of the fictionalworld, do a prequel, a sequel, or carveout your own niche in the established universe,far away from the main action.In a world as expansive and rich as the StarWars universe, you don’t have to be LukeSkywalker every time. In DUNE 2, Westwoodtook their license and stripped it down to oneessential aspect—desert planet economic warfare—andreproduced it beautifully, while ignoringother aspects of the license, characters’personal stories, that didn’t suit their game andwere much harder to reproduce in the interactivemedium.Licenses are an important section of the industry.They bring much-needed financial stabilityto any company’s balance sheets. They createlinks between our industry and other sections ofthe entertainment world, with film directors andactors and novelists. They bring in new audiences,fans of other media who might otherwisenever sit down in front of a computer to beentertained. And, finally, they teach us aboutour own medium, show us where our strengthsand weaknesses are, the things we can’t do, andthe things we can do better than anyone else.

This Page Intentionally Left BlankSection IV: BUILDING ON A LICENSE 222

223LucasArts’STAR WARSSTARFIGHTERby chris corryWork on Project Europa—the internal codenamefor the development effort that wouldeventually metamorphose into STAR WARSSTARFIGHTER—began in earnest in April 1998.A small crew of programmers, headed up bydirector Daron Stinnet, began preproductionwork on a STAR WARS: EPISODE I PC title thathad grand ambitions. As one of LucasArts’ greatunsung talents, Daron had previously led theDARK FORCES and OUTLAWS teams to muchcritical and commercial success. Now, followingin the footsteps of Larry Holland’s X-WINGgames, Europa was to bolster LucasArts’ presencein the space-combat genre and support thenew film franchise. While embracing much ofthe X-WING series’s simulation-oriented aesthetic,the team also wanted to deliver the visceral,sweaty-fingered arcade experience that wewere starting to see in early builds of ROGUESQUADRON.During the early months of 1999, a well-knowndesigner who was in the market for a new leadprogrammer and lead level designer for his company’soverdue project secretly approached twomembers of our team about the possibility ofBack-StoryThis air- and space-combat game is set in the Star Warsuniverse of Episode One: The Phantom Menace. Thegame’s story follows three protagonists—a Rebel pilot,a bounty hunter, and a pirate captain—in a series of missions,tracing a story that interleaves cleverly with theevents of the movie.jumping ship. Although obviously conflicted,the allure of working with a famous industryheavyweight proved too tempting, and within afew short weeks we had lost our main graphicsprogrammer and level designer. Shaken butundeterred, we were determined to make thebest of a bad situation, but three months laterthe project suffered another blow when we lostour second graphics programmer.This was Europa’s darkest hour. The technologydevelopment was progressing slowly, and ourinexperienced programming staff was stillclimbing the C++ learning curve. As lead programmer,this predicament was largely of myown making. I had joined LucasArts from outsidethe game industry, where I was accustomedto a corporate R&D environment that valuedsolid engineering and extensible software architectureover quick solutions that were perhaps

LucasArts’ STAR WARS STARFIGHTER 224less elegant or flexible. Now, with little to showbut a creaky Glide-based graphics engine and nographics programmer, we were at a loss as towhat to do next.As if things weren’t bad enough, we were alsofloundering on the game design side of the fence.Although we had a lot of excellent concept art,few of us had a clear idea about exactly whatGame DataRelease date: February 2001Publisher: LucasArtsGenre: science fiction, ship-to-ship combatPlatform: Playstation 2Full-time developers: Approximately 40 at the heightof productionLength of development: 30 monthsHardware used: 700MHz Pentium IIIs with 256MBRAM, GeForce 256, PS2 toolsSoftware used: Windows 2000, Microsoft Visual C++,Metrowerks for PS2, 3D Studio Max, Softimage,Photoshop, Bryce, Visual SourceSafe, Perl,AfterEffects, PremiereTechnologies: Eve level design tool, Miles SoundSystem, ObjectSpace STL, Macromedia/Secret LevelFlash, Planet Blue’s Tulip for prerendered cut-scenelip-syncingLines of code: 301,000 including toolstype of game we were making. We were painfullystarting to discover that while it is easy tocharacterize a title as being a cross betweenROGUE SQUADRON and X-WING, it’s anotherthing completely to describe what that actuallymeans.At this point two events occurred that I’m convincedsaved the project. Our multiplayer programmer,Andrew Kirmse, who had alreadyproven himself as a remarkably capable technologist,teamed up with two of our other programmersto create a graphics-engine “tigerteam,” a small subteam dedicated to attacking asingle task with unwavering focus. In just a fewmonths the three of them delivered a brand-newOpenGL-based engine that was far better thananything we had built previously.Shortly after the new graphics engine cameonline we also found the solution to our gamedesign woes. Tim Longo, who had recentlyhelped complete INDIANA JONES AND THEINFERNAL MACHINE, joined the team as ourlead level designer. The change was immediateand profound; five other level designers joinedthe project at about the same time, and now wehad the foundation for a thriving, collaborativedesign process. Daron worked with Tim and theother level designers on an almost daily basis,systematically identifying areas of the gamedesign that were incomplete and workingtogether to come up with concrete solutions.By the end of 1999 the project had performed a180-degree turnaround, but there was one moresignificant twist in the road awaiting us. Sonyhad turned the game industry on its ear with theformal announcement of the Playstation 2 thatyear, and every major development house wasfuriously rewriting business plans to accommodatesupport for the new platform; LucasArtswas no exception. The biggest problem for thecompany was that we wanted to have a titleclose to the system’s launch, and Europa was the

225SECTION IV: BUILDING ON A LICENSE225only project far enough along to be a seriouscandidate. The thought of throwing the PS2 intothe mix made many people very uncomfortable,but when we were able toport all of our non-graphicscode in a single 48-hourperiod, senior managementbecame convinced.The rest of the project wasan exciting and manic blurof activity. Early in 2000 wehit the “snowball point,”that period when all of asudden the tech falls intoplace, the art productionpaths are running on all cylinders,and the team is seeingexciting new gameplay on an almost dailybasis. From then on, STAR WARS STARFIGHTERwas indeed like a runaway snowball, picking upmomentum and new features almost as fast aswe could think of them.A Naboo Starfighter cruising overan early take on the rolling hills ofNaboo.the picture frame, but it’s up to the rest of theteam to provide the most important part, the picture.To bring this to fruition, theprogramming team neededto understand as best wecould the way the rest of theteam worked. WhileAndrew worked with leadartist Jim Rice and ourworld-builders to understandtheir workflows, BrettDouville, our AI and missionprogrammer, filled asimilar role with the leveldesigners. Brett scheduledregular “LD Days” witheach individual member of the level design staff.This gave each designer the opportunity to meetwith Brett on a regular basis and show him thespecific challenges and problems that they weretackling in their missions.What Went Right1. Good team communicationI’ve read many Game Developer Postmortemsthat blamed failures on a lack of communication,so I’m particularly proud that we got this oneright. From the beginning of the project, Daronworked hard to impress on the programmersthat it was the level designers and artists thatwould ultimately secure the success of Europa.As I became fond of saying, programmers buildEuropa periodically had full-blown team meetingswhere we could get together and kibitzabout the overall state of the project. However,the most valuable meetings were at the subteamlevel. Both the programming team and the artteams would meet weekly to discuss the issuesof the day, and each of these meetings wouldhave an attendee from the other camp—a rolewe referred to as the “exchange student.” Thismeant that if questions came up in the art meeting,for example, that required answers orinput from a programmer, there would alwaysbe someone present that could give aninformed opinion. Likewise, as programmers

LucasArts’ STAR WARS STARFIGHTER 226would discuss issues or new features in theirweekly meeting, the art or level design representativewould be able to disseminate thisinformation among the other team members.Finally, we relied on an internally maintainedWeb site as a pivotal communications tool. Wetried to make the site as comprehensive as possible,organizing areas along the lines of programming,art, level design, project management, andso on. When artists had questions about how toimplement a particular effect, or a level designer2. Project disciplineSTAR WARS STARFIGHTER was a well-organizedproject. In the heat of battle it’s all too easy tolet requirement lists and schedules get lost in theshuffle of the moment. We were determined notto let this happen. As soon as our technologybegan to take shape, we started to follow aniterative process of milestone planning and execution.These milestones were typically four tosix weeks in duration, with no milestoneextending longer than eight weeks. Milestoneswere also required to demonstratesome visual or gameplay aspect ofthe game.A schematic for the Naboo Starfighter—one of the onlyelements in the game that was present in both the originaldesign concept and the final product.As a consequence, we had veryfew milestone tasks that lookedlike “complete the Foobar class”;instead we would have a milestonetask that might read“Explosion smoke trails,” and theassigned programmer wouldknow that completing the Foobarclass was an implied requirement.By keeping our attention focusedon a discrete and relatively smallbody of work, we were able toavoid the cumulative errors thatinvariably creep into longer schedules,while still allowing fordemonstrable progress.needed a refresher on our class-file script syntax,there was usually a web page that they could bedirected to that would answer many of theirquestions.Most of the milestones were driven by theprogress of the technical team. Programmerswere solely responsible for estimating the durationof their tasks. We would occasionally adjustthese estimates outward but would never changean estimate to be shorter. Tasks were structured

227SECTION IV: BUILDING ON A LICENSE227so that the shortestscheduled taskwas never shorterthan a half-day.Even if a programmerwas certainthat a task couldbe completed inless than half aday, experienceclearly showedthat the timewould be lost elsewhere.Using these simplerules of thumb, wewere consistentlyable to buildschedules that Storyboard depicting Rhys Dallow’s ship getting hit.were fair and accurate.Out of eight scheduled milestones, wenever missed one by more than a handful ofdays. Best of all, most team members completelyavoided extended periods of crunch time. Likemost game teams as they approach their shipdate, everyone was working hard and often intothe evenings; however, this period of time wasshort, and we never had to resort to all-nighters.We also closely managed the process we used todistribute new binaries to the team at large.Since most of our development occurred on thePC even after making the decision to ship on thePS2, it was important that team members havetimely access to stable builds of the game. Weaccomplished this through weekly public builds.Once a week we would package and distributethe current code as a full-blown InstallShieldcompiledinstall. This provided team memberswith debug and production versions of thegame, along with level design tool and artexporter updates.Predicting that public builds would become criticallyimportant, we tried to be as ruthless aspossible about maintaining the build schedule.As we got closer to our ship date, the frequencyof these public builds increased until we wereperforming new builds as often as three times aweek. By this point we had a full-time staffmember dedicated to managing the public buildprocess and ensuring that the distributed codemet quality and functionality expectations.

3. A well-executed PC-to-PS2transitionMaking the decision to move the project to thePS2 could have been a complete disaster. Yet,despite paying little attention to portability duringthe earliest stages of the project, the Europacode base was well positioned to make the jumpto the PS2 platform. With the aid of strong andgenerally stable development tools provided byMetrowerks, the core port went off without ahitch.The biggest trick was on the graphics side,because this was clearly where we were mostvulnerable. None of ourprogrammers had anyconsole experience, andnone of us was up to thetask of tackling the PS2’sinfamous low-level vectorunits. Enter LECgl. LECglwas the brainchild of EricJohnston and Mark Blattel,two of LucasArts’most senior console programmers.They hadrecently shipped STARWARS: EPISODE I RACERfor the N64, and they welcomedthe opportunity totackle a problem temporarilythat was one stepremoved from the day-todaypressures of a project team. AlthoughEuropa was the most immediate recipient oftheir efforts, Eric and Mark were never officiallyLucasArts’ STAR WARS STARFIGHTER 228A page from the programming sectionof the STAR WARS STARFIGHTER internalWeb site.on the project. Instead they worked in a supportrole, providing us with regular LECgl librarydrops and immediate “on-call” PS2 graphicssupport.There was another, more subtle problem that wehad to conquer when we made the decision toadopt the PS2 as our primary platform. Most ofthe team members were big PC game players,but very few of us played console games. Intellectually,we knew that there were huge philosophicaldifferences in game design betweenconsoles and the PC. Much of our original gamedesign had used the X-WING games as a conceptualleaping-off point, wandering into thearcade action of ROGUESQUADRON only when itsuited us.Now that we were on thePS2 we recognized thatour design prioritiesneeded to be completelyflipped. Instead we woulduse ROGUE as our primarypoint of reference andwork from there, layeringon gameplay elements borrowedfrom X-WING asneeded. As such, I thinkthe final game demonstratesour successfulindoctrination into theconsole mindset. We werehaving so much fun blowing things up that wehad little desire to start adding sim-like featuresto the gameplay experience.

229SECTION IV: BUILDING ON A LICENSE2294. MacromediaFlashAs we approached theend of summer in 2000,we realized that we hada serious problem on ourhands. Despite our bestefforts, we still had notaddressed the issue ofour out-of-game userinterface. We had a 2Dvirtual-page system thatwe were using for ourHUD (heads-up display)symbology, and we hadalways planned to evolve that into somethingthat could be used for what we called the“administrative interface.” However, in August,with the quality assurance department nippingat our heels and our ship date looming ominouslyin the distance, things were not lookinggood.We had heard that a small San Francisco–basedcompany named Secret Level was adaptingMacromedia’s Flash technology for use in PS2games. After meeting with company representatives,we were excited by the prospect. TheMacromedia content-authoring tools were farmore elaborate than anything we could come upwith in the same time frame. We also suspectedthat there was a wealth of Flash authoringexpertise available from out-of-house contractorswhich would help us smooth out the workload. Most importantly, we were very impressedby the intelligence and games savvy of the SecretLevel staff.Early concept art for the mercenary Vana.When we realized thatbuilding our user interfacein Flash would significantlyease ourlocalization efforts, wedecided to take theplunge. Soon afterwardwe hired a design firmnamed Orange Design tohelp us implement ouradministrative interfacein Flash. Orange notonly had a ton of experiencewith Flash, but theyalso brought a technicalperspective to the table.We knew that this technical emphasis would becritical for working with our programming teamon integration issues.Integrating Flash into the Europa engine wasnot a completely smooth process, however. Performancein the first-generation Flash Playerwas poor (current generations of the Player arenow much faster), and we had to spend a lot oftime integrating the user interface Flash moviewith the core game systems. That said, the fivemonths that a single half-time programmerspent on this task ended up yielding a user interfacethat was far beyond what we would havebeen able to custom-code in the same period oftime.5. Good debugging systemsOur programmers built several tools that greatlyhelped our pursuit of high-quality code. One ofthe most instrumental was a Windows-only

LucasArts’ STAR WARS STARFIGHTER 230library that provided detailed stack-tracinginformation. This library was largely based onthe code and concepts covered by John Robbins’“Bugslayer” column published in the MicrosoftSystems Journal. As is standard practice onmany games, we built a custom memory managerthat could detect when the application wasleaking memory. However, unlike most implementations,when our memory managerdetected a leak it could provide a comprehensivestack trace of arbitrary depth, leading directly tothe leaking code statement.This capability represented a significant advantageover other implementations that could onlyprovide the immediate location of the allocationrequest. If the memory allocation were beingmade by the Standard Template Library (STL)or one of our widely used utility classes, it wasusually not enough to know what part of theSTL or which one of our utility classes was theculprit. What we really needed to know waswhat class called the STL method that causedthe leak. In fact, the leak was usually severalsteps up the call chain. Our stack-tracing librarymade finding these cases almost trivial.We also incorporated stack tracing into ourexception- and assert-handling systems. Whenthe game encountered a hard crash, we trappedthe exception and generated a complete stacktrace; a similar process occurred when our codeasserted. This information was initially reportedback to the user in dialog form. However, wealso packaged up this samedata and had the gamesend the programmers ane-mail detailing exactlywhere the problemoccurred. This ended upbeing an invaluable toolfor us. As a matter of practice,the Europa programmersgot into the habit ofchecking the assert mailboxregularly. In additionto appraising the currentstability of the code, wecould also use this data tospot trends and note whenpeople weren’t being diligentabout installing newbuilds.Several of the ship models developed for STAR WARS STARFIGHTER.

231SECTION IV: BUILDING ON A LICENSE231In the end, we had an exceptionally smooth QAprocess because the bugs we did have were generallyeasy to track down and fix. There were nolast-minute “heart attack” bugs that required usto set up camp and track a single problem forhours or days at a time. This made life easier onthe programmers, but it also made things easierfor the testing team and improved morale acrossthe entire project.What Went Wrong1. StaffingAs you can probably tell by now, staffing waseasily the biggest problem the project encountered.Try as we did to manage staff retention,the team experienced an alarming amount ofturnover, both in the programming and artdepartments. This invariably made life harderfor the people left behind, because the amountof work remained constant, but team memberscould not be replenished as quickly as theywere lost.This also meant that many of the team’s juniorstaff members missed out on valuable mentoringor experienced spotty supervision by their leads.On the programming team, senior programmerswere so busy that we had little time to train newteam members. This led to a stressful sink-orswimmentality which was difficult for newhires. Even relatively simple quality-control proceduressuch as code reviews were never instituted,since every moment of every day wasdedicated to making forward progress on thegame.The staffing issue continued to dog us throughoutthe project. Even after we had regainedsome momentum, we still ended up losing twoprogrammers and a handful of artists, all to thesame online gaming startup. Although nine programmerscontributed to the main code base atone point or another, the vast majority of codewas written by the core group of four programmerswho stayed with the project to completion.2. Initial lack of detailed designEuropa was always envisioned as having somesort of Star Wars: Episode I tie-in. During muchof 1998, however, it was difficult to predict towhat degree Lucas Licensing would allow thisto happen. One of the barriers we encounteredwas the intense veil of secrecy that surroundedany Lucas-owned company involved with themovie property. Some of us had access to thescript and the occasional rough-cut screening,but particularly during the first half of 1998 itwas virtually impossible to learn the importantdetails about the film needed to build a solidfranchise title.Initially we had assumed that the game shouldstay as far away as possible from the events ofthe film. Because we were going to be telling oneof the first original stories set in the time line ofthe new film, we had no feeling for where theboundaries were with respect to planets, characters,vehicles, and the like. We were intimidatedby the pervasive atmosphere of secrecy and generalsensitivity of the Episode I storylines; the

LucasArts’ STAR WARS STARFIGHTER 232first game designs described a pirate war fardivorced from the events of the film. In fact, theNaboo Starfighter was one of the only elementsthat could be found in both the first design andthe film.The Eve level design tool was a critical part of STARWARS STARFIGHTER’s success.As this design started to circulate, however,Licensing contacted the team and explained thatthe design contained too many pirate elements;they wanted the game to contain more elementsfrom the film. The “moving target” nature ofthis exchange ended up being very disruptiveand effectively paralyzed the design effort forweeks at a time as we wandered from idea toidea, wondering what fit into continuity withthe film and what was straying into areas thatwe should keep away from.The Europa team also had some pretty big shoesto fill. It didn’t take long for us to realize thatwhatever we did was going to be directly comparedto Larry Holland’s previous X-WINGtitles. The Totally Games guys had been makinggames like for this for the better part of adecade, and they had gotten very, very good atit. Game players could rely on Larry to producelarge, sophisticated games with well-designedfeatures and compelling gameplay. This successhad, in turn, incubated a dedicated and enthusiasticfan base that we knew would mercilesslyscrutinize STAR WARS STARFIGHTER.Frankly, we were in a no-win situation: if wedeviated too far from the Totally Gamesdesigns, we risked disenfranchising some of ourmost loyal fans, but we also didn’t want simplyto copy Larry’s last game either. Fortunately,once we decided to ship on a console, the designshackles fell away and we were free to chart ourown path. While we realized that the hardcoreX-WING players might not appreciate STARWARS STARFIGHTER as much as the Larry Hollandgames, they were no longer our primaryaudience.3. Naïve approach to memoryusageAs quickly as we were able to get Europa up andrunning on the PS2, it took the programmingteam much longer to fully embrace the creed ofthe console programmer. Since Europa was originallyintended to be a PC title and our programmersonly had PC experience, it’s notsurprising that most of the code suffered from abad case of “PC-itis.” I use this term to refer toprogramming practices that, while potentiallyportable to a console, are definitely not consolefriendly.

233SECTION IV: BUILDING ON A LICENSE233Our approach to memory allocation is a perfectcase in point. For starters, we relied on the STLfor all of our container classes. On one hand webenefited from a bug-free and robust set of standardizedcollection classes. As an integral partof the C++ Standard Library,the STL contains a powerfultoolset for general applicationdevelopment. We’re bigfans of the STL, and for themost part we can’t imagineworking on a project thatdoesn’t use it. Unfortunately,depending on whatcontainers you decide to use,the STL is notorious formaking many small memoryallocations.Our STL container usagewas paralleled by our use of an uncomfortablylarge number of ANSI string objects. The ANSIstring class is a great little class that makes dealingwith character strings much easier than itused to be when we were all writing code in C.Like most STL containers, however, excessiveuse of the string class also leads to large numbersof small memory allocations. By the timewe decided to port to the PS2, most of the damagehad already been done.As I mentioned earlier, our global memory manager’soriginal focus had been memory-leaktracking, but now we needed it to help with ourSTL problem. We accomplished this by introducingthe concept of bins, which were reallyjust a hierarchy of fixed-length memory allocators.When the memory manager received aAn example of the statistics thatDaron tracked during the game’sdevelopment.small memory request, it could very quickly andefficiently satisfy the allocation if the size of therequest fell into the range serviced by our bins.We ultimately relied on the bins for both rapidmemory allocation services and fragmentationmanagement.I should also note that wehad a pretty rough time withmemory fragmentation.Going into the PS2 port wesuspected that fragmentationwas going to be a problem.On the PC we had madean effort to generally cleanup after ourselves in waysthat would help reduce fragmentation,but we nevermade a concentrated effortto eradicate it completely,because we knew that in a pinch we couldalways rely on the PC’s virtual memory system.One of my jobs during the last six weeks of theproject was to build debugging systems thatwould give us detailed memory maps and thentrack down each fragmenting memory allocationone at a time. It was every bit as unpleasantas it sounds, and I urge those PC developersmaking the switch to consoles to take this lessonto heart.4. Not enough attention paid toperformanceThere is little question that in the rush to implementfeatures and ship the game on time, performancesuffered. Part of this was due to

LucasArts’ STAR WARS STARFIGHTER 234having an inexperienced staff, and part of thiswas due to the fact that we had ported a PCcode base to the PS2, but in truth most of uswere so preoccupied with one issue or anotherthat we had little time to revisit code with an eyetoward optimization. There was a pervasiveattitude among many of us that we could safelyignore code problems until they showed up ashotspots on a profiling run.There is some merit to thisstrategy, since prematureoptimization efforts can bemore wasteful than notfixing the code at all. Butsince profiling can turn uphidden problems in areasof the code that the teamhad previously thoughtcomplete or issue-free, it’simportant to start profilingmuch earlier than we did.For example, we hadsevere performance problemsin our collision detection systems that wewould have identified immediately if we hadprofiled sooner. As it happened, by the time werealized that collision detection was workingpoorly, the best we could do was apply spotfixes instead of the large-scale reworking thatthe problem actually demanded.Even after we started a fairly regular regimen ofprofiling late in the development cycle, we stilldidn’t do enough of it. In the end, only one programmerdid all of our profiling, and he wasresponsible for making the rounds and pointingout problems to other members of the programmingstaff. This was a real shame, because theMetrowerks PS2 profiler is a very nice tool, andmost members of the team had uninstalledlicenses. I should have made our developersresponsible for profiling their own code anddoing so at a much earlier stage.5. Space-to-planetAn early version of the NabooStarfighter passing in front of a nebulain deep space.If there was anythingabout the original STARWARS STARFIGHTER pitchthat met with widespreadenthusiasm, it was the ideaof seamlessly transitioningfrom planetside environmentsto the depths ofspace and back again.Dogfighting close to theplanet surface certainlyhas its own appeal, butthere is something aboutthe promise of being ableto pull back on the stickand blast off all the way into space that is simplyvery, very cool. This high concept was soexciting to the team that the original game pitchfeatured this idea predominantly. In fact, inmany ways this single feature was to define thegame.Well, it’s a bit of a trick to actually pull off.First, there were the technical considerations. Aplanet is big. I mean really, really big. Even asmall planet would require dynamically creatingthousands of terrain tiles. Although most ofthese tiles could be procedurally generated, theywould still need to be created and discarded on

235SECTION IV: BUILDING ON A LICENSE235the fly; depending on the player’s location, custommission-area tiles would have to bestreamed in from the hard disk, all while maintainingframe rate.Of course, since we wanted to allow the playerto fly absolutely anywhere on the planet, orderingthis data on the disk in a streaming-friendlyformat was problematic. We exacerbated the situationby requiring even our lowest-resolutionterrain height maps to be much higher resolutionthan they really needed to be. This in turnmade higher theoretical demands on the streamingand resource systems. This single featurehad introduced a tremendous amount of technicalrisk to the project, and yet we had blindlycharged ahead anyway because of the idea’sinherent coolness factor.The technical issues, however, did not describethe full extent of our problems with this feature.Quite quickly we also came to realize that therewere plenty of game design issues implied by thespace-to-planet concept.For example, there was theconstant issue of playercraft speed. We felt prettysure that our ships shouldhave a top speed of about450 miles per hour, becausedogfighting and bombingground targets becomesextremely difficult if youmove much faster. However,at that speed it would take the player 20 minutesto achieve a low-planet orbit. To circumnavigatea small planet the size of the mooncould take as long as 16 hours.Although we were able to brainstorm severalfanciful solutions to this problem, most weretime- or cost-prohibitive, and all of our solutionsthreatened to shatter the illusion that youwere in a small fighter craft, engaged in small,intimate battles.Back to EarthSTAR WARS STARFIGHTER finally shipped in February2001. While it was a little bit later thanwe had initially hoped, we burned our first setof master disks in mid-January, within threedays of the “realistic” schedule projection thatDaron had made a year earlier. While it certainlyhas its flaws, STAR WARS STARFIGHTERrepresents the culmination of an effort thatinvolved almost 50 people, and it is a productthat we are all very proudof. The lessons leaned overthe last few years, both positiveand negative, arealready starting to be usedby other LucasArts teams,ensuring that the project’slegacy will be with us longafter the last copy of thegame has been sold.Screenshot featuring the userinterface created with MacromediaFlash.

This Page Intentionally Left BlankLucasArts’ STAR WARS STARFIGHTER 236

237Raven Software’sSTAR TREK:VOYAGER—ELITE FORCEby brian pelletier, michael gummelt, andjames monroeIn the summer of 1998, Activision had acquiredlicensing rights to make games using a numberof Star Trek franchises. Their goals from thebeginning were to create a broad selection ofgames and show the gaming community thatActivision could take the Star Trek brand andmake high-quality games with it, better thanother publishers had in the past. The preliminarygame slate was set with a first-personshooter as one of the initial titles. Raven Softwarehad been an external studio of Activisionfor a year, finishing up work on HERETIC 2 anddiving deep into the development of SOLDIER OFFORTUNE.HERETIC 2 was near completion, and we wouldsoon need another project to work on. With ourexperience developing shooters and a reputationfor making quality games, Activision handed theStar Trek first-person shooter project to us.The game started out being based on anunknown Star Trek crew within the Next Generationfranchise. For two months work wasBack-StoryVOYAGER—ELITE FORCE faces special challenges, adaptinga traditionally combat-heavy form (first-personshooters) to a license that privileged conversation andcharacter over action. They solved this issue by lettingplayers take command of a special-forces style unitselected from a traditional Starfleet crew. These aren'tthe only challenges—Raven also faced the problems ofconvincingly portraying characters and settings familiarto most players and giving players intelligent-seemingcrew to accompany them on their missions. The resultinggame is an interesting fusion of the first-personshooter into the familiar format and rhythm of a StarTrek episode.done on the plot and story line, with a test levelof a Defiant-class ship made using the QUAKE 2engine. The main factor in designing the plot ofthe game was that it had to be an action game,despite the fact that Star Trek isn’t known foraction. To give meaning to the action, the ideafor a Special Forces team soon emerged to drivethe action for the game.Ultimately, because Activision already had twoother games using the Next Generation license,the setting for our game changed to the Voyager

Raven Software’s STAR TREK: VOYAGER—ELITE FORCE 238franchise. Our excitement level was low at first,with the team feeling that Voyager was the leastpopular of all the Star Trek franchises. We soonrealized that Voyager’s plot allowed us not onlyto make our game with much more creativefreedom, but also to create from something noone else had used.This inspired us to open the floodgates, continueon, and eventually realize that Voyager was thebest setting for what we wanted to do. Wequickly adapted the plot we had at that pointinto the Voyager setting. This was much easierthan we thought it would be, and the EliteForce, or the Hazard Team, as we called them,actually seemed to make more sense as a byproductof Voyager’s situation.Game DataRelease date: September 20, 2000Genre: first-person shooter in science fiction settingPublisher: ActivisionIntended platforms: Windows 95/98/NT/2000,Macintosh, Linux, Playstation 2Number of full-time developers: 20Number of contractors: 13Length of development: six months of preproduction,18 months of productionProject size: Single-player and Holomatch: 919,749lines of code; 1,679 files. The single-player game waslargely controlled by scripting, totaling 112,056 linesof code and 2,236 files.Project budget: Multimillion-dollar budgetCritical development hardware: Average system:Dell Pentium II 550 with 128MB RAM, 18GB harddrive, GeForce 3D acceleration card, and 21-inchmonitor.Critical development software: Microsoft Visual C++6.0, Microsoft Visual SourceSafe 6.0, Borland JBuilder3.5, 3D Studio Max 2, Softimage 3D, Photoshop.Notable technologies: Licensed the QUAKE 3:ARENA engine from id Software (using OpenGL);Icarus scripting system, BehaveEd scripting tool,Carcass skeletal system, Bink, and motion-capturedata from House of Moves.In January 1999, full production on ELITEFORCE began with a small team of 15 peoplethat would grow to about 25 core team members,with additional support from the SOLDIEROF FORTUNE team. Our main focus during productionwas not to think about the game as aStar Trek product per se, but rather an actionshooter that borrowed from the Star Trek universe.This helped us focus more on what wouldbe fun for players.To our surprise, the Paramount approval processwas much easier than we anticipated. Wehad heard many horror stories regarding Paramount’sstrictness with their licenses, things like,“You can’t do anything new,” and, “It’s hard toget things approved because they’re so protectiveof the license.” What we experienced wasthe exact opposite. Paramount was more thanaccommodating in helping us create a fun game,and we were able to bend the rules a little alongthe way to help accomplish our goal. We creatednew Starfleet weapons, a Voyager SWAT team,used the Klingons, and even added “classic”Star Trek to the Voyager setting. As long as anelement made sense to the story and its presencecould be explained, it was no problem.

239SECTION IV: BUILDING ON A LICENSE239One of the biggest obstacles we had to overcomewas that we would be making an actiongame that had to appeal to both the hardcoreFPS player as well as the average Star Trekgamer and fan. This was no easy task, and wespent a lot of time debating over the game stylebeing too much of an action game or more of aStar Trek game. Balancing these two aims was aconstant battle during the course of production.We knew we had to walk a fine line blending ashooter and a Star Trek experience if we weregoing to both make a successful game and overcomepeople’s perceptions that Star Trek gamesare not good games.What Went Right1. Improvements to the QUAKE 3engineRaven had worked with id Software’s enginessince 1992, but this was the first time we had toadd a single-player game to an id engine. Normally,we had the luxury of starting with a fullsingle-player code base and just adding thingssuch as breakable brushes, new AI, navigationsystems, and so on. But this time we hadlicensed a multiplayer game and had to put inmany systems we took for granted. We neededAI and navigation appropriate for single-playerenemies (not multiplayer bots), as well as teammatenon-player characters (NPCs) and cinematics.We needed an expanded animationsystem for all the different animations our cinematicswould require, we needed to create aload and save routine from scratch, and the listwent on.One of the things that made this possible wasthe decision early on to separate the multiplayerand single-player executables. At this time,QUAKE 3 was still about eight months fromcompletion, so we started on single-player andwould worry about multiplayer when we gotthe final code base. We were able to make drasticchanges to the single-player game and shortcutthe networking, allowing us to get awaywith a lot of things that would have just donevery bad things to networking. With this newfreedom, we revamped even more systems. Inthe end, we actually surpassed our initial ambitionsas far as new systems and features wereconcerned.For example, our Icarus scripting system wasplanned from the beginning and ended up workingout very well. The initial setup was finishedrelatively quickly and the remainder of the workwas mostly just tying the commands to the gameand AI. However, for the first seven or eightmonths, only a couple of programmers weredoing any scripting, as they were still refiningthe commands and there was no GUI for it yet.It wasn’t until the fall of 1999 that we made aGUI and the designers could finally start scripting.The system ended up contributing a hugeamount to the detail, uniqueness, and complexityof the game, and without it ELITE FORCEwould have been a totally different game.Another big technology decision we had tomake was with Carcass, our new skeletal modelformat. It was a huge undertaking to switch

Raven Software’s STAR TREK: VOYAGER—ELITE FORCE 240over to the new format, but it really saved us inthe end. At first we were using the same modelformat as QUAKE 3, but it quickly becameapparent that we were surpassing that format’scapabilities, so we looked for a solution. id hadalready laid the groundwork for a skeletalmodel, which seemed like it would work for us.Starting with that basis, we completed it anddeveloped it into the final format we called Carcass.With it, we reduced tenfold the amount ofmemory a single model took up. Without theCarcass format, we would have had to cut backmany animations, and we would have lost thecomplex detail in our cinematics.Another technology that was successful was ourlip-synch system, which really added realism tothe facial animations. We did some research,looking into phoneme recognition, but finallysettled on a quick volume analysis. We plannedthis system to make it very easy to use. Once themouth animation art was made for each character,the system used the appropriate frame withoutintervention. The code automaticallyscanned for peak volume of sounds whenloaded, and compared against that whenever asound was played on the voice channel. Thenthe animation system picked up that value tochoose the speaking frame. This setup requiredno extra effort when adding sounds, and wouldwork automatically for any foreign languagesused.Another system we revamped was the cinematicsystem, which had to be powerful and flexibleenough to give our cinematics that Star Trek“feel.” The camera system itself wasn’t thathard to implement, and it worked out well.First, the scripter/designer would set up theblocking of the NPCs through Icarus. Then theycould go into the game and let the scripted eventplay out, pausing it whenever they wanted tosave a camera position to a file that could beimported into the map.Menu screen for choosing your player character inHolomatch gameplay.Using Icarus commands, they could make thecamera zoom in and out, change the field ofview to simulate close-ups and wide shots, movealong a track, dynamically follow a subject, fadein and out, shake, and so on. This allowed us toset up our insane amount of cinematics asquickly as possible and still allow for some finetuningand detail (such as the “walk and talk”with Tuvok and Munro, and especially all thegestures and expressions the NPCs themselveswould do to add to their characterization andthe believability of a scene).

241SECTION IV: BUILDING ON A LICENSE241the feeling that they were partaking inan episode of the show.Since one of our main goals was tohave an away-team accompany theplayer for the missions, it was evenmore important that the story be solidifiedup front. A lot of story is conveyedduring the missions, so we had to makesure the levels were paced out well andthe level designers knew up front whatstory content their levels contained. Wewere able to pace the story throughoutthe game so that players would be continuallyrewarded with exposition. Asthey completed more missions, theoverarching plot of the game wouldslowly form in their minds.Storyboards were created as guides for the in-gamecinematics, helping to speed up production of more than 50cinematic sequences.2. Complete plot and story rightfrom the startFrom the beginning of production, ELITE FORCEhad a detailed story line, and every level of thegame was written out in story form. We alsohad standards we had to meet; after all, ourgame was going to be compared to the VoyagerTV show, so there was even more emphasis onstorytelling. The story had to be engaging andreminiscent of what a Voyager episode wouldbe, and we had to make sure our story had a lotof depth and interest for the player, to give themWith our tight schedule, we wouldn’thave time to redo parts of the game ifthey didn’t work out, so it was crucialfor all the people involved to worktogether on the story line toward onecommon goal. With a complete walkthroughof the levels written, the level designerscould concentrate on the looks of the level andaccommodate for where the cinematics andstory segments were going to take place.Because our story line never changed duringproduction, we were able to proceed forwarduninterrupted, and never had to scrap any levelsdue to plot restructure. This was key, as we hada fairly small team charged with creating a lot ofcontent in a short period of time. The majorityof the dialogue was written after all the levelswere finished, but this too went smoothly

Raven Software’s STAR TREK: VOYAGER—ELITE FORCE 242because the walkthroughs were updated fromthe finalized levels, and then the dialogue waswritten from them.3. The dialogueThe team was excited about the concept of playingwith a team of NPCs in an FPS. This led tothe definition of the different characters of theHazard Team early on. However, the actualscript for the game didn’t begin right away, sincethat had to wait for the final game flow designto be finished. Our writer (also one of our programmers)started in September 1999 and finishedthe first draft inMarch 2000. While he waswriting the script, we weremaking all the cinematicsand needed some temporaryvoices. We hademployees record the linesand then dropped them intothe cinematics to give us afeel for the pacing of eachscene. This allowed us totweak the dialogue whilesaving us from having tobring the expensive Voyagercast back for pickup lines.The script finally came together after many revisionsand, once it was approved by Paramount,the actors were lined up very quickly and thevoice recording was done in about a month. Wewere then able to put the final lines into eachscene, replacing our temporary dialogue withouthaving to adjust the timing or change thescripts. This was due to the fact that IcarusThe Voyager 3D model used inprerendered cinematics is the actualone used for the TV show.could pause execution of a script until a soundfile finished playing, so dropping in a new line ofdialogue automatically adjusted the timing ofeach scene. This also meant that lines wouldgenerally flow better in translation, since theywouldn’t have to deliver the line too quickly orslowly to match any hard-coded timing.We also had a system for automatically readingthe dialogue script itself and turning it into .PREfiles that would let the game precache all thedialogue for a level and simultaneously assignthe caption text to it. Included in this was automaticlocalization and dialogue adjustment forthe player’s gender.All of these things togetherenabled our game to havecaptioning, localization,gender-specific dialogue,precaching, lip-synching,and almost no pickups. Inthe end, the dialogue turnedout very well and our performanceswere good (Paramounteven let us makefinal casting decisions on allthe ELITE FORCE–specificcharacters). The story and dialogue added agreat deal to the game and contributed heavilyto the feeling of actually being in an episode ofStar Trek.4. Re-creating the look of theStar Trek universeRaven has always tried to push graphics boundariesand painstakingly create beautiful settings

243SECTION IV: BUILDING ON A LICENSE243with ease. Once the scale of the levels was set asa standard, we continued forward with theother Voyager rooms with little rework needed.It was important to make highly detailed sketches,since another company was making the models fromthem.for our game worlds. STAR TREK was no exception,and challenged us not only to create abeautiful gaming environment but also to createit in a likeness that is known worldwide. It’s onething to make arbitrary-looking levels in anever-before-seen world, but when trying to recreatethe look of Voyager we came across manydifficulties that we hadn’t expected. For starters,the QUAKE 3 level editor is made to create levelsat a fairly big scale. When we built the bridge ofVoyager, we were all astounded by the detailthat we achieved, but when we put a normalsizedcharacter on the bridge, he was incrediblytiny. The bridge was huge, yet it was built likeyou would build any normal QUAKE 3 level. Werealized that we had to build the levels on amuch smaller scale than what we were used to.It took seven attempts at rebuilding Voyager’sbridge until we attained the proper proportionsbetween the characters and the level. Wetweaked the scale until it looked perfect and theplayer and other characters could move aroundThe artists spent much time working on the texturesfor the environments, getting their referencefrom many sources to make sureeverything was exact. Having access to Paramount’sStar Trek reference library was key ingetting reference for carpets, chairs, upholstery,computer panels, and more. We sometimesscanned in the photo references themselves forthe textures. Watching episodes of the show ontape was also instrumental in determining whatthings looked like. We used a total of 1,033 texturesto create the look of Voyager’s rooms andhallways. Working together, the level designersand artists created the best-looking Star Trekenvironments in any game to date.Just like the challenges we faced building theenvironments, creating Voyager’s characters andcrew presented the challenge of re-creatingsomething that already existed. We used manyreferences from the Star Trek reference libraryto help us re-create these real people. Each actorhad a series of photos of him or her as theircharacter, which we used to help get just theright shape of the head, and we even used thephotos themselves (with Photoshop touchups)as textures on the polygon heads to achieve thelikenesses.There are limitations to any technology, andworking around the limitations is where we succeeded.The heads could only have 150 polygonalfaces and the textures for the skins couldonly be 512×512 pixels. The fine craftsmanship

Raven Software’s STAR TREK: VOYAGER—ELITE FORCE 244required to work with so little and still achievethe right look for the characters is a testamentto our artists’ skills. For example, designing theHazard Suit in the Voyager style took manyattempts, but we finally got something everyonewas happy with and looked natural to StarTrek.5. Creating smart NPCsTo create a Voyager game that resembles whatyou would see in a TV episode, we had to createa working spaceship filled with its busy crew,and make it believable enough so players wouldfeel like they are in a real place. We also had tocreate an away-team to fight alongside theplayer. After all, what is Star Trek without anaway-team?Voyager’s Hazard Team, created by Raven to helpaccentuate the action for the game.We created our NPCs using a few differentthings. The Icarus scripting system allowed us tohave precise control over specific actions. TheNPC Stats system allowed us to create manycharacters with various looks. The Squadmatesystem gave us the tools to enable the teammatesto work with the player, and we used awaypoint or pathfinding system to make ourNPCs navigate through a complex environment.All of these systems together created the artificialintelligence for our NPCs.We used scripting with the pathfinding to makethe crew of Voyager come to life, and we couldtell them exactly where to go and what to dowithout too many unknowns to cause problems.They did exactly what we as designers wantedthem to do. The teammates, on the other hand,have to act according to what is happening withthe player. Since players can do anything theywant while playing the game, this means a lot ofunknowns for how the teammates should react.The teammates could have easily been a hindranceto the gameplay, and now we know whyno other company has ever tried to make an FPSgame with up to five teammates working alongsideyou throughout entire levels.In the final stages of developing the teammates,we weren’t sure if they were going to work out;they had so many problems, and every time wewould fix something another problem wouldcrop up. Just getting them to follow you was noeasy task and was something we kept tweakingright up to the final days. Sure, we could getthem to follow the player, but the game tookplace in tight hallways and small rooms so playerswould bump into them. They wouldn’t getout of the way and would constantly get stuckon each other.

245SECTION IV: BUILDING ON A LICENSE245Also, having them follow the player everywheremade them seem less like intelligent characters,so sometimes we had them stand their groundor take up a position while the player wentexploring. Then we had the constant problem ofthe team not following players at all, eventhough they might need them later on. When wedid get it working, someone found a new way tobreak a level with a teammate. Elevators andteleporters added to the risk of teammates beingleft behind. We were getting worried that wewouldn’t even be able to get them to walkthrough an entire level, and we would have toresort to something drastic. Luckily, we did getthem to work in the levels. They may have runfunny or jumped down long elevator shafts tocatch up with the player, but at least they stayedin formation through the whole level no matterwhat the player was doing.enemies, turning the gameplay into “shoot thealiens attacking your teammates.” Eventuallywe made the enemies attack the player more, sothe player would feel threatened by them, andthe teammates helped but didn’t do all thework.It’s funny now to hear people say that the teammateswere stupid because they hardly killedany enemies, or that the enemies were dumbbecause they attacked the player more than theteammates. If they only knew how tiresome thegameplay would have been had we not balancedit the way we did.What Went WrongOf course, once there were enemies we had toworry about friendly fire. We wanted the teamto react intelligently to being shot, but we didn’twant to punish the player for shooting themaccidentally. After a lot of trial and error, wedecided that teammates would retaliate againsta player only if the player had shot them repeatedlyoutside combat. In combat, they’d stillreact to friendly fire, but couldn’t be killed, andwould never turn on the player.Then came the problem of trying to balance theteammates’ involvement in combat. Once weput enemies in the levels, we found that theteammates were so good that they killed most ofthem, leaving little for the player to do. To balancethis, we had the teammates shoot lessoften, but then they got attacked constantly bySave your teammate from the Borg, one of themany multiple outcome events.1. Not enough programmersFor the first half of development, there wasmainly only one programmer working on scripting,enemy AI, teammate AI, pathfinding, andthe animation system. This programmer wasalso writing all the dialogue, and it became necessaryfor him to relinquish other programming

Raven Software’s STAR TREK: VOYAGER—ELITE FORCE 246duties in order to finish writing. Unfortunately,we didn’t have any extra programmers to help.Eventually we got a programmer from a differentproject to start working on game code. Hecompletely rewrote the navigation system,which took time away from creating the AI forall the enemies, which didn’t end up being completeduntil the game itself was done. This createda real lack of cooperation between leveldesign and enemy AI, and forced the designersto rewrite their scriptsconstantly to matchthe changes in theunderlying game systems.With more programmersworking on AIand navigation earlyon in the development,these kinds oflast-minute changesand back-end designcould have (hopefully)been avoided.2. From Ghoul models to regularmodels to skeletal modelsIt was a big decision to switch to the new skeletalmodels. In the beginning, we were usingwhat was to become SOLDIER OF FORTUNE’sGhoul system (see “Raven Software’s SOLDIEROF FORTUNE,” Postmortem on page 259, formore on Ghoul). When we received theQUAKE 3 code, we tried to integrate Ghoul intothe new code, but found it to be too different. ItOther models were designed by Raven and madeby the company making the prerendered movies.just didn’t fit in with the new optimized renderingpipeline QUAKE 3 provided. So we switchedover to regular QUAKE 3 models.There was a lot of learning going on at this time.When we get new code, it doesn’t come withoperating instructions, and it’s often not complete.We went through a lot of growing painsadopting the new format and figuring out itsrequirements. When the option to go skeletalcame up, we had to weigh the benefits of thenew system versusthe risks and timeit would take toswitch over. Whilewe did the rightthing andembraced the newtechnology, we hadto write a new setof tools to handlethe new formatsand learn new proceduresto get ouranimations out ofSoftimage 3D andinto 3D StudioMax. We had a lot of squashed creatures andbizarrely stretched limbs along the way, but itwas well worth the trip.Unfortunately, by the time we got it workingright, we were past our alpha date, and becauseof all the different changes the models had gonethrough by that time, we didn’t have enoughtime to fully implement a good AI system for theenemies, and had to settle with what we coulddo in the time we had.

247SECTION IV: BUILDING ON A LICENSE2473. Underestimating the amountof scripting work neededAs we mentioned previously, our Icarus scriptingsystem was a huge plus. But we also encountereda lot of problems with scripting. Not onlyhad no one ever used this system before, none ofthe programmers behind it had ever written ascripting system before. The designers didn’teven get their hands on the scripting systemuntil about eight monthsbefore the game wasdone. They did pick it upquickly, but not withouta lot of effort and timeinvolved.One of the major problemsdesigners had whenscripting was the constantchanges to theunderlying systems thatthe Icarus commandsrelied upon. They’dscript an NPC one wayand it would work fine. Then the followingweek, something in the navigation, AI, or animationsystems would change, and the scriptwould be broken. This was a source of majorfrustration among the designers and definitelyimpeded their productivity. Ideally, those systemswould have been finalized before thedesigners had to start scripting.The Klingons’ AI allowed them to crouchand run for cover.Within Icarus itself, there was one major flawthat should be addressed. Icarus can start acommand and wait for completion, but it doesnot have a built-in system for letting the command(or “task”) time-out and continue or takeanother route. There was no failsafe if, somehow,a command never completed. Given thesheer complexity of our scripting, these kinds ofshowstopper problems showed up constantlyand would completely stop the game in itstracks. Up until the last minute, we were franticallytrying to find every case in which a scriptwould just stop execution. In the end, we didmanage to catch them all, except for two casesthat were caused by peopleturning their detaillevels up too high andcausing the game to dropto very low framerates,which could in turn messup the scripted events.It turned out pretty wellin the end, but all theeffort that went into constantlyrevising thescripts could have beenput to other, more productiveuses.4. Adjusting to new QUAKE 3technologyThe biggest level design headache in workingwith technology that is still being developed isthat it’s constantly changing. We started buildingour levels way before the QUAKE 3 enginewas near completion, and this caused schedulingproblems every time we got a new code build.We built our levels one way with the tools andknowledge we had at the time, and then when abig change was made to the QUAKE 3 code, the

Raven Software’s STAR TREK: VOYAGER—ELITE FORCE 248level designers had to spend a few days alteringeach of their levels to keep up with the changesin the code and how it handled surfaces, lights,and architecture.This happened numerous times during development,and we often went months without newcode drops. The level designers would continueto work on levels in order tomake progress, and thenwhen we finally receivednew code, we had to go backto all the levels that hadbeen done and spend amonth getting them up todate. This month was notaccounted for in the schedule,and therefore a monthof designer time was simplylost. This happened morethan once and was a big factorin keeping us behind ouroriginal schedule.Another part of adjusting to the QUAKE 3 technologywas realizing that our levels couldn’t beas big as QUAKE 2 levels. When we startedbuilding levels, we made them as we did usingQUAKE 1 and 2 technology. We had expansivelevels that looked awesome and showed offwhat the QUAKE 3 engine could do. Then, somewherenear the middle of our development, werealized that the file size of most of our levelswas huge, running 11 to 15MB each, when theyshould have been about 6MB. This was a problem,since we’d planned for the file sizes to be10MB or less out of a total memory budget ofFighting aliens in the stasis ship,which was created with 90 percentcurved surfaces.64MB. The levels were the normal game-worldsize of a QUAKE 2 level, so what was the problem?It turned out to be the high polygon (or triangle)count used to create a much more intricate anddetailed environment. We realized that althoughQUAKE 3 can handle more polygons in the viewat one time, the file size forthe level had not increasedmuch from a QUAKE 2 level.We had a dilemma; eitherwe could bring the file sizedown by taking out all ofthe detail that made theQUAKE 3 engine superiorand keep the physical size,or we could cut the size ofthe level down, making itsmaller yet highly detailed.Since we were making aworld that could readily becompared to a TV show, we opted to keep thedetailed environments of the Star Trek universeand cut the level size down.We were able to cut most of the levels in halfand make two separate levels out of them, butthen all the level designers had twice as manylevels to work on, and this could have causedsome major scheduling problems. Unfortunately,to keep up with the schedule, large partsof the levels were deleted and redesigned, whichresulted in much smaller levels that could be traversedquicker, and ultimately made for ashorter game.

249SECTION IV: BUILDING ON A LICENSE2495. Mission stats never gotfinishedThe only major thing that didn’t get into thegame that we originally planned for was ourend-mission statistics. The feature made it intothe game in the form of basic stats when youdied, but it was planned to be much more, andwould have really added to the game. The endmissionstats would have improved the replayabilityof the single-player game and given moreemphasis to the interactive and multiple-outcomeevents.The main goal with the stats was to grade players’performance when they completed a mission;for example, giving a score of 100 percentfor a perfect mission. A number of medalswould also be awarded to players based onwhat they did during the mission. At the end ofthe game, all the scores and medals would beadded up for one final game score. The statswould have made a significant gameplay feature,letting players know at the end of a missionwhether they could have saved someone ordone something differently to get a better score.This would have made the interactive eventsmean something more, emphasizing the fact thatthey are interactive; events that players didn’teven know could be changed would have beenpresented to them after the mission, making thegame world seem that much more alive. Withthis feature not in the game, the multiple outcomeevents didn’t mean anything more thanjust a “cool” factor, instead of being intrinsic tothe gameplay and adding to replayability.Final ThoughtsWe started out with a lot of great ideas, andalmost all of those ideas were implemented inthe game with the exception of a couple. That’scertainly an achievement in this industry. Wemade the game we set out to make and are veryhappy with the end result, so it was hard tothink of the things that went wrong. Eventhough we had many problems, we workedaround them and ultimately finished the game,which makes us feel like we did everything right.Then we heard comments from fans and gamereviewers who didn’t like certain things aboutthe game, and all the memories of workingthrough all the obstacles came back, and wethought, “If they only knew how many problemswe had to work through to get the game toits final state.” It’s working through those developmentobstacles that makes a game successful.It’s also gratifying to hear from fans and reviewersthat the game was successful both as a fungame and as a Star Trek game. For us, thatmeans many more things went right thanwrong, and the team was talented enough towork through the things that went wrong andmake a game that is being enjoyed by thousandsof people.ELITE FORCE was a very difficult project cyclewith a really long crunch mode, but what gameis any different? Yet we had a lot of extra obstaclesto overcome, including the perception thatall Star Trek games suck and that meant ourswould too. It seemed like we were destined tofail before we even started. Working with one ofthe two biggest science-fiction franchises in the

Raven Software’s STAR TREK: VOYAGER—ELITE FORCE 250world added to the pressure. But Activision supportedus all the way from upper managementto a top-notch marketing and PR staff. Paramountwas surprisingly helpful and proved to usthat they care about the quality of the gamesmade and would do everything possible toensure that quality. With a dedicated and verytalented team of individuals, we met our challengesand succeeded in making what is beingcalled the best Star Trek game ever made.

251Red Storm Entertainment’sRAINBOW SIXby brian uptonRAINBOW SIX and Red Storm Entertainmentboth came into being during the same week.When the company was formed in the fall of1996, the first thing that we did was to spend aweekend brainstorming game ideas. That initialdesign session generated over a hundred possibilitiesthat we then winnowed down to a handfulthat we thought had star potential. The onlyone that we unanimously agreed we had tobuild was HRT—a game based on the FBI’sHostage Rescue Team.The ConceptIt was a long road from HRT to RAINBOW SIX,but along the way, the basic outline of the titlechanged very little. We knew from the start thatwe wanted to capture the excitement of moviessuch as Mission: Impossible and The DirtyDozen—the thrill of watching a team of skilledspecialists pull off an operation with clockworkprecision. We also knew that we wanted it to bean action game with a strong strategic component—arealistic shooter that would be fun toplay even without a QUAKE player’s twitchreflexes. From that starting point, the titleseemed to design itself.Back-StoryIn RAINBOW SIX, players lead a multinational team ofmilitary operatives who intervene in sensitive crises inthe post-Cold War world. The game has both tactical andaction elements. Players go into battle, but they alsomanage their squad, choosing equipment and creating atactical battle plan before going into action. The gamehas a real-world feel—one shot can kill, and small mistakescan doom an entire mission. Typical missionsinvolve rescuing hostages and assassinating terroristsand criminals, and over time, the missions cohere into aTom Clancy-style plot arc that takes players all over theglobe.By the time we’d finished the first treatment afew weeks later, all the central game-play featureswere in place. We expanded the scope ofthe game (rechristened BLACK OPS) beyond hostagerescue to encompass a variety of covertmissions. Play would revolve around a planningphase followed by an action phase, and playerswould have to pick their teams from a pool ofoperatives with different strengths and weaknesses.Combat would be quick and deadly, butrealistic. One shot would kill, but the targetingmodel would favor cautious aiming over therunning-and-gunning that was typical of firstpersonshooters.

Red Storm Entertainment’s RAINBOW SIX 252Ironically, the only major element that wehadn’t developed during those first few weekswas the tie-in to Tom Clancy’s book. Clancywas part of the original brainstorming sessionand had responded as enthusiastically as the restof us to the HRT concept, but he hadn’t yetdecided to make it the subject of his next novel.Game DataRelease date: August 1998Publisher: Ubi SoftGenre: tactical team-based shooterIntended platform: Windows 95/98Team size: 16 full-time and 6 part-time developersCritical development hardware: 400MHz Pentium IIw/64MB RAM and a 3D acceleratorCritical development software: Microsoft VisualC++, SourceSafe, Hiprof, Boundschecker, and 3DStudio Max.Because we had moved away from doing a stricthostage rescue game, we batted around a lot ofdifferent BLACK OPS back stories in our designmeetings, ranging in time from the World War IIera to the near future. For a while, we consideredsetting the game in the 1960s at the heightof the Cold War, giving it a very Austin Powers/Avengersfeel.We eventually converged on the RAINBOW SIXback story in early 1997, but we didn’t find outthat we would be paralleling Clancy’s noveluntil almost April. Fortunately, we’d been sharinginformation back and forth the whole time,so bringing the game in line with the bookdidn’t involve too much extra work. (If youcompare the game to the novel, however, you’llnotice that they have different endings. Due toscheduling constraints, we had to lock down thefinal missions several months before Clancy finishedwriting. One of the pitfalls of paralleldevelopment…).The ProductionOriginally, the RAINBOW SIX team consisted ofme and one other programmer. Red Stormstarted development on four titles straight outof the gate, and all the teams were woefullyunderstaffed for the first few months. The firstRAINBOW SIX artist didn’t come on board untilthe spring of 1997, with a full-time producerfollowing shortly after. With such a small group,progress was slow. During that first winter andspring, all that we had time to do was throwtogether a rough framework for what was tofollow. This lack of resources up front wouldcome back to haunt us later. Because we were sounderstaffed, we tried to fill the gaps in ourschedule by licensing several crucial pieces oftechnology.The first was the 3D renderer itself. VirtusCorp., our parent company, was working on anext-generation rendering library for use in itsown line of 3D tools. We decided to save ourselveswork by building on top of the Virtus renderer,rather than developing our own. At first,this seemed to be an ideal solution to our problem.Virtus had been doing 3D applications foryears, and the renderer that its engineers wereworking on was a very general cross-platformsolution that ran well with lots of different typesof hardware acceleration.

253SECTION IV: BUILDING ON A LICENSE253We also went out of house for our networkingtechnology. We had researched a variety ofthird-party solutions, including Microsoft’sDirectPlay, but we weren’t satisfied with any ofthem. Just as we were on the verge of decidingthat we’d have to write our own library, a localdevelopment group within IBM contacted us.A 2D floor plan, created for the purpose of collision detection, also helpedplayers in both the planning and action interfaces.The group’s engineers were interested in findinguses for their powerful new Java-based client/servertechnology. The technology, calledInverse, was designed to allow collaborativecomputing between large numbers of Javaapplets. The IBM engineers wanted to see how itwould perform in a number of different applicationdomains, including games. Inverse supportedall of the features that we wanted in anetworking solution, such as network time synchronizationand reliable detection of disconnects,so after much deliberation we decided touse it for RAINBOW SIX. Eventually, we wouldcome to regret both of these third-party technologydecisions, but not until months later in theproject.Over the summer of 1997, we acquired most ofthe motion capture data that was used for animatingthe characters in the game. One of theadvantages of working with Tom Clancy wasthat he put us in touch with a wide variety ofconsultants very quickly. Among the manyexperts we spoke with to get background informationon counter-terrorism were two closequarterscombat trainers who worked for thearms manufacturer Heckler and Koch. When itcame time to do our motion capture, these trainersvolunteered to be our actors. They spent acouple of days at theBiovision studios inCalifornia being videotapedrunning throughevery motion in thegame. Using real combattrainers for ourmotion capture datarepresented one of ourbetter decisions. Whilea professional actor might have been tempted tooverdo the motions for effect, these guys playedit absolutely straight—the results are impressive.The game’s characters come across as seriousand competent, and are twice as scary as aresult.Our crisis came in October of 1997. We’d beenworking hard all summer, but (although werefused to admit it) we were slipping furtherand further behind in our schedule. Partially,the delays were the result of my being completelyoverloaded. Partially, they were theresult of the ambitious scale of the project:because the plot of Clancy’s evolving novel wasdriving our level design, we’d committed ourselvesto creating sixteen completely uniquespaces—a huge art load. And partially, theywere the result of the fact that the “time-saving”technology licenses that we’d set up wereproving to be anything but.

Red Storm Entertainment’s RAINBOW SIX 254Inverse was a great networking solution—forJava. Unfortunately, we wrote RAINBOW SIX inC++. Our initial research had suggested thatmixing the two would be trivial. However, inpractice the overhead involved in writing anddebugging an application using two differentlanguages at the same time was staggering. Theinterface code that tied the two parts togetherwas larger than the entire networking library. Itbecame clear that we’d have to scrap Inverseand write our own networking solution fromscratch if we were ever going to get the productout the door. (As a side note, we did continue touse Inverse for our Java-based products: lastyear’s POLITIKA and this year’s RUTH-LESS.COM. The problems we faced didn’t arisefrom the code itself, but from mixing the twodevelopment environments.)We also had problems with the Virtus renderinglibrary. As we got deeper and deeper into RAIN-BOW SIX, we realized that if the game was goingto run at an acceptable frame rate, we weregoing to have to implement a number of differentrenderer optimizations. Unfortunately, theVirtus renderer was a black box. It was designedto be a general-purpose solution for a wide varietyof situations—a Swiss Army knife. Withframe rates on high-end systems hovering in thesingle digits, we quickly realized that we wouldneed a special-purpose solution instead.In early November 1997, we put together a crisisplan. We pumped additional manpower intothe team. We brought in Erik Erikson, our topgraphics programmer, and Dave Weinstein, ourtop networking programmer, as troubleshooters.I stepped down as lead engineer and producerCarl Schnurr took over more of the gamedesign responsibilities. The original schedule,which called for the product to ship in thespring, was pushed back four months. The artistswent through several rounds of productionpipeline streamlining until they could finallyproduce levels fast enough to meet the new shipdate.Finally, we took immediate action to end ourreliance on third-party software. We wrote anentire networking library from scratch andswapped it with the ailing Java code. Virtus graciouslyhanded over the source code for the rendererand we totally overhauled it, pulling incode we’d been using on DOMINANT SPECIES,the other 3D title that Red Storm had inprogress at the time. All this took place over theholiday season. It was a very hectic two months.From that point on, our development effort wasa sprint to the finish line. The team was incrunch mode from February to July 1998. Avariety of crises punctuated the final months ofthe project. In March, I came back on board aslead engineer when Peter McMurry, who’d beenrunning development in my place since November1997, had to step down for health reasons.As we added more and more code, builds grewlonger and longer, finally reaching several hoursin length, much to the frustration of the overworkedengineers. The size of the executablestarted breaking all our tools, making profilingand bounds checking impossible. In order tomake our ship date, we had to cut deeply intoour testing time, raising the risk level evenhigher. On the upside though, the closer we gotto the end of the project, the more the excitementstarted to build. We showed a couple ofcautious early demos to the press in March

255SECTION IV: BUILDING ON A LICENSE2551998 and were thrilled by the positiveresponses. (At this point, we were so deep intothe product that we had no idea of what an outsiderwould think.)The real unveiling came at the 1998 E3 inAtlanta, Ga. Members of the development teamran the demos on the show floor—for most us,that was the longest stretch we’d had playingthe game before it shipped. Almost all of thefinal gameplay tweaks came out of what welearned over those three days.What Went Right1. A coherent visionThroughout all of the ups and downs in the productionprocess, RAINBOW SIX’s core game playnever changed. We established early on a visionof what the final game would be and we maintainedthat vision right through to the end. Ican’t overstate the importance of this consistency.Simply sticking to the original conceptsaw the team through some really rough parts ofthe development cycle.For one thing, this coherent vision meant thatwe were able to squeak by without adequatedesign documents. Many parts of the designwere never written down, but because the teamhad a good idea of where we were headed, wewere able to fill in many of the details on ourown. Even when we had to perform massiveengineering overhauls in the middle of theproject, a lot of the existing art and code wassalvageable. Our vision also did a lot formorale. Many times we wondered if we’d everfinish the project, but we never doubted that theresult would be great if we did. It’s a lot easier tojustify crunch hours when you believe in wherethe project is going.2. An efficient art pipelineThe art team tried out four or five different productionpipelines before they finally found onethat would produce the levels that we wanted inthe time that we had available. The problemwas that we wanted to have sixteen uniquespaces in the game—there would be almost notexture or geometry sharing from mission tomission. Furthermore, instead of creating ourown level-building tool, we built everythingusing 3D Studio Max. Thus, artists had morefreedom in the types of spaces that they couldcreate, but they didn’t have shortcuts to stampout generic parts such as corridors or stairwells—everythinghad to be modeled by hand.Eventually, the art team settled on a processdesigned to minimize the amount of wastedeffort. Before anyone did any modeling, an artistwould sketch out the entire level on paperand submit it for approval by both the producerand art lead. Then the modelers would buildand play test just the level’s geometry before itwas textured. Each artist had a second computeron his desk running a lightweight versionof the game engine so he could easily experimentwith how the level would run in the game.

Red Storm Entertainment’s RAINBOW SIX 2563. Tom Clancy’s visibilityA good license won’t help a bad game, but it cangive a good game the visibility it needs to be abreakout title. When we first approached membersof the gaming press with demos of RAIN-BOW SIX in the spring of 1998, they had noreason to take us seriously—we had no trackrecord, no star developers, and no hype (OK,not much hype…). We were showing a quirkytitle with a less-than-state-of-the-art renderingengine in a very competitive genre. With muchanticipatedheavyweights such as SIN, HALF-LIFEand DAIKATANA on the way, having Clancy’sname on the box was crucial to getting peoplecode through a profiler, we figured that most ofour time was going to collision checks—checksfor characters colliding with the world and lineof-sightchecks for the AI’s visibility routines.The problem was that every time the physicsengine was asked to check for a collision, it calculateda very general 3D solution. Except inthe cases of grenade bounces and bullet tracks,a 3D collision check was complete overkill.Over the next month, we reworked the engineto do most of its collision detection in 2D usinga floor plan of the level. These collision floorplans would be generated algorithmically fromthe 3D level models.The various mission levels called for the creation of sixteen completely uniquespaces.to take a first look at the title. Fortunately, thegame play was compelling enough to turn thosefirst looks into a groundswell of good press thatcarried us through to the launch.4. Reworking the physicsengineIn February 1998, we completely overhauled theRAINBOW SIX physics engine, which turned outto be a win on a variety of fronts. We’d retooledthe renderer during the previous month, but ourframe rate was still dragging. After running theThe technique worked.In addition to gettingthe frame rate back upto a playable level, italso made collisiondetection more reliable.The game enginealso used the floorplans to drive the pathfindingroutines for the AI team members. Playerswould view these same floor plans as levelmaps in both the planning and action interfaces.By figuring out how to fix our low frame rates,we wound up with solutions to three or fourother major outstanding engineering issues.Sometimes, the right thing to do is just throwpart of the code out and start over.5. Team cohesionRed Storm employs no rock stars and no slackers.Everyone on the RAINBOW SIX team worked

257SECTION IV: BUILDING ON A LICENSE257incredibly long hours under a tremendousamount of pressure, but managed (mostly) tokeep their tempers and their professional focus.What Went Wrong1. Lack of up-front designWe never had a proper design document, whichmeant that we generated a lot of code and artthat we later had to scrap. What’s worse,because we didn’t have a detailed outline ofwhat we were trying to build, we had no way tomeasure our progress (or lack thereof) accurately.We only realized that we were in troublewhen it became glaringly obvious. If we’d beenabout the design rigorous up front, we wouldhave known that we were slipping much sooner.2. Understaffing at the startThis point is closely related to the previouspoint. Because we didn’t have a firm design, itwas impossible to do accurate time estimates.Red Storm was starved for manpower across theboard, and because we didn’t have a properschedule, it was hard to come to grips with justhow deep a hole we were digging for ourselves.There were always plenty of other things to doin getting a new company off the ground besidesrecruiting, and we were trying to run as lean aspossible to make the most of our limited startupcapital. Given the circumstances, it was easyto rationalize understaffing the project anddelaying new hires.Additionally, I badly overestimated my ownabilities. For Red Storm’s first year, I was workingfour jobs: VP of engineering, lead engineeron RAINBOW SIX, designer on RAINBOW SIX,and programmer. Any one of these could havebeen a full-time position. In trying to cover allfour, I spent all my time racing from one crisis tothe next instead of actually getting real workdone. And because I was acting as my own manager,there was no one to audit my performance.If one of the other leads was shirking his schedulingduties or blowing his milestones, I’d callhim on it. But on my own project, I couldalways explain away what should have beenclear warning signs of trouble.3. Reliance on unproventechnologyOur external solutions for rendering and networkingboth fell through and had to bereplaced with internally developed code late inthe development cycle. In both cases, we wererelying on software that was still under development.The core technology was sound, but wewere plagued with inadequate documentation,changing programming interfaces, misunderstoodperformance requirements, and heavyintegration costs.Because both packages were in flux, we failed todo a thorough evaluation of their limitationsand capabilities. By the time it became obviousthat neither was completely suited to our needs,it was too late to push for changes. In retrospect,we would have saved money and had amuch smoother development process if we’d bit-

Red Storm Entertainment’s RAINBOW SIX 258ten the bullet early on and committed ourselvesto building our own technology base.4. Loss of key personnelLosing even a junior member of a developmentteam close to gold master can be devastating.When our lead engineer took ill in February1998, we were faced with a serious crisis. For afew frantic weeks, we tried to recruit a lead fromoutside the company, but eventually it becameobvious that there was no way we could bringsomeone in and get them up to speed in time forus to make our ship date in July 1998. Promotingfrom inside the team wasn’t a possibilityeither—everyone’s schedule was so tightly packedthat they were already pulling overtime just to gettheir coding tasks done; no one had the bandwidthto handle lead responsibilities too.Ultimately, I wound up stepping back in as lead.This time, however, we knew that for thisarrangement to work I’d have to let my VPduties slide. The rest of management and theother senior engineers took up a lot of the slack,and Peter had set a strong direction for theproject, so the transition went very smoothly.(After his health improved Peter returned towork at the end of the project, putting inreduced hours to finish off the RAINBOW SIXsound code.)5. Insufficient testing timeWe got lucky. As a result of our early missteps,the only way we could get the game done ontime was to cut deeply into our testing schedule.We were still finding new crash bugs a weekbefore gold master; if any of these had requiredmajor reengineering to fix, we would have beenin deep trouble. That the game shipped as cleanas it did is a testament to the incredible effortput in at the end by the engineering team. As itwas, we still had to release several patches toclean up stuff that slipped through the cracks.In the End…RAINBOW SIX’s development cycle was a 21-month roller coaster ride. The project was tooambitious from the start, particularly with theundersized, inexperienced team with which webegan. We survived major overhauls of thegraphics, networking, and simulation softwarelate in the development cycle, as well as twochanges of engineering leads within six months.By all rights, the final product should have beena buggy, unplayable mess. The reason it’s not isthat lots of very talented people put in lots ofhard work. I’m not going to say that RAINBOWSIX is the perfect game, but it is almost exactlythe game that we originally set out to make backin 1996, both in look and game play. And thelessons that we’ve learned from the RAINBOWSIX production cycle have already been rolledinto the next round of Red Storm products. Ourcurrent focus is on getting solid designs done upfront and solid testing done on the backend—and on making great games, of course.

259Raven Software’sSOLDIER OF FORTUNEby eric biessman & rick johnsonThe development of SOLDIER OF FORTUNE wasrife with questions and uncertainties right fromthe very beginning. Fresh from finishing up POR-TAL OF PRAEVUS, the HEXEN 2 mission pack,Raven was ready to dig in to a full-fledgedstand-alone product. Unfortunately, no one atRaven had a solid idea for our next project andwe found ourselves floating in a sea of ideaswithout a solid direction. With a full team readyand willing to go, we needed a project and weneeded one fast. It was then that Activisionhanded us the Soldier of Fortune license.In the beginning, what was to become the SOFteam was focusing on several different storylines and game ideas. One of these was a somewhatreal-world, military-style shooter based ina World War II setting. When we decided not topursue that game, we began looking for newgame ideas. We knew that we still wanted to doa real-world military game, but beyond that wedidn’t have much of an idea. As soon as we gotthe Soldier of Fortune license, though, thegroundwork for the game immediately began tofall into place.While the license name itself was met withmixed reactions from the SOF team, at its corewas everything that we wanted from the game.Back-StorySOLDIER OF FORTUNE puts the player in the role of a contemporarymercenary, fighting in locations around theglobe for the highest bidder. The game puts a premiumon making real-world considerations a part of gameplay,which distinguishes it from other first-person shooters.For example, a noise meter warns players if they arealerting opponents, and wound location and weaponcaliber matter in combat. An array of high-tech, but stillrealistic, gadgetry rounds out inventory possibilities. Thegame's graphic violence and the detailed anatomicalspecificity in its damage system raised a few eyebrowson its release, and a non-violent version was released intandem with the original.Action, intrigue, political turmoil, and firepowerwere key elements of the design from the verybeginning. Now we needed to find a story thatwould complement the license and turn it into agreat game.The name SOLDIER OF FORTUNE evokes differentimages for different people. One thing thatwe could all agree on was that the title reflectedthe mercenary life; making money at the risk ofdeath. This was something that we wanted tohighlight and focus on dramatically throughoutthe game. However, focusing on this one aspecttended to blind us to the bigger picture of whatwe were trying to accomplish, and our first few

Raven Software’s SOLDIER OF FORTUNE 260story attempts failed miserably. We focused toomuch of the gameplay on making money andnot enough on finding something that wouldtruly compel the player throughout the game.Nevertheless, even without a story set in stonewe began the production of the game. This wasGame DataRelease date: March 2000Publisher: ActivisionGenre: First-person realistic shooterPlatforms: Windows 95/98/NT/2000, LinuxFull-time developers: 20 (on average)Contractors: 2Budget: Multimillion-dollar budgetLength of development: 23 monthsHardware used: Dell Pentium 550 with 128MB RAM,18GB hard drive, and a TNT2Software used: Microsoft Visual C++ 6.0, MicrosoftVisual SourceSafe 6.0, 3D Studio Max 2.x, Softimage3D, PhotoshopNotable technologies: Licensed the QUAKE 2 enginefrom id Software (using OpenGL), motion-capture datafrom House of Moves, force feedback, A3D/EAX 3Dsound, World Opponent Network (WON) matchmakingservicesProject size: 406,044 lines of code, 602 filesa decision that we would come to regret manytimes throughout the rest of the developmentcycle. The bright side to spending a large portionof development time working on a gamewithout a solid story was that most of it wasspent on technology creation. The bad part wasthat many of the levels that were originallyplanned and created had to be reworked orremoved from the game entirely.On top of that, Activision was getting a littlenervous that they had not seen any solid gameplayfrom us yet after almost a year of development.This uneasiness itself caused majorturmoil in the development and it took a whilefor us to settle into the game that we wouldeventually create. Luckily, during this time, allof the core technology was implemented andfunctioning smoothly. Because of this, once wenailed the story down, we were able to jumphead-first into the production and quickly createa solid product.In order to achieve a strong sense of realism, wedecided to talk to a published author about thescript and also to a real-life “military consultant”about how a soldier of fortune truly liveshis life. This was one of the major turningpoints in the development and we were finallyable to focus the game into its final product. Aswe settled on an action-movie feel, SOF finallybegan to take form. We were able to tie togetheran appealing story line quickly with severaltwists to keep the player enthralled.Combining this with the extensive amount ofinformation that our military consultant providedus, everyone on the team was excitedabout the project again and the true developmentof the game got underway. In less than tenmonths, the core of SOF was assembled into a

261SECTION IV: BUILDING ON A LICENSE261fun, viable product. After the game was releasedthis past March, the rest, as they say, is history.What Went Right1. Familiarity with technologyplus powerful tools andenhancementsOne of the most important pluses for SOF wasthe team’s experience and familiarity with theQUAKE technology. Raven has been using idTwo views of SergeiDekker, the quintessentialbad guy.Software’s technology since its early days ofHERETIC and HEXEN. This familiarity allowedus to experiment, create, and use tools thatvastly sped up the game’s development.QuakeHelper. One of the first tools that wedeveloped was QuakeHelper. As SOF’s developmentprogressed, we realized that all of theoptions associated with the individual texturesfor the world were becoming too complex toencode into a parsing file. QuakeHelper wascreated to allow a visual way to assign all ofthese properties. This included texture scaling,detail texturing, damage texture (next texture tobe shown, and the amount of damage it shouldtake), material properties (sound and visualeffects for user interactions), and alternate textures(more detailed and unique textures wouldbe replaced by common textures on video cardswith lower texture memory). In the end, SOFhad more than 5,000 unique world textures.QuakeHelper saved the artists a tremendousamount of time in preparing the textures for thegame and in adjusting and tweaking their properties.ArghRad. One of the benefits of working in theQUAKE community is that the public has accessto most of the source code to the tools. In thebeginning of the project, we used QRAD, whichwas the original tool id developed to calculatethe lighting information on the world. Ourdesigners learned of an enhanced version ofQRAD that had been developed by Tim Wright.He called the new modified version ArghRad!,which added a Phong-type shading model to thelight map calculation, a global sunlight castingpoint, and several bug fixes. Raven contactedhim to arrange to get the source code. In theend, this helped us create better-looking levelsby utilizing the wonderful QUAKE community.

Raven Software’s SOLDIER OF FORTUNE 262DS. DS, or Designer Script, was developedjointly for both HERETIC 2 and SOF. The goalwas to provide a simple language for designersto help create more complex scenes and puzzlesin the game. Those who designed this languagerightfully kept in mind whom the language wasfor. In other words, it was a language created byprogrammers for designers. While this mayseem like a straightforward concept, often thisidea gets lost during the development phase oftools or other items that are supposed to assistthe desired recipient. Even though this languagedid have certain limitations (described under“What Went Wrong,” beginning on page 265),it did help meet our goals for both projects. Thefollowing two tools helped extend the scriptinglanguage in simple yet powerful ways.Chimaera. Because of the large amount of animationneeded for SOF and the fact that wewere going to be using a mix of traditionalhand-animated sequences and motion capturesequences, we needed something that wouldwork well with both. All of our motion capturedata was taken by House of Moves, a wonderfulmotion capture house, and sent to our animators.From there, we used Chimaera, a controlrig within Softimage that allowed us to tweakboth types of animation easily. It also allowedthe animators to utilize both inverse and forwardkinematics simultaneously, accomplishingROFF. While one of SOF’s designers was playingaround with Lightwave to create a complexmotion path for an entity, he ended up writingan exporter that created a DS script. The scriptconsisted of a series of move and rotate commandsto simulate the complex movement animatedin Lightwave. While this accomplishedthe ultimate goal of importing the entity’s animationinto the game, it was not very efficient.Exporting the movement into a file and adding acommand to the scripting language to play thatmovement file corrected this. This format wasknown as ROFF (Rotation Object File Format).SOF used about 500 of these movement files,from the simulation of helicopter movement andexploding crates, to creating a flying bird(although you’ll have to look really hard to seethat one).Every cinematic sequence was conceptualized withstoryboards first.this ordinarily complex task with relative ease.One of Chimaera’s most important features wasthat it allowed the animators to apply every animationto any humanoid model, including modelsnot local to SOF. This tool has also been putto good use on our next release, STAR TREK:VOYAGER—ELITE FORCE.

263SECTION IV: BUILDING ON A LICENSE263SoFPath. We originally developed SoFPath tocreate a pathfinding system based on the BSP ofa map. During the development of this tool,however, we discovered that the world was brokenup too much to provide an effective meansof pathfinding. Our early use of .ROFF files alsoshowed that animating entity movement orrotation in a commercial package was difficultwithout a good representation of the world.Since the SoFPath utility had a good “understanding”of the BSP world, we changed it toexport .IFF Lightwave object files. The designerswould basically BSP their map (either the fullmap or a partial region), create the Lightwavefile, and import it into Lightwave. They thenhad a representation of the world, a rough outlineof all entities, and could then animate thingsaccurately. Later in the project, we also addedthe ability to edit these files in 3D Studio Max.Audio tools. Both dynamic music and ambientsound systems were designed internally to createimmersive environments in SOF, but they alsoallowed the sound designer to add sound assetsinto the game more easily. Instead of hard-codingthe names of the sound files, the tools provideda quick and flexible method of tweakingsonic properties in levels. This process not onlytook the weight of sound placements off theprogrammers’ shoulders, but also empoweredthe sound designer with a powerful and creativetool to create unique soundscapes.2. Taking time to addressviolence concernsFrom its inception, we knew that SOF wasgoing to be a game for adults. Due to its largeamount of simulated violence, we wanted tomake sure that adults had every opportunity tokeep SOF out of the hands of minors while stillbeing able to play the game on their home computers.In order to do this, we implemented severaldifferent protective measures forconsumers.First and foremost was creating the SOLDIER OFFORTUNE: TACTICAL NON-VIOLENT VERSION. Atotally separate SKU from the regular version ofthe game, the low-violence option removed allof the gore, limited the number of death animations,and seriously toned down the game ingeneral. This version used the same box as theregular version, but colored red instead of greenand stamped with a large advisory that statedthat it was different from the regular version.For the regular version, we added a violencelockfeature to allow users to password-protectthe game and change various options to theirliking. The consumer could lock out dismemberments,blood, death animations, adult textures,and other adult content, essentially turning theregular version into the low-violence version. Tofurther inform consumers of the violent subjectmatter, a large warning was placed on the frontof the box and the ESRB rating was enlarged forgreater visibility. A “mature audiences” warningwas also added to the game’s bumper and implementedinto the menu system so that no onewould be surprised by the game’s content.All of these features and functions helped extensivelyin the end. We widened our sales platformas stores realized they could order thetactical version if they wanted to, and we

Raven Software’s SOLDIER OF FORTUNE 264showed consumers that we listened to theirneeds and concerns, giving them a broaderchoice in their purchase.3. Outside helpAlthough your team will most likely not beusing real-life mercenary John Mullins to helpdesign your game, outside individuals can be anincredible help in product development. Talkingand working with a person who has an exhaustiveknowledge of your game’s subject matterwill help refine your project and add a trulycohesive feel to the final product.As a consultant helpingus with the military aspect ofthe game, Mullins gaveinstant feedback in areaswhere our knowledge waslacking and helped round outthe areas that needed it.He described how trained soldierswould react to attacks.He discussed what soundsyou would expect to hear inbattle. He advised us on how the weapons in thegame should “feel” to the player. In short, hehelped us to create the correct atmosphere inwhich to immerse players. By drawing on theinsights and knowledge of someone with firsthandexperience of the action we were lookingfor, we were able to focus the design of thegame.Breaking out the big guns.4. “Commando” marketing andbuzz wordsWe knew that in order to keep the QUAKE 2engine competitive in the FPS realm, we had toadd significant technology. Many of the technologyimprovements we made were centered onnew modeling technology, which featured,among other things, a completely new modelingsystem, compression of animation data, attachmentof models (bolt-ons), multiple skin pagesper model, and advanced networking. Our leadtechnology programmer dubbed this new modelingsystem Ghoul (in keepingwith an earlier in-housetechnology proposal calledSpecter).In the public’s eye, we associatedall of these majorchanges with the Ghoulname. Without Ghoul, SOFwould have been a mereshadow of the final product.It allowed us to throw in allthe bells and whistles, includingthe vast array of enemies and the highdegree of gore. As SOF’s development progressed,our continued references to Ghoulcaused the public to monitor the changes andbuild up their expectations. Ghoul became animportant marketing word for SOF.Besides normal marketing channels such asmagazines and print ads, we decided to try ourhand at “commando” marketing. By using our.plan files, giving web interviews, supporting thewonderful fan sites that were popping up, and

265SECTION IV: BUILDING ON A LICENSE265making ourselves available throughe–mail and online chats, we established astrong presence in the Internet community.This proved invaluable for consumerfeedback. With the release of thedemo and the early OEMs, players gaveus instant feedback on what they likedand disliked and we were able to changethe game accordingly.One example where this feedback camein handy was with limited saves. Originally,players were limited in the numberof saves that they could make based ontheir present difficulty level. Many peoplewho played the demo disliked this feature,so we added the ability to customize the numberof saves that players could make, thus adaptingthe game directly to consumers’ preferences.5. Good planning andschedulingOne of SOF’s saving graces was that it wasplanned and scheduled well. The sheer volumeof animation, art, programming, and levelsforced us to update our schedules on a frequentbasis. With a concrete animation naming system,an incredibly large and detailed databasefor animations, storyboards for every cinematicsequence, and a well-designed QA system, SOFdid not suffer much inefficiency. The only areathat endured some wasted time was the designdue to the various story and game changes.Once the story was finalized and had the greenlight, establishing and maintaining good planningand scheduling for the design processhelped finish the game in a timely manner. Wecreated total level walkthroughs, with eachroom and encounter written out. Flowchartswere used to draw the preliminary levels, andconcept art was used for key location elements.Perhaps the most important lesson we learnedfrom SOF was that preplanning is the mostimportant aspect of game creation.What Went Wrong1. Unfocused designThe single most damaging problem duringSOF’s early development was that the originalgame lacked a truly focused design. We knewwhat the fundamentals of the game would be,but we did not have the specifics that we neededto create a solid, cohesive product. The game’soverall story changed five times before it wasfinalized—at one point we had even changed the

Raven Software’s SOLDIER OF FORTUNE 266basic game concept to a team-based tacticalshooter, similar to RAINBOW SIX.One reason for this indecisiveness was that, atthe time, our original marketing team was wonderingwhat the “hook” would be for the game.This was a major roadblock in creating thegame because we knew that if marketing wasn’tbehind the idea, SOF wouldn’t get the marketingmoney that it deserved. On top of that,Raven developed QuakeHelper to manage more than5,000 unique world textures with a visual means toassign properties to them.without the backing of the marketing division,the senior management at Activision wouldn’tget behind the title, either. We had to constantlysell and resell the idea that a high-octane,action-movie-like, real-world combat gamewould be enough of a hook. At times, it went sofar that we were making design decisions not forthe fun or betterment of the game, but to findthe hook that we felt we were missing.The last straw came when we found ourselvesworking on a tactical team-based shooter, acomplete 180-degree shift from our originaldesign. We then decided to return to the game’sroots and started banging out a new story. Eventually,a new marketing team came on boardthat recognized exactly what we had been sayingall along. SOF had more than enough tostand on its own, and they worked with us tofind the right angle for marketing the product.This new team fit right in with the developmentteam and things started to roll.On top of that, since we urgently needed to naila story down in a short amount of time, theyrecommended that we meet with a hot-sellingwriter (Gonzalo Lira, author of the spy novelCounterparts) and John Mullins. Although thefull story that Gonzalo Lira wrote for us wasnever used, some elements of it were, and theprocess made us realize exactly what we wantedfrom this game and how to get it. John Mullinscontributed an element of realism to the gamethat we were missing at that time.In short, working on everything at once was notthe way to go. For the projects that we currentlyhave lined up we are designing the entire gamefrom start to finish before we begin physicallydeveloping it. The SOF team learned the hardway that a day of preplanning saves a week ofrework. Also, getting a green light for everythingbefore starting development saves havingto backpedal later on. Both of these lessons willbe applied to our future projects.

267SECTION IV: BUILDING ON A LICENSE2672. Technology creation tooklonger than expected to visualizegameplayA sure way to sell your product is to have aworking prototype a tan early stage in its development.Since we had decided to give theQUAKE 2 engine an entire overhaul, we realizedthat we would really have to come together andwork as a team to make sure things were completedon time. One of the major enhancementsfor SOF was the Ghoul modeling system, whichreplaced the entireQUAKE 2 modeling system,and turned out tobe quite the undertaking.Throughout theentire life of theproject, tweaks andchanges were made toGhoul to make it moreflexible and powerful.Unfortunately, this alsomeant that for a substantialpart of theearly development, wehad no game to look at — only individual components.It’s one thing to be able to look at amodel in a model viewer, or at a level with nothingin it, but it’s essential to be able to see themodel in the world and interact with it.Another problem was the huge number of animationsplanned for SOF. Since we had so manyanimations (more than 600 sequences) we hadto limit which animations would appear on aspecific level due to memory constraints. Limitingthe animations on a per-level basis was anightmare in itself, not only for the animatorsbut also for the AI programmer (who had tomake the AI work within the animation constraints)and the designers, who had to createscripted and cinematic sequences using only theanimations available for each level. As the gamedrew nearer and nearer to completion it becameincreasingly difficult to bring new animationsinto the game without ruining someone else’swork by removing an animation that wasalready in use.The final problematic technology was the AI.Developed throughoutthe entire course of theproject, the AI wentthrough many differentincarnations. Wedecided early on thatthe pace of the gameshould be fast and furiouswith a large numberof enemiesattacking at once. Enemieswere to be reactive,but not toointelligent. There were three major areas thatcaused AI problems: developing the models,developing the intelligence, and working withthe scripting language.The main enemy model for the game was verycomplex. Incorporating all of the animationsequences and consisting of nearly 4,000 polygons,the model contained every piece for variousbody builds, coats, and other items thatdifferentiated the enemies. Because of this complexity,we were forced to preprocess enemy sets

Raven Software’s SOLDIER OF FORTUNE 268for each level. These individual enemy setslooked at what enemy pieces and animationframes were needed for the level because we didnot have a skeletal system in place. This directlyimpacted the AI because not every move wasnow available on every level. In turn, the AIcould only call animations that were genericacross the levels.The second area thatcaused AI problems wasthe addition of multipleskin pages, bolt-onaccessories, gore, anddeath animations.Although not directlyseen by most people asAI, all of these wereimportant features forSOF. One of our maingoals from the beginningof the project was tohave lots of uniquelookingenemies. Thismeant that our modelwas composed of manydifferent skin pages into which we could swapdifferent faces or outfits. We also implementedwhat we termed “bolt-ons”: any item or featurethat was not originally part of the model. Theseincluded Mohawks, canteens, briefcases, andside arms, which helped distinguish differentcharacters. Implementing the gore was also verytime consuming. We implemented gore zonesthat required skin page overlays, bolt-on modelsof viscera, the ability to remove limbs, and all ofthe blood pools and spatters that litter the game.Finally, implementing the various deathsequences also hampered the AI. In addition toall of the gore that we created, we also had toplay one of several animations when an enemydied. Animations had to be called based on certaincircumstances, such as where on the bodythe enemy was shot and what he was shot with.On top of all of that, adding the violence-locksystem that would allowplayers to lock out the gameviolence meant that all of thegore and animations had tobe able to be shut off if theplayer wanted.The third area that causedproblems for the AI was itsactual development. Alongwith the problems created bythe per-level animation system,the AI also had to workwith the game’s scriptinglanguage. If the AI wastweaked in certain ways, itcaused the scripting tobreak. Many times in thegame, enemies had to be “frozen” in place whiletheir script waited to be activated. If a playerhappened to see one of these suspended enemiesbefore they were triggered, it obviously madethe AI appear less intelligent. We had to comeup with ways around these problems, andexpended considerable time and energy to fixthem.To make matters worse, the AI had a slightunpredictability built into it that caused scriptedevents to occur differently each time. Although

269SECTION IV: BUILDING ON A LICENSE269unpredictability is good for gameplay, it had tobe removed from the scripting element. Finally,a large amount of time was spent with thedesigners to build in hints for the areas (such asreactions of the enemies) and to specify whichareas the enemies could traverse. At the beginningof the development we had “duck,”“hide,” “flee,” and other commands that eventuallywere removed and taken over totally bythe AI. The AI was in development until nearlythe end of the project.3. Too many OEMs and demosSomething that seemed like a great idea at thetime but turned out to hurt us in the end was thedecision to make specific OEM releases beforethe game was truly finished. The main reasonfor this was that we looked at the revenue thatwould help the bottom line instead of consideringhow much it would set back the game.Because there were both regular and low-violenceversions of the game, we needed to makeseveral different builds for the different violencelevels and test each build accordingly.In the end, we had roughly 75 QA submissions.While each OEM and demo iteration helpedbring more of the game together, it also divertedour attention from the final product. As we weretweaking and fixing the OEM versions, full productionwould come to a standstill as wefocused on getting the smaller versions out thedoor.4. No fixed deadlinesOriginally, SOF was scheduled to ship in July1999. Activision wanted to avoid releasing SOFin the “blast zone” of competing FPS titles thatwere shipping that year, so they extended thedeadlines on the game. As our competitors’titles were pushed back, so was SOF. Althoughwithin these deadlines we had schedules set upand planned out, this caused a never-endinguncertainty of how much time we had left in theproject and how much technology we could addor change within that time.In March 1999, we realized that with our complexmodels and the amount of animation wewanted, we needed to address memory concerns.Because we thought that we only hadthree or four months left of core development atthat stage, we concluded that switching to askeletal system would be too risky for theproject. Instead, we created a vertex compressionsystem that mimicked the benefits of skeletalcompression in a few ways. Unfortunately,this meant that we were not able to provide allof the animations at once, as we would still beover memory budgets. If we had known that ourdeadlines would be pushed back another sixmonths, we would have added the skeletal system,saving everyone a large amount of headachesand work.5. Miscommunication aboutsome technologiesConfusion over project scheduling aside, additionaltechnologies were developed during thecourse of the project that were never trulyplanned out appropriately, such as the terrain

Raven Software’s SOLDIER OF FORTUNE 270engine, the in-game effects editor, and thescripting system that we used. All of these technologiesserved to improve the game substantially,yet they could have worked better if theyhad been properly discussed between the teammembers.The terrain engine, while flexible enough to dovarious types of visualeffects, was neverproperly coded intothe gaming logic. Thebasic premise of theterrain engine wasthat the designerswould create architecturethat representedthe portions of theworld that the playercould interact with.For example, on thetrain level, the trainwas created by the designers. The terrain enginewould then be responsible for the scrolling polygons,in this case the train tracks and surroundinglandscape. When we put this level in, wesoon realized that we needed a bunch of specialcode to handle the various effects, such as whena person falls off a train. We wanted to addmore unique kinds of levels like this, but wedidn’t have time to develop a generic physicssystem for handling other types of terrain, suchas water where bodies might float or sink.The effects editor was created by one of the programmersto help him create visuals for theweapons. The interface, while functional, wascrude. Other people wanted to create visuals,including designers, but were hampered by theeditor’s interface design since it was neverintended to go beyond the programmer whocreated it. Although the in-game editor allowedsomeone who knew the tool to create a specialeffect quickly and efficiently, it had a long learningcurve for those not familiar with it. Thisreduced the amount of control that the artistshad over the effects.SOF shared the samescripting languagethat HERETIC 2 hadused. It was originallydeveloped to givedesigners more controlover their levels,but we soon learnedthat we would need toadd more and morepower to the scriptingsystem. SOF’s complexscripting soon overwhelmed the scriptinglanguage and too much time was spent trying totweak out sequences. With the addition of ingamecinematics (an unplanned feature notincluded in the design document), we realizedthat the way we were using the powerful scriptinglanguage was wrong. If we had planned betterfrom the beginning, the scripting would havegone much easier. Unfortunately, since the storywas planned so late, we didn’t know at the timewhat would be needed.A Direct HitOriginally slated for an 18-month developmentcycle, SOLDIER OF FORTUNE ended up taking

271SECTION IV: BUILDING ON A LICENSE271nearly two years, a considerable undertakingthat in the end allowed a talented group ofdevelopers to really shine. As with all projects,SOF had its problems, but for the most partthings went well thanks to the efforts of anincredible team of people, and SOLDIER OF FOR-TUNE has quickly become one of Raven Software’sbest-accepted titles. With strong sales todate and a solid Internet community, SOF hasexceeded many people’s expectations, includingour own.We’ve been very happy for the large number ofgood reviews, both in print magazines and onthe Internet, and we are helping to support theonline community as much as we can. From adevelopment viewpoint, SOF allowed the Raventeam to grow and mature, and many lessonsthat we learned are now being put to use in ournext set of products. Of course, no project everruns smoothly, but with each new game we gainmore understanding of what it takes to makethe next one better.

This Page Intentionally Left BlankRaven Software’s SOLDIER OF FORTUNE 272

273SECTION VThe Online FrontierOnline gaming as a large-scale commercialendeavour is clearly a big part of the future ofgaming. There is something uniquely thrillingabout the experience of sharing a virtual worldwith other people. The emotional buzz and endlessunpredictability of human interaction areirreplaceable.However, it’s still unexplored territory. We arestill exploring ways to crystallize that fascinationin a mass-market game. Like the Internet,we don’t quite know what to make of it or whatto do with it; we just know it’s huge and interestingand it’s not going away. Like 3D graphics,online multiplayer gaming has swept the industryas a technology without providing a clearblueprint for what kind of games should bemade using it.It’s just clear there’s something fundamentallypowerful about it. Single-player games allowplayers to immerse themselves in dreamlike fictionalworlds with the total absorption commonto films and novels, with the added experienceof interactivity. One downside is that they havea solitary, even solipsistic quality that some findto be lonely or sterile. By contrast, online gamesare vibrant social worlds, challenging, unpredictable,and occasionally moving. They blurthe line between art, game, and community inways we are still sorting out.Online gaming—two or more people playing ashared game through a computer—has beenwith us almost since computer games wereinvented. As researchers, hobbyists, and entrepreneursexplored the beginnings of the computergame phenomenon, many of those earlydirections involved multiplayer worlds and networkedinteractions. In 1978 Roy Trubshawand Richard Bartle coded the first MUD (Multi-User Dungeon), an online virtual space thatplayers accessed through text interface. Worklike this continued through the 1980s and early90s, largely out of the public eye, until in themid-90s a few games brought the idea to prominence,showing how much fun and profitable itcould be. A few games like AIRWAR and MERID-IAN 59 gained devoted followings, and DOOMintroduced the charming neologism “deathmatch”into our collective vocabulary.In 1997, though, online gaming entered themainstream with Richard Garriott’s ULTIMA

Section V: THE ONLINE FRONTIER 274ONLINE, the first massively multiplayer onlinegame, a gigantic implementation of a fantasyworld derived from his earlier, genre-foundingrole-playing series. UO had many supportersand many critics, but over time it proved itsconcept—its popularity demonstrated the feasibilityas well as the profitability of such anenterprise. Large-scale fantasy role-playing iscurrently the dominant paradigm for onlineplay, but it probably won’t remain so—thereare too many interesting modes of play waitingto be explored.As they continue to evolve, online games bringup new questions and raise new challenges forgame production. Development teams aren’tjust creating a piece of software they can forgetabout once it has been published—they’re planninga service that users will subscribe to andkeep interacting with, potentially for years.There has to be a business model that will sustainnot just the production cycle, but the maintenanceand administration of the game once itgoes “live” and stays active for as long as it canturn a profit. How do players pay for such a service—bythe hour, the month or according tosome unit in the game, like territory or titles ortroops to control? The live game creates a wholenew phase of the production life-cycle, onewhich probably lasts much longer than developmentand is equally unpredictable. We are stilllearning what it looks like, what kind of teamstructures and roles and skills it involves.Game design has been equally redefined by theproblems of the online space. Is the game’s virtualspace a place to explore, to conquer, or tobuild? Do players meet to collaborate, compete,trade, or fight? Do they clear out a given areaand move on, or stay in one space to interact?What happens if players run out of things to do?Is the game-world static, or does it change overtime? How do we avoid dangers like flashcrowds overloading servers, and players disruptingother players’ experiences?The least predictable and least controllable factorin an online game is the players themselves.An online game is partly composed of the peoplethat play it, the community that surrounds itand the culture that forms in the process. But asa developer, how do you influence the nature ofthe community that comes about, both beforeand after a game’s launch? You can’t controlwhat players do in your world, only try to createa system that encourages play. At times, rulechangesfeel more like legislation than gamedesign. Community management has become anessential development task. The whole nature ofthe relationship between game developers andplayers is changing from vendor-buyer to someamalgam of host-guest, server-client, and government-citizen.Little enough is known about how to makeonline games, which makes the few postmortemsavailable in this section that much moreinteresting. Here are a few tips that can beabstracted from these developers’ accounts:• Anticipate high demand.Nearly everyone seems to underestimate thenumber of users who want to play theirgame.

275Section V: THE ONLINE FRONTIER275• Tools.World-building tools aren’t enough; administratorsand customer service people needtools to monitor the game and assist playersonce the game goes live.• Get full use out of your public beta.In addition to reporting bugs, experiencedand committed players can be help educatenew players and set the overall tone and cultureof your online community.• Don’t trust the client.A tried and true observation—players willexploit, hack, or otherwise take advantage ofany weakness in the game to gain power orjust disrupt the game.• Don’t rely on existing content to keepplayers entertained.Players are ravenous for things to do. Theywill instantly strip bare as many dungeonsand hunt down as many monsters as you canmake. The lasting interest of your game willalways be in strength in players’ interactionwith one another, in community and competition.

This Page Intentionally Left BlankSection V: THE ONLINE FRONTIER 276

277Mythic Entertainment’sDARK AGE OF CAMELOTby matt firorDARK AGE OF CAMELOT was the best-sellingcomputer game in the United States for the weekof October 7, 2001, and is still comfortably inthe top five as I write. This Postmortem is anoverview of how this successful title was conceivedand developed. My role on the projectwas as the game’s producer. Mythic Entertainmenthas been developing online games as acompany since 1995—forever in this field—butthe company’s founders had made online gameseven before then. In fact, as a company, weprobably have more experience than any othercompany in developing online games of alltypes—over the years we have developed roleplayinggames, first-person shooters, top-downspaceship shooters, and strategy games.When I last wrote a Postmortem in the pages ofGame Developer, it was back in May 1998 forALIENS ONLINE, our online first-person shooterbased on the well-known Alien movies. AfterALIENS ONLINE, a nonaccelerated game, we createdour first 3D-accelerated game, SPELL-BINDER: THE NEXUS CONFLICT. During thatproject, we developed a relationship with NDL,makers of the NetImmerse 3D engine API toolkit.We learned a lot about 3D engine developmentover the course of that project and becameBack-StoryDARK AGE OF CAMELOT is part of the second generationof massively multiplayer online games to reach the public.The game is set in a mythic British past in the chaosfollowing the death of King Arthur; accordingly, theworld is divided into three realms (respectively Celtic-,Norse-, and Arthurian-themed) eternally at war with oneanother, giving shape and purpose to interplayer conflict.At first glance, it appears cast in the same mold asits predecessors—medieval fantasy adventure—but ahost of smaller changes, such as in interface and community-relatedfeatures, reshape the gaming experience.very comfortable with software and art developmentin this environment.We finished SPELLBINDER, which went on to be amildly successful Internet shooter, and it still hasa small but loyal following. After completingthe SPELLBINDER project, we decided to create agraphical online roleplaying game to competewith the then new wave of online RPGs such asULTIMA ONLINE and EVERQUEST, which weretaking traditional text-based games and addinga graphical front end, with very successfulresults.Over the years, we had developed several nongraphicalonline role-playing games, including

Mythic Entertainment’s DARK AGE OF CAMELOT 278DRAGON’S GATE and DARKNESS FALLS: THECRUSADE. Because of our experience developingRPGs, we knew that we had to have a slightlydifferent slant on our new title in order to distinguishit from the RPGs that were already onthe market. DARKNESS FALLS: THE CRUSADE(DFC) featured a built-in player-versus-playerGame DataRelease date: October 9, 2001Genre: Massively multiplayer, online fantasy roleplayinggamePublisher: Mythic Entertainment/AbandonEntertainment/Vivendi Universal Interactive PublishingPlatforms: Windows 98/ME/2000/XPNumber of full-time developers: 25Number of contractors: 5Estimated budget: $2.5 millionLength of development: 18 monthsDevelopment hardware: 900MHz Pentium IIIsDevelopment software: 3DS Max, Photoshop, VisualC++, Linux GNU C++, various proprietary in-housetoolsNotable technologies: NetImmerse, Linux opensourceserver and database products(PvP) conflict in which three different teams,called Realms, fought each other for control ofmagical artifacts, known as Idols. We reallyliked this concept, which served to keep DFCplayers hooked on the game—especially becauseno other online game featured such team-basedconflict as a core part of the game design. So, inlate 1999, we decided to make a graphical versionof DFC.The project was dubbed “Darkness Falls 3D,”and we began preliminary work researching clientengine and server technology. Right off thebat it was obvious that we had two major factorsgoing in our favor. First, we determined wecould use a much-enhanced version of theSPELLBINDER graphics engine as DFC3D’s client,just as we were able to use DFC’s server code asa platform for the new game’s back end. Havingsuch a solid client and server right at thestart—with associated client/server messaging—alonesaved us at least a year of development.Second, and even more advantageous, DFC’sserver came with that game’s database ofobjects, monsters, and weapons. Indeed, wewent into the CAMELOT project with a hugehead start. We were proceeding along under theDFC3D concept until our president, MarkJacobs, came up with the idea of basing thegame, at least partially, on the Arthurian legends.It was a great idea, since the stories ofKing Arthur are in the public domain, whichmeant we could use them with no fear of licensingissues.Of course, because the game was based on theidea that three Realms were in conflict, wequickly came up with the idea of basing theother two Realms on Norse Viking myths andCeltic Irish legends, respectively. Having themyths and legends of three cultures gives CAM-ELOT the feel of being three games in one, sinceeach Realm has different races, classes, guilds,terrain, and monsters. Because everyone knowswhat happened in Arthurian England, we basedthe game after Arthur’s death and developed a

279SECTION V: THE ONLINE FRONTIER279back story of conflict among the three Realms.The game was rechristened DARK AGE OF CAM-ELOT, and around January 2000 we began theproject in earnest. A year and a half and untoldnumbers of Monty Python jokes later, we finishedthe game.The initial versions of DARK AGE OF CAMELOTused the rights for a tabletop role-playing gamecalled Rolemaster as a basisfor the class and spell systems.Not long into theproject, the company thatcreated Rolemaster, IronCrown Enterprises, filed forbankruptcy, and we lost therights. This turned out to begood for us, however,because we were no longerrequired to adhere to a setof rules based on thelicense—although we didhave to scramble for about aweek to rename and retunespells and classes and otherwiseclear Rolemaster contentout of the game.As a company, Mythic hadnever before been able todevote all of its resources to any onegame—we’d never had a project big enough topay for it. Because of the sheer size and scope ofCAMELOT, we wanted to ensure that everyone atMythic devoted themselves fully to the project.Doing so required an influx of money, and that’swhere New York’s Abandon Entertainmentstepped in. Abandon owns a couple of smallIt all starts with a concept. The troll,a playable race, changed the mostover the course of developmentfrom a hulking, human-like creaturethe more mythologically inspiredversion seen here.companies, each of which specializes in differenttypes of entertainment: a film studio, a webcompany, and a couple of game content developmentcompanies. Abandon wanted to becomemore involved in game development, so it purchaseda minority stake in Mythic. This moneyallowed us to devote everyone on staff to theCAMELOT project, while also expanding and hiringmuch-needed programmers and artists. Ourspreadsheets showed thatwe had enough money tosupport exactly 18 monthsof development startingfrom January 2000, givingthe project a hard end dateof September 2001.By the summer of 2000, wehad nearly our entire teamin place. We had about 25developers working fulltimeon the project—quite asmall number compared toother online RPGs, but ourexisting technology allowedus to reduce substantiallythe amount of technical programmingstaff required. Wehad five programmers, tenworld developers, seven artists,and several other people working on thegame. Rob Denton, Mythic’s vice president andchief technical brain, was responsible for all clientand server programming, as well as the client/servermessaging that tied the two together.His input was critical during design discussions,as he could tell us whether an idea would workor not. He immediately categorized features into

Mythic Entertainment’s DARK AGE OF CAMELOT 280“doable,” “not doable,” and the dreaded “onthe list,” which meant that it could be done, buthe wouldn’t commit to it.Brian Axelson was in chargeof server programming aswell as design of the game’scombat system—a criticalcomponent in a PvP-centricgame. Jim Montgomeryprovided CAMELOT’s clientinterface coding and alsodesigned and coded thegame’s magical spell system.CJ Grebb and Lance Robertsonled the art team. CJwas responsible for thegame’s look and feel, whileLance handled figure modelingand animations andmanaged the team’s deadlines.Their team used 3DSMax and Character Studio to create CAMELOT’scharacter and monster models and animations.The character models were technicallyadvanced, as each in-game character has severaldifferent parts buried in it that can be turned offand on by the game. So, each model can have ahelmet head and a regular head (with hair) withouthaving to load in a new model. MikeCrossmire created the game’s spells in 3D Studio,tweaking the NetImmerse system to displayanimated spells with spectacular results.The other major group in CAMELOT’s developmentwas the world team, led by Colin Hicks.This group was responsible for quests, monsterplacement, object placement, and just aboutIt was essential to provide playerswith plenty of player-versusenvironmentconflict, such as withthe forest giant seen here.everything else having to do with creating theworld of DARK AGE OF CAMELOT. CAMELOT’seconomy was designed byDave Rickey. This economicsystem ensures that playersmust continue to spendmoney as they rise in level,which limits the amount ofmoney that stays in thegame. Dave and MarkJacobs designed CAMELOT’strade skill system, whichenables players to makearmor, weapons, and otherobjects in the game—all tiedto the economic system.Among the myriad tasksthat I did as a producer(writing, designing, persuading,arguing, and such),my job was to make sure allthe teams worked together. I hosted an almostdailymorning meeting (at the wretched hour of8:30 A.M.) where Colin, Rob, CJ, Lance, and Igot together to make sure that we were all onthe same page. I was also responsible for maintainingthe master game client—all files addedto the game had to be given to me, so I couldverify they worked and then integrate them withthe rest of the game.For the game’s sound and music, we contractedwith Womb Music, based in Los Angeles, whichhad provided music for some of our previoustitles. Rik Schaffer, the main guy at Womb, composeda wonderful soundtrack that consisted ofseveral long main scores, as well as many

281SECTION V: THE ONLINE FRONTIER281shorter pieces in the style of Celtic, Norse, andold English folk songs, adding a sense of depthand quality to the world.What Went Right1. Community management/betaprogramFrom the beginning of the project, we knew wehad precious few dollars available for marketing,and that our best chance to capture publicattention would be to have a big presence on thevarious roleplaying fan sites around the Internet.One, the Vault Network, provided us with somemessage board space, a news page, and a coupleof moderators, and we were off and running.We devoted a lot of time over the year and a halfthat DARK AGE OF CAMELOT was in developmentto interacting with the future fans of thegame. We hired a community relations managerwhose sole job was to read different messageboards and report back to us what was happeningin the community. From the beginning, wetook our fans seriously and made many tweaksand additions to the game based on their commentaryand ideas.2. No bureaucracySince the founding of Mythic, we have striven tohave little bureaucracy. We have no levels, nodirectors, and few managers. We have a president,a vice president, and a producer. That’s itfor management, although for CAMELOT we didhave to assign a lead world developer and artco-leads, just to streamlinethe day-to-day processes ofthe project. Because of thissimple command chain, weexperienced no power struggles.We feel this is the bestway to make a solid, cohesivegame—a small group controlswhat the game is and how itis presented to the user.Because of this approach,decisions are made quickly,and features can be implementedwithout an endlessline of approvals and politics.3. Smart businessdecisionsOur close relationship withAbandon Entertainment wasa critical factor in the successof the game. Abandon’s purchaseof a minority interest inMythic ensured that we hadenough money to fund theCreatures weremodeled andmapped using3DS Max andanimated withCharacterStudio. Rumorsthat this zombieis a portrait ofthe producerafter too manymeetings aretotallyunfounded.game from start to completion. Abandon’s managementwas smart enough to realize that weknew more about game development than they,so they largely left us to make game-relateddecisions ourselves. They were involved in theproject, of course—some Abandon employeeseven became avid beta players of the game, eventhough most had never played an RPG before.

Mythic Entertainment’s DARK AGE OF CAMELOT 282Abandon’s investment meant that we did nothave to rely on any outside influence in designingor creating the game, which means thatCAMELOT is wholly ours.With Abandon teaming with us, Mark Jacobs,our president, decided to take a big chance andwait until the game was almost complete beforelooking for a distributor. In most cases, gamecompanies seek out publishers, which typicallyhave a hand in the design and production of thegame and then distribute the game to the retailchain. With Mark’s gamble, we produced thegame ourselves (with critical financial help fromAbandon and business advice from our businessdevelopment person, Eugene Evans) and thenlooked only for a retail distributor. This gamblecould have placed us at the end of the projectwith a great game but no way to get it into thehands of our customers. It all worked out in theend, of course, with Vivendi Universal steppingin and distributing—but on our terms.4. Sweet serendipityThe CAMELOT project was helped immensely byfactors completely out of our control—in otherwords, blind luck. Several high-profile onlineRPGs that were slated to launch at about thesame time as CAMELOT were either pushed off(SHADOWBANE) or canceled outright (DARKZION, FALLEN AGE). Also, the week welaunched was originally scheduled to be thesame week as the launch of WARCRAFT III,which will almost certainly be a huge seller.That project was also delayed, which ensuredthat CAMELOT launched as the only large-scalegame, and the only online RPG, when it debutedon October 9, 2001. This little bit of good fortunegave the game a big initial boost, as therewas little direct competition from other newproducts.In addition to designing CAMELOT’s many outdoorareas, Mythic’s world development team had topopulate those areas with interesting encountersand dynamic quests—no small task, consideringthey had not one but three distinct Realms toaccommodate, as well as a finite amount ofcreatures available to them. Work on this contentis ongoing, with new updates added to the gameon a regular basis.5. The joys of open sourcesoftware and stabilityLong ago, during the development of our earlytitles, we decided to use Linux wherever possibleas our server back-end OS, and we kept tothis same practice when creating DARK AGE OFCAMELOT. We have extensive Linux experiencein-house, and it made sense for us to stay with aplatform that we knew could handle the taskand also was, well, free. Because running CAM-ELOT would require a considerable amount of

283SECTION V: THE ONLINE FRONTIER283data management, we initially planned on usingOracle to store account and character information.However, Oracle’s quoted license fee ofmore than $900,000 quickly removed themfrom contention.Once we got over our shock and amusement atOracle’s pricing, we turned to a Linux-basedfreeware solution, MySQL, to manage CAM-ELOT’s data storage, which so far has workedadmirably. Everyone developing games shouldat least investigate open source solutions fortheir servers. It’s saved us a pile of money andhas been stable and reliable.In fact, prior to CAMELOT’s launch, it was axiomaticthat MMORPGs were unstable andprone to crashing during their first month or so.From the outset, we were determined to buckthis trend. We co-located our servers directly atUUNET, on the network backbone, whichensured a wide network pipe to the Internet.With this Internet connection, we can increaseour bandwidth with just a few hours’ notice toUUNET.With the combination of reliable server codeand a stable Internet connection—all running onopen source software—CAMELOT went live onOctober 9, 2001, with virtually no problems.That first night, the game went down for aboutan hour and a half due to a database configurationproblem, but since then, the game has beenremarkably solid and stable. As of this writing,it hasn’t been down due to server error for morethan a few minutes ever since the first night.What Went Wrong1. Development of customerservice toolsWe really tried to avoid the customer serviceproblems that are characteristic of some recentlylaunched online games. One of the most importantfactors in keeping customer service reasonablyeffective was a smooth launch. Obviously,giving players fewer problems results in fewercalls to customer support. We did an excellentjob with the launch—it went very smoothly.However, we could have better foreseen otherparts of our customer service plans. First, wehad a lot more players in the first week afterCAMELOT went live than we ever could haveforecast—1,000 boxes were sold in the firstfour days alone. Our forecast numbers calledfor a much smaller number, and we hired ourcustomer service staff based on this smallernumber.Also, we put off creating customer service toolsuntil much too late in the developmentcycle—some had yet to be developed when thegame went live. These missing tools really hurtthe customer service staff and added to the timeit took to help each player with in-game problems.Eventually, wait times became much toolong, and customer support as a whole sufferedbecause of it. As I write, we still are trying towork ourselves out of this hole.

Mythic Entertainment’s DARK AGE OF CAMELOT 2842. Lack of a cohesive marketingplanWe went into the CAMELOT project with a lot ofexperience in developing software, but no realexperience in creating a marketing plan. We gota lot of help with advertising from AbandonEntertainment, but there was no overall projectplan. Basically, we took out ads in magazinesthat we thought were important and tried tokeep on top of the Internet community. Wedidn’t regularly issue press releases nor attemptto do a press tour or invite reporters to theMythic offices to show off the game.It’s difficult to gauge just how much this hurt us.Our focus on Internet marketing gave us strongsupport among fans of the genre, but our lack ofcommercial marketing kept our company profilelow, and we never received much mainstreammedia coverage because of it. Fortunately, wemade up for our slow start, and then some, byour successful presence at E3. Abandon funded,designed, and staffed a large booth for us at theshow, complete with medieval motif and lots ofgiveaways.3. O Dungeons and Cities, whereart thou?The first major update we made to CAMELOT’sgraphics engine to differentiate it from SPELL-BINDER was to put in the rolling terrain systemthat makes the world so lifelike. We spent a longtime making the outdoor areas of thegame beautiful and well stocked withmonster encounters. The ease withwhich we did this gave us a false senseof security when it came to developingour dungeon/city technology.These areas in the game required a largenumber of models and characters in amuch smaller space than the outdoorterrain, so creating dungeons and citiesproved to be a much more difficult jobthan we thought. Because we put offdoing the technical designs for the interiorspaces for so long, in the end wesimply didn’t get enough of them done.The game launched with only three capitalcities (one per Realm) and about 15dungeons.

285SECTION V: THE ONLINE FRONTIER2854. We have a great game but noservers!In a great “Why didn’t they tell us about this incollege?” situation, we went into the finalmonths of the project with no credit rating.Mythic Entertainment has been around for along time, but we simply hadn’t ever borrowedany money, and so we didn’t have a credit history.This turned out to be a problem when wewent out to lease our servers from Dell and wereflatly denied. We pointed out that we had plentyof money in the bank, but to no avail. Dell simplywouldn’t lease us the computers until wehad a credit history.In the end, we were forced to purchase the serversoutright from Dell, which obviously had amuch greater impact on our bottom line.5. Postrelease fancommunicationAs good as our communication with CAMELOT’sfan base was during the game’s design and betaperiods, it began to suffer soon after the game’srelease. The community simply grew too largeto communicate with in the manner we had duringbeta, when we simply went out to Internetmessage boards and posted our thoughts andplans. With the game live, it was obvious weneeded a much more coherent way to communicatewith our fans, one that would not sendthem to numerous different fan sites to siftthrough literally thousands of messages. Thissituation grew into a big problem when playersbecame extremely frustrated by what they perceivedas a lack of communication from us.About six weeks after release, we realized thatwe needed to create our own Web site to publishinformation about the game: release notes, planfiles, server status, Realm War status, and manyother little things that we knew but our playersdidn’t. This Web site, dubbed “Camelot Herald,”launched the following week and so farhas been a great success. Fans of the game cannow go to one Web site to get all the informationabout the game in one place and with nointerference.For the AgesIt was a great pleasure to create DARK AGE OFCAMELOT, as it is the first big title that MythicEntertainment has ever worked on. It was awonderful thrill to see our names on top of thebest-seller lists for those couple of weeks inOctober 2001, and we hope to be working onthe game for a long time to come. As long asplayers are interested in playing the game, we’llbe there adding content and updating it.

This Page Intentionally Left BlankMythic Entertainment’s DARK AGE OF CAMELOT 286

287Multitude’sFIRETEAMby art minOur goal with FIRETEAM was to create a completeonline game experience. The Internet givesgame designers the ability to take multiplayergaming one step further by creating a community,something that wasn’t possible beforeonline games came about. Multitude wanted totake the next step in gaming evolution by makingthe community a significant part of ourproduct. In other games, such as DIABLO orQUAKE, the players were creating communitiesthemselves, mostly through their own Web sites.Multitude, on the other hand, devoted significantdevelopment time to creating tools thatwould help the community. We spent as muchtime on FIRETEAM’s lobby and community webpages as on the game engine itself. Our goal wasto create a game that would make people say,“Wow, this is what I’ve wanted from an Internetgame.”FIRETEAM is an online-only gaming experience.The actual game play is a squad-based tacticalcombat. Players can communicate with othermembers of their team using Multitude’s voicetechnology. Each player controls one characterin the battlefield. The game uses an isometric,three-quarter view 2D graphics engine. ThereBack-StoryFIRETEAM's approach to online play is distinctive, aseries of game modes that are half futuristic sport, halfsquad-based tactical combat. Players sign on as part ofsmall teams rather than massive worlds and let teammateschat by voice rather than text to create camaraderieand a more intimate social environment. AlthoughFIRETEAM hasn't persisted, it's an interesting casestudy, contrasting with the dominant massively multiplayerapproach to online play.are four different FIRETEAM scenarios, and eachgame session is ten minutes long. The scenariosare very sports-like in their design to help promoteteam play.Equally important to the FIRETEAM experienceis the lobby, where players can view other players’statistics, chat between games, and findsquad mates and enemies for their games. Thelast component of FIRETEAM is the communityweb pages, which display players’ complete statisticsand provide support for FIRETEAM Companies(which are similar to QUAKE Clans). Onthe community web pages, players can createcompanies, add/kick members, and access privateCompany bulletin boards.

Multitude’s FIRETEAM 288Brief HistoryGame DataRelease date: December 1998Publisher: Cryo Interactive EntertainmentGenre: online tactical team-based sports gameTarget platform: Windows 95/98Team size: 14 full-time developers. Some number ofcontractors.Budget: Approximately $2.5 millionTime in development: Two and a half yearsTools: Microsoft Developer Studio 5.0, Microsoft SQLServer, Microsoft IIS, 3D Studio Max, MicrosoftInterdev 6.0, Microsoft Chat Service, and Windows NTFIRETEAM evolved dramatically over its firstyear of development. Multitude was originallyfounded to create the “ultimate online game,”which was to be a large persistent science fictionworld. We knew that there would be some competitionbecause ULTIMA ONLINE had alreadybeen announced, although Origin hadn’t yetperformed any alpha or beta testing. We spentmonths writing and planning for a massivelymultiplayer online game set in a futuristicworld. The project was to have a server team ofaround 10 people and a game team approximatelydouble that size.As we were designing around our original conceptfor the game, our desire to make a persistent-worldgame work as well as a single-playergame presented us with many hard technicaland design problems. On the good side, it wasduring this process that we finalized the designspec for our combat engine. The combat enginewas inspired by X-COM: UFO DEFENSE, emphasizingsquad combat with features such as lineof-sight.We soon realized that our new company’sfinancing was coming along very slowly andthat we needed a much more easily attainablegoal (due to lack of resources, both financialand human) that would still showcase theunique voice technology that we’d developed.We looked at the combat engine specification,our voice technology, and the Internet technologythat we were designing and realized that wecould make a great tactical team game. So atthat point, we decided to abandon the large persistentworld and make team play the essence ofthe game.Designing a multiplayer game is very differentfrom designing a single-player game. I’ve heardthat in many games, the multiplayer componentwas added on only because marketing hadrequested the feature; this approach can makethe multiplayer experience less than ideal. In asingle-player game, the player is the hero andthe focus of the game experience. The playershould be able to win 100 percent of the time(with some effort). In a multiplayer game, aplayer should win 50 percent of his or hergames against an equivalently skilled player. Thethrill of a multiplayer game shouldn’t be in thewinning, but more in the process and the actualcompetition. Team play gives players a deepgaming experience, even if they lose.Our efforts to create engaging multiplayer gameplay were made even more effective by our voice

289SECTION V: THE ONLINE FRONTIER289technology, which allowed players to hear theemotions of their fellow players.F IRETEAM’s ComponentsFIRETEAM’s network architecture is client/serverbased.We chose a client/server architecturebecause of the benefits that it offered us in theareas of performance (especially with the voicetechnology), cheat prevention, and centrallylocated statistics. The clients all run on Windows95/98 and the servers run on WindowsNT boxes, where we use Microsoft Chat servicesto do the intercommunication between ourserver processes. We also have a Microsoft webserver running the community web pages, witha Microsoft SQL server maintaining the database.Our servers are at one location, our ISP,Globalcenter, in Sunnyvale,California.FIRETEAM uses the ElemediaSX2.0 Voice Codec todo its voice compressionand decompression. Multitude’sproprietary softwarewraps around thisvoice codec and interfaceswith the Windows soundsystem for both input andoutput. The game mixes multiple voices on theclient side rather than the server side. Clientssimply send voice packets to the server, theserver then routes them on to the appropriateteammates.In the future, spectators or enemies will be ableto listen in on the voice chatter. Our voice softwarehandles both DirectSound and non-DirectSound drivers because some sound cardswork with DirectSound in full duplex. Fullduplex means recording from microphone andplaying sound at the same time.Who Worked onF IRETEAMNed Lerner and I started Multitude and beganworking on the original project in April 1996.The development team grew gradually over thecourse of the project. Jim Morris was broughton during the summer of 1996 to be the chieftechnical officer, and his first project was todevelop the voice technology. Alan Murphy wasbrought on to provide art for the prototype andeventually was named artdirector. Conroy Lee,Harvey Smith, and HarrySchaffer were brought onin early 1997 to help takeFIRETEAM from a prototypeto the real game thatwe showed off at E31996. Bill Money, JamesPoelke, and David Reesecame on in late 1997.The team has a very diverse group of productsto its collective credit. Lerner and Morris weretwo of the first people to work on 3D in thegame industry. Murphy’s art credits includeGALAXIAN, PAC-MAN, DEFENDER, TAZ, and X-MEN. The others have worked on games such asSYSTEM SHOCK, TERRA NOVA, MAGIC SCHOOL

Multitude’s FIRETEAM 290BUS, ULTIMA VIII, and FRONT PAGE SPORTS:BASEBALL.What Went Right1. Combining team play andvoice togetherFIRETEAM’s design focus was on team play. Justas we’ve seen in team-oriented sports, the cooperativenature of playing as amember of a team has provenClient Sideto be a very addicting andLobby Clientpowerful gaming design.FIRETEAM’s cooperativenature was a symbiosis of ourvoice technology and teamplay design. We needed togive people a reason to talk toGame Clientstrangers on the Internet.In a fast-paced tactical game such as FIRETEAM,players don’t have time to coordinate movementswith the keyboard. Without voice, youlimit team communication to select macro keys(or players who can type very fast). InFIRETEAM’s Basetag scenario, for example,teammates protecting the base can give instantinformation on where the enemy is making itsattack. Over the course of their lives, peoplehave already learned how to talk; it’s an interfacethey understand. Vocal communicationdoesn’t require a key card list for communicationhotkeys, just a microphone to talk into.InternetInternetServer SideStatistics ServiceUtility ServiceRedirector ServiceGame State ServiceCombat daemonGame ServerGameStatisticsDatabaseTeam play was that reason; itWeb Browsergives people the ability to say“Watch out behind you!” or“Good job!” Teammates canshare the joys of victory or the agonies of defeat.Because there is no button to push to transmityour voice (it transmits automatically when youtalk), players can hear the spontaneity of teammatesyelling and laughing. Emotion comesacross very clearly with voice and is definitelypreferable to typing in ALL CAPS or emoticons.The ease of vocal interaction brings the teamtogether.InternetFIRETEAM’s technical architecture.Community Web Pages2. Designing the project aroundconstraintsMultitude was founded to do a game for theInternet. The Internet offers many problems thatwe had to solve in order to make a fun game.The biggest technical problem was Internetlatency. Fundamentally, latency causes eachplayer to have something different on his or herscreen, so there is always a delay between a

291SECTION V: THE ONLINE FRONTIER291the next shot you made. Byhiding opponents’ healthfrom our players, we hide theperception of lag.A 3D Studio Max layout of one of the maps. Our artists take the gametestedlayout from Tile Edit to create backgrounds for each map.player performing an action and the other playersseeing that action carried out.For example, we decided early on that wewanted the game to respond as quickly as possible.When you shoot at something during aFIRETEAM game, you’ll see instantly whether ornot you hit your target. The actual damage willtake a small amount of time to be applied to thetarget. So it’s possible that you’ll see someoneget shot, walk a bit, and then die. The game cannotprovide a perfect view of the world to eachplayer; that’s not possible given the limitationsof the Internet. So we decided not to show playerstheir opponents’ health. If you can see thatyour opponent has only a sliver of health andthat one shot could kill him or her, then youwould expect that player to die instantly withA project’s constraints canalso be exploited to theproject’s benefits. Because theconstraint was that weneeded to be on the Internet,we created the communityweb pages to give players theability to look at their statisticsand create FIRETEAMCompanies. We wanted astrong community forFIRETEAM, and the communityweb pages were an easyway for people to have anidentity in this communityand to join a group of other players.3. Spending sufficient time todevelop toolsWe used several proprietary tools to createFIRETEAM’s game environments. Early on, wespent a lot of time building easy-to-use toolsthat allowed us to create content rapidly. Ourinternal testers used these tools to create newarenas for FIRETEAM. And because FIRETEAM isan online game, we were able to test new mapsvery quickly with our beta testers.With an online game, game balance is crucial.Players will find any competitive edge and mapimbalance they can and exploit it. Especially inan online game with a lobby, word of cheats or

Multitude’s FIRETEAM 292advantages spreads very fast. Your tools mustallow you to tweak your maps, so you canquickly fix any small problems. Many of ourmaps changed during the course of testing asour testers would point out weaknesses thatthey found.4. Managing risk: voicetechnologyThe biggest risk in developing FIRETEAM hasbeen the voice technology. Many smart peopleinitially said it was impossible, but we knewI can recall a particular controversyover whether Gunball (aFIRETEAM scenario similar tocombat football) was balancedenough. Many of the advancedplayers were complaining thatGunball’s offense was too hard.Using our Tile Edit tool, wequickly created a few maps withtwo endzones for each team(Gunball maps normally onlyhave one endzone). Throughtesting the new maps, we discoveredsome of the problemswith Gunball were unrelated tothe maps themselves, but thatthe offense simply had a disadvantagewhen trying to score. Soinstead of redoing all of ourmap designs, we tuned the Gunballgame by giving the Gunball carrier a protectivedrone.An added bonus of easy-to-use tools is that youcan make them available to the public and letyour players customize the game and createtheir own content. We haven’t yet taken that laststep, because we’re not sure how we want tostore the maps on our servers and present themto the community.This is Tile Edit, our basic world builder. We quickly prototype thephysical layout of the maps with this tool. It’s very easy to movewalls around to achieve the right game balance.that the game’s design objective was a cooperativeteam game, and voice was very important toaccomplishing the goal. So FIRETEAM’s firsttechnical project was to determine whether ornot voice on the Internet was even possible.Once we had the technology running over theInternet, we still faced the possibility that itwouldn’t work with the wide spectrum of soundcards in the market.

293SECTION V: THE ONLINE FRONTIER293We tried to minimize the problems that voicewould cause by providing users with a tool thatwould configure the sound card and microphoneduring installation. Multitude was veryaware (almost scared) of the fact that FIRETEAMwould represent most users’ first use of voicetechnology on their computers. So we had tomake sure that it worked on as many soundcards as possible and that it was very easy touse. We eventually released FIRETEAM as twoexecutables—one for systems with DirectSoundand one for systems without it. One feature thatwe explicitly did not put into the game was theability for players to talk to their opponents. Wewanted players’ first experience with voice to bea positive one. We didn’t think a 12-year oldtelling you where to put your gun in his shriekingvoice would convince people that voice is awonderful addition to gaming. Similarly, peopleasked for the ability to eavesdrop or stealanother team’s radio and listen to the otherteam. This feature would impel team membersnot to talk if they believed they were being monitored.These types of behavior would weakenthe voice feature.5. Promoting communityIf you’re going to design an online game, youcannot ignore the community. Any online game,from FIRETEAM to Poker on AOL to ULTIMAONLINE, will have a community because theplayers will be able to communicate with eachother.Online game developers should take advantagethe fact that their product inherently has a community.Most online games go through alphaand beta online tests mostly to test the software,but few deliberately create or test the communityaspects of a product.Players are not only a source of revenue for aproject, but they are a feature of your game. Inan online environment, the players’ game experiencesare dictated by their teammates and theopponents against whom they play. You wantthe players to follow guidelines and really careabout the game and the community. If yourpopulation is full of a bunch of player killers,then that’s the experience that the players willget.Multitude succeeded in developing communityenablingtools. We spent significant time anddiscussion on our lobby and community webpages. Given FIRETEAM’s team nature, wewanted players to feel a sense of belonging sothat they would want to save each other’s lives.The FIRETEAM product is not just the gameitself. The game is an important piece of theFIRETEAM experience, but it’s only a piece. Thecommunity plays a large part of the whole experience.What Went Wrong1. Misjudging market conditionsWhen Multitude was founded in April 1996,there was a lot of buzz in the online gamespace. Mpath and Ten had big plans. ULTIMAONLINE was about to go through testing. Webelieved that an online-only game, sold directly

Multitude’s FIRETEAM 294to customers via the Internet, would be acceptableto the market when we eventually shipped.What we’ve discovered is that the online gamemarket has not matured to the level that weexpected. Very few online-only games havebeen released, with ULTIMA ONLINE being theonly clear success.We made two decisions early on that shouldhave been reexamined when it became clear thatcustomer acceptance of an online-only gamewas not a foregone conclusion. FIRETEAMwould have been more willingly accepted by themarket if it contained some artificial intelligence(AI). With such an implementation, playerscould practice using the interface by themselvesand, more importantly, players could practice asa team against AIs. With computer-controlledopponents in place, players could play offline orpossibly on a LAN against computers opponents.Many users are intimidated by having tolearn a new game while playing against othermore experienced human players. AIs wouldhave helped ease players into the online-onlypart of the game, providing a feature that manyplayers expect to find in games today.FIRETEAM also should have had a demo availableon day one. As an online game, providing ademo presented an interesting problem becauseof the server issues. With a traditional game,developers can hand out a million demo disksand never think about the problems their usersmight experience. If we gave out a million demodisks, then we would need to have enough serversto support all those people that actually playthe demo. We didn’t create an infrastructure tosupport a demo mode of FIRETEAM. FIRETEAM isa new type of game—people aren’t yet accustomedto online tactical team games with voicetechnology. We should have made someextra promotional effort to get potentialusers to make that initial leap andtry out the game.The home page for the community web pages. Players canaccess a wealth of information about their statistics or otherplayers’ statistics.2. Managing contractorsFIRETEAM was a large and extremelychallenging project. We had to lookoutside of our own company for helpwith certain parts of the project. Ourmistake was in assuming that theseexperts held the same priorities as therest of the development team. Thesegroups have their own objectives andaren’t expected to understand the bigpicture or know how to create fun

295SECTION V: THE ONLINE FRONTIER295games. We realized that when working withcontractors, we needed to give those contractorsa very precise and clear specification. Because agood game design evolves over the course of aproject, a project manager must constantlymake certain that the contractors are followingthe latest version of the specification.As we were developing FIRETEAM, our attentionwas also focused on growing our new company.We found that it was easy to forget what thecontractors were doing and how they fit into theproject. We made the naïve assumption thatthey would be willing to work with an evolvingspecification. However, when a project is fixbid,an external developer will only do so muchtuning and reworking of code before he or shestarts charging you for it. If you don’t managethis relationship closely, these costs add up veryquickly.For example, the cost for developing the communityweb pages doubled from the originalquote because the design evolved. The final versionof the community web pages was great, buta more thoughtful initial design specificationand better management of the process wouldhave saved Multitude significant money andtime.3. Internet technical issuesWe take the output from 3D Studio Max (with ourplug-ins) and, with our proprietary ZHMPView tool,convert the files to a format that FIRETEAM can read.The Internet poses significant problems fordevelopers. Although we did our best in designingthe game around the limitations of the Internet,we did have some technical problems. Weoriginally designed FIRETEAM around TCP/IPbecause it’s a reliable transport protocol for networktraffic. However, the reliability comes at avery high cost: retransmission times. If a packetis lost on the Internet (which happens a lot), ittakes some time for the machines on both endsto realize this and resend the data. TCP/IP guaranteesthat all packets are in order; therefore, allof the packets after the lost packet will bedelayed until the lost packet is sent again. In afast-paced game such as FIRETEAM, lost packetscan really cause problems.As soon as we started doing real Internet tests,we realized that we needed to start sendingsome packets unreliably via UDP. These packetscould get lost, be out of order, or even duplicated,but they wouldn’t be delayed by otherpackets. We learned that different packetsrequire different sets of reliability and timeliness,and that developers should use all the toolsavailable to them, both TCP/IP and UDP. Weinitially labored under the idea that only one

Multitude’s FIRETEAM 296protocol should be used for the sake of simplicity,but it’s best to use the appropriate tool foreach job.Packet loss and high ping times are simply partof the reality of dealing with the Internet. Youdo your best to deal with these issues, but they’llstill cause you endless headaches as routers overwhich you have no control go down throughoutthe country. Many online games come with a littleutility that does a trace on the route thepackets take between a player’s machine and theservers. The information that the utility returnscan help the player and his or her ISP determinewhere the bad connection is along that route.Developers should be aware that while they cannotfix the Internet infrastructure, it’s importantto understand its limitations and deal with themas best they can.4. Server spaghettiFIRETEAM is a very complicated project withmany processes running on both the client andthe server. Add in the complication of the Internet,and you can get one confusing mess (Figureshows just how complicated the FIRETEAMarchitecture is). We tried to break our servercomponents down into smaller, more manageablepieces, each with its own function. Wehired some experts in various disciplines to helpus better understand parts of the server technologythat were new to us. Our mistake was inthinking that these experts could just come inand solve our problems. As we busied ourselveswith other parts of the project, it was easy for usto say to ourselves, “They know what they’redoing.”In the end, however, the development teamneeds to understand the whole picture and howthe pieces really fit together. One of FIRETEAM’sunique properties is that its server-side componentsrun remotely at an ISP’s facilities. In orderto debug something as complicated as our serverarchitecture remotely, our key programmers—notjust the client/server experts—neededto understand the whole system.5. Coping with the communityAs I mentioned previously, when you create anonline game, you need to embrace the community.At the same time, a direct connection witha community of testers who aren’t 100 percentaware of your objectives is something that needsto be managed very carefully. The testers willalways want something different. When is thelast time you played a game and said, “This isperfect”? I’ve often said that even my favoritegame would be better if it had feature X.Most beta testers are young people who have alot of time on their hands; that’s great for findingbugs, but it can also be a problem becausesome of them lack perspective. All players havean equal voice in the FIRETEAM lobby, so we hadto watch over the lobby constantly because afew testers could ruin the fun for others, even tothe point of instigating a mini-online-riot.From what I can tell, some online game companiessimply ignore their testers’ constantdemands. After the experience of developingFIRETEAM, I must admit that this is a possiblesolution, though not an optimal one. Many ofus on the development team spent many hours

297SECTION V: THE ONLINE FRONTIER297justifying our design decisions in order to educatethe testers on why we were doing things acertain way. While this education does makethem better testers, it takes up a lot of time. Andit’s a dangerous black hole that you can besucked into if you’re not careful.I believe that the true balance is to pay attentionto your community, but sometimes to sacrificethe battle in order to win the war. You shouldinvolve your intended community in the evolutionof your game, but don’t let it take over yourdesign process or time.Evolving Right AlongIn building FIRETEAM, we as developers accomplishedour goal of providing a complete onlinegaming experience with true team play, innovativevoice technology, and extensive communitybuilding tools. The Internet offers brand newgaming experiences; game players can competein ladders such as battle.net or tournamentssuch as the PGL. Also, an online game lets playersmeet new friends with whom they can sharetrue social gaming experiences.However, the Internet introduces a lot of negativesto the gaming experience. Instead of lightning-fastLAN connections, players must nowtolerate latency. Instead of a small group offriends, a player’s opponents may be completestrangers who aren’t polite and may even becheaters.Because of the newness of this market,FIRETEAM may be ahead of its time. Or it maynot have exactly hit the sweet spot that onlinemultiplayer gaming should be. But FIRETEAMhas helped online game evolution along by demonstratingthat voice technology does work andthat team play and community are compellingelements that don’t have to be accidental.

This Page Intentionally Left BlankMultitude’s FIRETEAM 298

299Turbine’sASHERON’S CALLby toby ragainiASHERON’S CALL is a statistical anomaly. In anindustry where cancelled games and dashedhopes are the norm, this project seemed one dayaway from certain failure for nearly its entirehistory. And yet, thanks to the visionary foresightof a handful of people, a healthy dose ofluck, and incredible conviction from both thedevelopment team and publisher, it made it tostore shelves and has received a great deal ofcritical acclaim.In May 1995, I walked into a small suburbanhome in southern Massachusetts and met mynew co-workers. Having left my previous job ata genetics lab, I expected nothing more than aninteresting summer project as “A Game Writer.”Little did I realize what was in store for me andthis start-up company called Turbine. Havingfilled every nook of a residential home with PCs,an enterprising group of about ten developerswas already busy working on the game thatwould one day become ASHERON’S CALL.Although not a single one of them had professionalgame development experience, I wasimmediately impressed with their enthusiasmand dedication. After introductions, I was toldto scrounge around for a desk. Upon securingan end table and a plastic lawn chair, I sat downBack-StoryASHERON'S CALL is the third massively multiplayer persistentonline world to reach the market, although it wasdeveloped in parallel with ULTIMA ONLINE and EVER-QUEST. Like its competitors, it is set in a heroic-fantasyworld, but with crucial differences. It offers a fealty systemthat creates formal links and hierarchies betweenplayers and rewards cooperative play. It also offers episodicnarrative content, periodic new quests, andevents that visibly affect the entire world.and started meeting with various team membersto figure out just what this game was all about.What was described to me was something thatnearly every computer game geek is by nowfamiliar with: a 3D graphical MUD. A persistentfantasy environment where hundreds ofplayers could explore the land, defeat monsters,form adventuring parties, delve into dungeons,and complete quests. I’m not sure why anyonethought it was possible. We had no office, notechnology to speak of, and no publisher. And Iwas being paid $800 a month. Yet from thesehumble beginnings, something truly wonderfulwas created.The development team was divided into functionaldepartments. Tim Brennen, a Brown Universitydropout who had helped develop

Turbine’s ASHERON’S CALL 300Windows NT as a Microsoft intern, led theengineering team and would go on to design theserver, networking, and character database.Chris Dyl, a former physicist turned programmer,would develop the 3D graphics engine andserver-side physics. Andy Reiff, also a Brownalumnus, would later round out the engineeringGame DataRelease date: November 1999Publisher: MicrosoftGenre: Massively multiplayer, online fantasy roleplayinggameIntended platform: Windows 95/98Project budget: multimillion-dollar developmentbudgetProject length: 40 months plus 8 months of betaProject size: approximately 2 million lines of code.Team size: 30+ full-time developers, including 6artists, 4 game designers, 15 software engineers, and5 QA testers.Critical development hardware: Intel Pentium PCsCritical development software: Microsoft Visual C++5.0, Visual SourceSafe 5.0, Lightwave 5.5, Photoshop4.0, RAIDleads as the game systems programmer, responsiblefor implementing all of the game rules systemsand functional interactions in the gameworld. All of the game’s code would be developedfrom scratch. At the time, this was a fairlyeasy decision, since licensable game code waspretty much nonexistent in 1995.On the art team, Jason Booth, a music studentwith experience using Lightwave, would take onthe title of lead technical artist. In this role,Jason bridged the gap between the art andgraphics teams, ensuring that the art asset pipelineran smoothly. Sean Huxter brought his substantialanimation and modeling experience tothe team as the lead artist. My own contributionsto the team were in the area of gamedesign. As the project grew in scope, my rolechanged to become that of lead designer. Soonrealizing the amount of work required to designa game with the scope of ASHERON’S CALL, I puttogether a team of designers that envisioned anddocumented the characters, monsters, history,and timeline of a fantasy world called Dereth. Inaddition, the design team spec’d all of the gamerules and systems necessary to RPGs.Although the team had no professional gamedevelopment experience, one invaluable thingthat the team did have was experience playingMUDs and similar text-based Internet games.Although these games were comparatively simple,the game-play dynamics created in a massively-multiplayerenvironment are extremelydifferent from a single-player game. MUDsproved to be a very useful model for multiplayergaming patterns.ASHERON’S CALL was initially designed to supportjust 200 simultaneous players, each payingan hourly fee. Turbine would host the servers,which were originally going to be PCs runningLinux. Although in today’s market, this soundsludicrous, in 1995 this was in fact the standardpremium online game model. Games using similarmodels, like Genie’s CYBERSTRIKE and AmericaOnline’s NEVERWINTER NIGHTS, were quitesuccessful at the time. Based on this goal, the

301SECTION V: THE ONLINE FRONTIER301original schedule had ASHERON’S CALL shippingin the fourth quarter of 1997.What Went Right1. Staying true to our originalvision of the gameASHERON’S CALL was a ridiculously ambitiousproject for an unproven team. Yet despite thisnaïveté (or more likely because of it), the finalproduct is frighteningly close to the originalgoal of the project. Of course during that time,Turbine learned lessons in feature cutting,scheduling risks, and compromise. But despiteall the missed deadlines, all-nighters, and otherdisappointments, we are able look back on ourshared vision and take pride in that we achievedwhat we set out to do.Typically, there exists a master document thatdescribes the overall game concept and goal.Although the documentation at the inception ofthe game was in fact very sparse, what little thatdid exist described the fundamental architectureof the game, including its client/server model,dynamic load balancing capabilities (describedlater), and 3D graphics. In addition, gameplaydetails such as the allegiance system, magiceconomy, and the emphasis on social game playare in my notes going as far back as 1995. Theteam internalized these goals, and a form of oraltradition maintained them in meetings.Although we didn’t know it at the time, ASH-ERON’S CALL would debut as the third massivelymultiplayeronline RPG amidst two strong competitors,ULTIMA ONLINE and EVERQUEST. We’reoften asked if we made any dramatic changes inresponse to the release of these two titles. In allhonesty, the answer is no. If anything, these twoproducts proved to us that our initial technicaland game design decisions were correct. Clearly,social game play helped drive the success of thesegames. This made our game’s social systems suchas allegiance and fellowships all the more important.It was also obvious that immersion wascritical. Instability and pauses were the bane ofmassively-multiplayer games. In theory, thedynamically load-balanced servers would preventmany of these problems.In an industry that can be driven by holidaydeadlines, marketing hype, and cutting corners,it’s refreshing to know that ambitious goals canstill be rewarded. But it’s more than that. Whilewe certainly could have created a less ambitiousgame, I believe it would have been a detrimentto Turbine’s competitiveness as an independentdevelopment studio. ASHERON’S CALL mighthave shipped earlier had it been a LAN game ora series of connected arenas, but we would nothave the innovative technology and game designexperience that today puts Turbine in such adesirable competitive position in the industry. Inthis way, our team’s unwavering vision washandsomely rewarded.2. Securing a publishingagreement with MicrosoftIn mid-1996, representatives from the newlyformedMSN Gaming Zone were booed by theaudience of the first Mpath Developer Confer-

Turbine’s ASHERON’S CALL 302ence. Their crime was the prediction thathourly fees were dead and that flat monthlyrates would become standard. Our businessplan at the time counted on an hourly model,but we recognized the truth to the Zone team’sstatement. At that year’s E3, we relentlesslypursued Jon Grande, product planner on theZone, in order to pitch him our game proposaland show him our technology demo.At that time, the demo consisted of two PCsconnected to each other. One was running theclient software, complete with 3D graphics. Theother was the server executable. The Zone teamwas very impressed, and scheduled a visitto our office (we’d since moved into anactual office space south of Boston). Soonafter the visit, Microsoft agreed to enterinto a publishing agreement with Turbine,secured initially with a letter of intent.The actual contract arrived six monthslater, but the letter of intent granted us aninitial milestone payment and enough certaintyto schedule the milestone deliverables.This was the start of a long, sometimestumultuous, but ultimately fruitful alliance.After we secured the contract, thedivision of labor was discussed. As the developer,Turbine was to design the game, engineerand implement all of the code, generate all artassets, create a QA plan, and perform testing onall game content. With its pre-existing Zoneplatform, Microsoft was responsible for codetesting, billing, and ongoing server operations.Fundamentally, this meant that while Turbinewould create the game, the day-to-day operationsof the ASHERON’S CALL service would beentrusted to Microsoft.One thing that Turbine successfully negotiatedfor was the rights to our source code. Besidesthe team, we knew that our massively-multiplayertechnology was going to be our singlemost valuable asset. In addition, we agreed to aone-title deal that gave us the flexibility to pursueother development deals as opportunitiesarose. In this way, we ensured that Turbinewould remain independent and effectively incontrol of our own destiny.In many respects, Microsoft proved to be anideal partner for Turbine. Like Turbine, theZone was a start-up organization, and waseager to prove itself. The Zone was pioneering anew type of business, with a business model newto Microsoft, and this placed the managers ofthe Zone in a position where they could affordto take risks. And while ASHERON’S CALL ulti-

303SECTION V: THE ONLINE FRONTIER303mately validated Microsoft’s belief in Turbine,at that point Turbine was certainly a risk.Besides the obvious funding issue, Turbine benefitedfrom its partnership with Microsoft inother ways. We had free access to Microsoftdevelopment tools like Visual C++, VisualSourceSafe, and a bug-tracking database calledRAID. We learned a lot about professional softwaredevelopment from Microsoft as well, suchhow to create an efficient build process, managecode source trees, and organize effective testcycles on the daily builds.generalized enough that they could be reused indifferent massively-multiplayer titles. At thetime, this was an unusual premise for a gamedeveloper; typically, source code was thrownout at the end of a project, and the idea oflicensing a 3D engine like QUAKE was still along way off. From our perspective it just madegood business sense to leverage our R&D asmuch as possible.Finally, we gained prestige by working with oneof the most respected software companies in theworld. Having Microsoft as a partner gave us alot of credibility and put us in a much betterposition to pursue funding and make criticalhires, two incredibly important objectives for asmall startup company.3. Reusable engine and toolsMassively-multiplayer games require a fundamentallydifferent architecture from that of single-playergames, or even multiplayer LANgames. Beyond the graphics engine, user interface,and other elements of a typical game, persistentmassively-multiplayer games generallyrequire a centralized server, networking layer,user authentication, game administration tools,and a host of other technologies.Early on, Turbine recognized that many of thesetechnologies would be required by any massivelymultiplayer game, and could perhaps beSince so much of our development budget wasdevoted to creating these key technologies, wemade every effort to keep the technology modularand data-independent. This modular architecturehas since proven to be a tremendous winfor Turbine. We’ve been able to prototype newgame concepts rapidly by changing data whilekeeping the server executable nearly unchanged.Not only has this helped us get new business, ithas also proven to be extremely useful for inhouseplay testing and constructing proof-ofconceptdemos.

Turbine’s ASHERON’S CALL 304Currently we are investigating the potential oflicensing our technology. While we continue toadvance the code base, we have placed someemphasis on productizing the Turbine engine.From a business perspective, this is a very desirablesource of revenue. We can leverage ourR&D efforts and developmentcosts, while advancingthe engine that ourown future products willuse.In addition to the abilityto reuse code, Turbine’smodular emphasisextended to the way contentis created for thegame world. As developmenton ASHERON’S CALLprogressed, we quickly came to realize that populatinga game world the size of Dereth wasgoing to be a monumental task. By this time, weknew our competitors were hiring teams todesign individual levels and create content manually.This seemed less than optimal to us, andfurthermore we didn’t have the resources to hirea large content team.Instead, we created a series of world-buildingtools to maximize our efforts. The first kind oftool allowed artists to create vast chunks ofgame environment (represented as a grayscaleheight map) with each stroke of their brush.Random monster encounters and terrain featuressuch as trees and butterflies could also beplaced using this method.We also developed a tool called Dungeon Makerto create subterranean environments such asdungeons and catacombs. Early on, Jason Boothgot sick of hand-modeling the complex leveldesigns he was getting from the design team, sohe and user-interface programmer Mike Ferriercreated a level-buildingtool that used an intuitivedrag-and-drop interface.This allowed nontechnicaldesigners the ability tocreate and instantiatedungeons quickly withouttaking up the art team’svaluable time.An offshoot of DungeonMaker, World Builder,became a much moreadvanced tool by the time ASHERON’S CALLshipped. Using World Builder, a contentdesigner could wander around the game worldplacing houses, decorations, and monsterencounters, and even raise and lower the terrain.This proved to be an incredible timesaver,and the amount of landscape content we wereable to generate easily quadrupled. This kind oftool modularity allowed us the ability to updatethe game world easily with new content, such asnew monsters, quests, items, and adventurelocations.Thanks to monthly content additions, ASH-ERON’S CALL “events” can propel an overarchingstory forward and involves players in allareas of the games. So far these events haveproved to be a huge success. Players feel likethey are part of a living, breathing world, and

305SECTION V: THE ONLINE FRONTIER305are more likely to stay involved in the game forlonger periods of time.4. Painless launchWhen the first few thousand players beganpouring onto the production servers, we werecertain that there would be all sorts of catastrophes.We had watched our competitors suffersimilar calamities, and we had resigned ourselvesto accept this rite of passage. To our surprise,nothing went wrong the first day. We weredelighted by just how stable and uneventful theretail launch was. Everything went without ahitch. This stability was due to effective betatesting, intelligent project management, andinsightful data-center equipment deployment.Here’s how it worked. During beta, bothMicrosoft and Turbine testers submitted bugsinto RAID. In addition, user-submitted bugswere tracked by the Microsoft team and wereadded into RAID if they were deemed important.Server performance metrics were one ofthe key goals towards meeting our shippingrequirements. Each server had to maintain aminimum level of performance, given a concurrentuser base of 3,000 players. To meet thismetric, a few changes were in order. The serversidephysics was modified to use a more simplifiedcollision model. In addition, a faster “cleanup”cycle for objects dropped on the landscapewas implemented.Having made these changes, we were able tomeet the aggressive server metrics and ourserver software has since proved to be nearlybulletproof. In fact, for the first several weeks,the server software did not crash once, whichwas a major accomplishment, considering thetechnical problems evident in other massivelymultiplayergames.Our retail launch was a staggered affair. Initially,only two “enthusiast-oriented” retailchains received shipments of ASHERON’S CALLboxes. This allowed our die-hard fans from thebeta testing program to get copies, but preventedthe deluge that would have occurred hadwe been in the larger, more mainstream retailstores. While it would have been exciting to seemassive sales on day one, I believe that thisgradual approach was a smart move.5. Seamless environment usingdynamically load-balancingserversOne the most impressive features of the Turbineengine is the continuous outdoor environment.This is made possible thanks to dynamic loadbalancing, which is a scalable server-side architecture.The easiest way to appreciate the needfor dynamic load balancing is to consider thefollowing scenario. Imagine a hypothetical gameworld that is divided into four servers, each ofwhich corresponds to a geographic area in thegame world. With a static server architecture, ifeveryone in the game world decides to go to thesame area, that one server’s performance wouldbe dramatically impaired, while the threeremaining servers would effectively be idle,completely unaware of their overtaxed brother.Dynamic load balancing solves this overloadedserver problem. Instead of assigning a static geo-

Turbine’s ASHERON’S CALL 306graphic area to each server, the individual serverscan divide up the game world based on therelative processor load of each server. In the previousexample, instead of remaining idle, allfour servers would divide the load equallyamong themselves, ensuring the most efficientuse of the hardware’s processing capacity.Dynamic load balancing allows a very free-formenvironment where players can travel whereverthey want with very few hard-coded limits.But in order for the graphics engine to accommodatethe seamless nature of the server, wecouldn’t allow the “level loading” pause typicalin many 3D games to interrupt the game play.To avoid level-loading, the geometry teamheaded by Chris Dyl engineered a unique renderingengine that constantly loads data in thebackground, and draws objects at far enoughdistances so as to minimize obvious “popping”effects and without having to rely on a foggingeffect to hide the clipping plane.What Went Wrong1. Poor scheduling andcommunicationFor most of its early history, ASHERON’S CALLwas the victim of poor project management.During the last year of development, a managementreorganization took place that salvagedthe project. Depending on how far back youlook at the schedules, ASHERON’S CALL waseither one to two years late. This is attributableto a number of reasons, some of which I willexplain momentarily.When Microsoft and Turbine entered into thedevelopment agreement, neither side had anyidea of the scope of the project. An initial list ofmilestones was drawn up by the Microsoftproduct manager and our development leads.Unfortunately, after the second milestone, deadlineswere consistently missed. A lot of this wasdue simply to underestimating the time requiredfor development tasks. This created a dominoeffect as we continually played catch-up, tryingdesperately to make up for lost time.This schedule free-fall continued into 1997 andforced us to re-evaluate the feature set. Unfortunately,feature cuts were made without consideringthe impact on the playability of the game.Ultimately, most of these features were addedback into the game anyway, which took additionaltime due to the reallocation of teamresources. The lesson here concerns the value ofeffective scheduling. Identify the risky areas inyour schedule early, figure out the dependencies,and make sure you pad the time estimates fortasks.Communication between Microsoft and Turbinewas also a major factor. The teams wereseparated by about 3,000 miles and three timezones. Although weekly conference calls werescheduled, they lacked the collaborative mentalitynecessary for maintaining a successful relationship.E-mail threads were either ignored orelse escalated into tense phone calls, and insome cases the bug-tracking database (RAID)was not used effectively. Clearly, everyone

307SECTION V: THE ONLINE FRONTIER307would have benefited from moreface-to-face time. E-mail—and evenconference calls—are poor media formanaging new and sensitive corporaterelationships, especially onesbetween companies with such differentcorporate cultures.From a developer’s perspective, it’salways easy to blame the publisherfor unrealistic expectations andbureaucracy. What’s important torealize is that it is everyone’s obligationto communicate expectationsand problems before they escalate tothe point of being a crisis.2. Inexperienced developmentteamNone of the senior developers at Turbine(including me) had ever shipped a retail PCgame. None. Many of the employees were studentsimmediately out of college, or even collegestudents completing a work-study program.This obviously was the source of several severeproblems in the development of ASHERON’SCALL. It was nearly impossible for team leads togive realistic schedule estimates for tasks, sincefew of us had experience in professional softwaredevelopment. It was also initially difficultto get different teams from the programming,art, and design departments to communicateregularly with each other.The collegiate atmosphere made it very difficultfor decisions to be made; meetings would happenand resolutions would seemingly be agreedupon, only to have those same questions askedin a subsequent meeting. No one likes unnecessarybureaucracy and giving up creative freedom,but ultimately one person needs to begiven the authority to make a decision and holdpeople to it. A good supervisor takes intoaccount the opinions of everyone involved;design by committee simply does not work.Obviously, having a seasoned and experienceddevelopment team has innumerable advantages.While it’s not critical that everyone on the developmentteam have professional experience, atthe very least team leads should have some formof professional experience. As it was, Turbinehad to get by with raw talent, unabashed enthusiasm,and simply not knowing any better.3. No feature iteration duringdevelopmentMany weaknesses of ASHERON’S CALL at launchstemmed from the methodology we followed for

Turbine’s ASHERON’S CALL 308feature completion. Features were scheduled bymilestone and were expected to be completed intheir entirety before other features were workedon. While this approach may work for moretypical software applications, PC games rely ona host of interrelating systems that cannot beimplemented in a vacuum.An example of this involved our melee combatsystem. This game feature was completelyspec’d and implemented long before magicspells worked within the game, under the misguidedassumption that it saves developer andtest resources not to have to revisit completedfeatures. Clearly, these two game systemsneeded to be tested and balanced in stagesalongside each other, not independently.Another example of this problem occurred duringbeta testing. A massively-multiplayer gamecannot be considered adequately tested untilthousands of players have participated in thegame world for at least a few months. The firsttime ASHERON’S CALL was exposed to this manyusers was when it went into beta testing.Unfortunately, we were placed in a codefreeze situation during the beta test, andonly the most serious bugs were fixed.projects, Turbine is deploying a more iterativeimplementation process where rapid prototypingand early play-testing is encouraged.4. An ambitious project lackingfundamental underlyingtechnologiesAs one of the first massively multiplayer 3Dgames, ASHERON’S CALL was a bold undertaking.Several core components were still theoreticalwhen the project was planned. Things likedynamically load-balanced servers and continuous,uninterrupted outdoor environments werestill unproven concepts when we committed tothem for ASHERON’S CALL. Furthermore, wehad to create our own 3D graphics engine, alatency-friendly network layer, and physics andgame rule systems that would all work within aclient/server model.We learned very quickly why there hadn’t been agame like ASHERON’S CALL before us: It wasdamned hard to develop such a game. I don’tBoth Microsoft and Turbine recognizedmany serious game balancing problemsduring beta, but at that point it wasextremely difficult to make changes. Thiscan be attributed to our tight schedule,but earlier beta tests would have acceleratedthe bug-finding process and resultedin a better balanced game. On future

309SECTION V: THE ONLINE FRONTIER309think committing to a less aggressive feature setwas the right solution, though. Instead, weshould have acknowledged up front that R&Defforts are fundamentally hard to schedule, andbeen more flexible with our development schedule.With this in mind, we could have createdmore realistic estimates and done a better jobmanaging expectations within and outside Turbine.5. No documented high-levelfeature statementBecause ASHERON’S CALL had such a long andevolving development cycle, it was difficult tokeep all the documentation up-to-date. To compoundthe matter, the project never had an officialfeature set as part of the developmentcontract with Microsoft. The technical designdocument process and high-level feature overviewswere basically skipped. This createdsevere problems when it came to prioritizingwhich features were important. We constantlyhad to justify features, and we had no documentationto fall back on to resolve our discussions.Without a high-level vision statement it was alsovery difficult to educate new employees aboutthe game. There was a sort of oral tradition toinitiate new employees that had been passeddown for so long that it just became part of ourcompany’s culture. This was partially possiblebecause the concept of a 3D graphical MUDintuitively made sense to a lot of people. Unfortunately,it was very difficult to explain whatASHERON’S CALL was about to people whodidn’t understand this concept or had their ownideas about how things should be done. Havinga documented vision statement and a descriptionof the high-level feature set is absolutelyessential for any title.A Unique CompanyRésuméASHERON’S CALL was a tremendous learningopportunity for Turbine and Microsoft. Despiteall the problems and setbacks, ASHERON’S CALLis a success story. The game has been wellreceived by PC game enthusiasts as well as themajority of the game industry press. The fansupport for ASHERON’S CALL is overwhelming,and players routinely spend more than six hoursa day logged into the game world. In addition,Turbine is now in a very desirable position,being one of only a handful of developers (andthe only independent studio) that has successfullycreated a massively-multiplayer title.Industry analysts predict that online games willbe the fastest growing segment of entertainmentsoftware. With its reusable architecture, robusttoolset, and (now) experienced developers, Turbineintends to remain at the forefront of massively-multiplayergaming.

310AFTERWORDIndependent GameDevelopmentBy now it’s a commonplace observation thatthe game industry has become more conservative,that games have become less interesting,more stereotyped, less original, less willing totake risks. This development coincides with atrend towards consolidation: large publishingconglomerates have bought out many of thesmall independent developers. These conglomeratesmake money by cranking out sequels andcopycat products rather than truly interestingand innovative creations. As a result, each yearE3 is crammed with the same old games withnew names and the latest graphical bells andwhistles.One response has been to look for freshness andinspiration outside the corporate environment,from independent game developers, hobbyists,students, and mavericks who can try out newideas without focus groups or corporate bureaucracy.A clear analogy exists to the resurgence ofindependent filmmaking in the 90s that popularizedthe Sundance Festival and created a sense ofan independent movement, a rough, edgy, originalstyle to counteract the big-budget slicknessand comfortable predictability of mainstreamHollywood productions. This style then filteredback into mainstream moviemaking and helpedrevitalize the medium. It’s one of the venerableRomantic myths of art—Outsiders vs. The Man,creative renewal from the margins—and additionallyit’s often true. We’ve seen it in music(think of the punk, DIY, and grunge movements)to painting (salon des refusés) to literature(the Beats).Can independent game development do thesame? No reason why not—the video gamesindustry is still in pretty close touch with itshobbyist roots. Independent game developmentis proceeding on any number of fronts. Indiegame development happens all the time,although it doesn’t always get the attention itdeserves. Alone or in groups, students, hobbyists,and coders crank out shareware and freewaregames, either for money or in response to

311Afterword: Independent Game Developmentsome burning interior impetus. Some games,such as NETHACK (http://www.nethack.org),have existed for decades. NETHACK was born inthe age of university-based mainframes and hasgrown by accretion over the years, as peopleadd new features to this sprawling, rich dungeongame. Most exist virtually unknown orwith underground fan bases. A few games, suchas PONTIFEX (http://www.chroniclogic.com), havewon cult followings, even within the gameindustry itself, but cannot be said to have had awidespread influence.One problem for the indie scene is that with risingstandards in production values, indie gamescan’t match the lavish graphics and sound andprogramming finesse of mainstream games.Even when they have solid, original gamemechanics, they can look clunky next to the latestmultimillion-dollar fantasy epic. Tools suchgame editors, Shockwave, and Director havemade it possible to produce professional-levelwork on a relatively independent basis, but itremains to be seen whether digital gaming willbecome a medium too expensive to support anindie sector.A prominent sector of indie game developmentthat has undoubtedly influenced the mainstreamis the mod community—game fans who tinkerwith existing games, creating new levels,objects, characters, and rules, downloading editingtools or writing their own. This phenomenonbegan in the first days of computer gamingand took root in the fertile soil of the Internet,especially for games such as DOOM where themultiplayer component encouraged communityand peer-to-peer exchange rather than solitaryplay. Industry powerhouses, such as id Software,led the way in providing tools for the modcommunity to change and expand the gamesthey wrote, while websites, such as Blue’s Newsand Planet Quake, became gathering places forfans to trade tools and new game levels. Plentyof ideas, such as Capture the Flag and otherteam-based games, have made their way frommod community web sites into shipping products.Likewise, fans who began by making theirown levels for their favorite games have endedup with game-industry jobs.The Interactive Fiction movement has taken thetext-adventure, which is now extinct commercially,and made it a thriving amateur concern.Text adventures aren’t competitive in the marketbecause they don’t display any pretty movingpictures, but this doesn’t mean they aren’t artisticallypowerful or outmoded. Dozens of newtext adventures appear every year. The mediumhas numerous advantages for indie development—it’sa stable technology, costs little toproduce, and new works can be written, revised,and released in relatively little time by a singleauthor. As a result, the IF movement has a thrivingavant-garde that puts the mainstream industryto shame.The game industry has begun to reach outactively to the independents. The annual GameDevelopers Conference now showcases thefinalists of the Independent Games Festival(http://www.igf.com), an annual Sundance-likeevent for games developed outside the ranks ofthe major publishers, with a separate categoryfor student work. The results are typically lowbudgetaffairs but based around a solid original

Afterword: Independent Game Development 312conception, and the event is getting bigger everyyear. Another sign of interest is the Indie GameJam (http://www.indiegamejam.com), an annualevent begun in 2002 that brought 14 professionaldevelopers together for four days to hacktogether as many different games as possiblebased on a single piece of technology, the ideabeing to encourage originality and brainstormingoutside the usual corporate production process.The first Jam was a success—12 wildlydifferent games resulted and were displayed thefollowing week at GDC as part of the ExperimentalGames Workshop. As a movement andan ethos, independent game development isbeginning to exist.That having been said, it would be premature toabandon hope for mainstream game production—topoint to an independent scene as theonly source of creative renewal is too simple anidea. The line between indie and corporate isblurrier than the romantic myth would make it.Like a shape-shifting alien on Star Trek, thegame industry has two sets of cultural DNA,partly corporate, partly devoted amateur, whichis one of our great strengths. Our medium hadits genesis among amateurs and entrepreneurs,and that generation is still part our industry,making it hard to tell who is definitively indieand who isn’t. The industry has only veryrecently become big and static enough to makepeople worried—until a few years ago, therewasn’t enough of a mainstream to warrant anidea of an independent scene.The medium is still changing too rapidly todeclare the death of all originality. We’re constantlyadjusting to a dozen new ideas at once.The Internet, the trend toward licensed middleware,massively multiplayer gaming, and theoverall breakneck pace of technological changeare still transforming gaming faster than we canfollow. We can’t tell if we’re in a downward spiralor just a temporary retrenching.The independent scene is a place from which todraw inspiration and ideas to reform our workand our production processes, a source of ideasrather than a magic bullet. It’s important toremember that great work can come from anywhere—wehave only to look at classic WarnerBrothers cartoons and Golden-Age Hollywoodfilm (to say nothing of Shigeru Miyamoto’s oeuvre)to find examples of brilliant work that camefrom the mainstream. They came from peoplewho loved their work and also understood theirart form and how to work together to produceit. Like them, we’re in the incredibly fortunateposition of being part of the next great entertainmentmedium. By learning from oneanother, examining our successes and failures,and never being satisfied with the status quo, wehave the opportunity to do as well.

313APPENDIX AGAME DEVELOPMENT TEAMROLESThe age of the single-author game is more orless over, and game production has been splitinto discrete jobs. As an industry, we haveinvented terminology to describe the differentmembers of a development team. This hasturned out to be a devil’s bargain—job titles aregreat because they tell you who’s responsible forwhat kinds of tasks, but they also tend to givepeople the misconception that everything outsidetheir job description is none of their business.One of the lessons that repeat throughoutthe postmortems is how important it is for theentire team to understand what the game is andbe able to contribute ideas on any subject. Otherwise,the abilities of the team aren’t reallybeing put into play.Every one of these descriptions is an oversimplification.In practice, game development jobsshape themselves to the needs of the project andthe skills of the person doing them. The sharplines within art, programming, design, audio,writing, and management that seem to exist ona spreadsheet, don’t exist at all—every one ofthese jobs has technical, artistic, and gamedesignareas. That said, here is a rundown ofcurrent industry job titles and what they, basically,mean:ArtistThis is the broad category of workers who createthe graphical content for a game. It caninclude anything from a concept artist to a 3Danimator to an architectural consultant; fromartists make cut-scenes, walking animations,3D furniture, wall-textures, landscape geometry,fake newsreel footage, and a thousandother things. Although technical expertise isalways a plus, the actual requirements vary. Aconcept artist might work only with paper andpencils, whereas a technical artist might spend90% of their time hacking file formats andwriting custom plug-ins for a commercialgraphics package.

Appendix A: GAME DEVELOPMENT TEAM ROLES 314As with all game industry jobs, this one blursinto the others. Designing natural-looking terraingeometry and realistic architecture blursinto level design; creating interface buttons blursinto interface design; writing 3D Studio plug-insblurs into tools-programming; crafting texturesto look correct in a 3D world requires understandingrendering algorithms; and so on.AudioLong neglected, audio is now one of the fastestgrowingareas in game production. Two reasonsare that exciting new audio technologies areemerging and people are paying attention togames as complete entertainment experiencesrather than just graphical displays. Sound andmusic are tools for giving virtual worlds richness,character, and emotion—tools we’re juststarting to take advantage of.Audio departments divide roughly into soundengineers and composers. Sound engineersdesign the audible world of a game—the voiceof a character, the chunky click of a weaponreloading, the tread of a shoe on dry leaves orcold marble, much as a foley engineer in the filmworld. They supervise recording sessions andengage with emerging audio technologies, suchas 3D sound and voice synthesis. Composersscore the game, working inside the technicalconstraints of the computer and the formal constraintsof interactive media. If emotion is aproblem area for computer games, music mightbe one of the most powerful solutions.DesignerThis job is the hardest to pin down and the mostvariable between different projects, companies,and designers. It is perhaps most correct to saybroadly that game designers craft the player’sinteractive experience using tools that artistsand programmers make—they make the fun.Typical design tasks include laying out the gameinterface, building the level maps, designingpuzzles, balancing units’ abilities to create agame that is both fair and challenging. Designersoften double as the game’s writer for storyand in-game dialogue and text, althoughincreasingly this profession is becoming separate.In some teams, the lead designer is like anauteur film director. They have the initial visionfor the game; they write the overall design documentand the story. Later in the developmentprocess, this initial game concept is a touchstonefor determining priorities. Other designers workas a kind of caretaker for a group vision of thegame—they hear all the suggestions, recordthem, and turn them into a full design documentfor the game. They make the final decision onsome issues, but the design doesn’t start withthem. The design starts from a company’s overallstrategy decision, an existing game engine, ora team vote.Designers often have specialized skills in arelated field, such as writing, graphic design, orprogramming, and this issue shapes how theymesh with the rest of the team. Some technicalknowledge is always necessary, so that the

315Appendix A: GAME DEVELOPMENT TEAM ROLESdesigner understands the tools of their trade andwhat a computer can and can’t do.ProducerProducers are the ones who manage projectteams as a whole. They are in charge of projectmanagement issues, such as schedules, budget,morale, and coordinating different sections of aproject team. They host meetings, facilitatecommunication, resolve problems, and acceptresponsibility for the product as a whole.Leadership styles vary. Some producers viewthemselves purely as administrators—they makesure the schedule and budget work correctly,and coordinate the team’s efforts, but leave thecreative vision to a project leader or the design,art, or programming lead. Other producers arethe keepers of the product’s overall concept andserve as creative director and final decisionmakeron the product’s feel.Producers also serve as a liaison to companymanagement and publisher concerns. Theymake sure a given product meshes with overallcompany strategy and integrate marketing andlocalization efforts into the project team’s work.Likewise, they represent the team’s progress andneeds to upper management—if the project islate or there’s a problem with working conditions,the producer brings the news up the chainof command.ProgrammerProgrammers write the software that comprisesthe game engine and the tools the team uses toproduce the product. Game programmers oftenspecialize in a game subsystem, such as graphics,networking, audio, or AI, or on tools programming,creating things, such as game editors andexporters.It’s easy to see programmers as pure technicians,but as much artistry exists on the programmingside as anywhere else—any truly great game is amarriage of creative vision with technical decision-making.An AI programmer creates one ofthe core elements of the game experiences—theopponent or ally who shares the world withplayers, who competes or fights or bonds withthem. Likewise, coding a good game editormeans understanding designers’ needs and priorities,as well as the designers themselves. Programmershave to make decisions daily thatrequire an overall understanding of the gamevision.The earliest games were entirely programmerwritten,and some programmers see this time asthe golden age—games created by people whothoroughly understood the limitations andstrengths of the machine and the programs thatran it. That era is past, but programmers noware still the team members who can convey thatunderstanding to the team as a whole.Quality AssuranceThe quality assurance (QA), or playtest department,tests the finished product (or work-in-

Appendix A: GAME DEVELOPMENT TEAM ROLES 316progress) to see that it works the way it’sintended to. Sadly, this job frequently puts theteam members in the position of bearers of badnews—“don’t shoot the messenger” might bethe unofficial motto of every QA department inexistence.The official QA mandate is to make sure theproduct does what it’s supposed to do. Theycheck, in excruciating detail, every feature andevery level of the game, in every combinationimaginable. This process includes checking inevery language the game ships in and on everyreasonable configuration of hardware and operatingsystem, in PC products.The unofficial QA role is that they tend to knowthe game better than anyone else on theteam—no one else is in contact with the actualproduct, 40 or 60 or 80 hours a week. QA oftenhas the best view of what’s actually happeningto a product and is best qualified to comment onintangibles: is the game fun and does it correspondto the initial vision. In the best case, QAcan become creative collaborators rather thanjust bug-reporters, reporting on how the gamefeels and plays, rather than just working from achecklist.

317Glossarycut-scene a non-interactive animated presentation,played back from prepared data ratherthan generated dynamically; usually used asintroduction and conclusion for a game, also forproviding narrative exposition and, as a graphicspectacle, rewards for accomplishment.data game content, such as terrain geometryor spoken dialogue, as distinct from the softwareused to manipulate and display it; contrastengine.DDA Dynamic Difficulty Adjustment; a game’sability to react to player performance byincreasing or decreasing the level of challenge.deathmatch a charming neologism coined forplayer-versus-player modes in first-personshooter games; later broadened for use in othergenres, such as real-time strategy games.E3 Electronic Entertainment Expo; the annualtrade show for the game industry, held in lateJune; games often get their first public showingat E3, hence the importance of the E3 demo inmarketing a game.engine core systems that, taken as a group,display the game environment and enact itsbasic functions; as distinct from data.exploit particularly in online games, a flaw inthe game that players can use to gain disproportionateadvantages and rewards.first-person shooter popular genre of game, inwhich players navigate a 3D world full of enemies;players view the world through a cameraset at head height (hence the name), which alsoserves as a gunsight. Id Software’s CASTLEWOLFENSTEIN 3D is perhaps the first example.first-person sneaker term coined to designategames in first-person perspective, where stealthis more important than combat in achievingplayer goals. Looking Glass Studios’ THIEFseries is perhaps the prime example.gameplay vague word denoting what playersdo in a game, the activities and challenges, asdistinct from the technology and artwork thatsupport these.

Glossary 318GDC Game Developers Conference; an annualmeeting of game developers to present and discusstheir experiences in game creation.level a unit of game data usually correspondingto one stage of a game, or a virtual location(e.g., a floor of a building); also, a game character'srank in a graded scale of power.MMPOG Massively Multiplayer PersistentOnline Games; multiplayer games involvingthousands of players, whose characters arerecorded and change over time.motion capture a technique of recording animationfrom a real-life source.patch a piece of software that fixes problemsin a product that has already been shipped, correctingbugs and adding missing features.renderer software that draws a scene procedurallyfrom a set of data, rather than replayingframes of animation.RPG Role-Playing Game; an early term forpaper-and-dice-based fantasy games, later translatedinto a genre of computer games retainingthe conventions of the original; as exemplifiedin, for example, the ULTIMA and WIZARD seriesof games. Alternately an acronym for rocketpropelledgrenade.RTS Real-Time Strategy; a genre of game thatdepicts large-scale military conflicts in continuous-runningaction, as contrasted with turnbasedgames; Westwood’s DUNE II was thefounding example.sandbox a game whose interest derives fromthe amusement value of a complex, dynamicsimulation, which relies on player creativityrather than pre-set goals or narrative.texture a 2D piece of artwork, applied to thesurface of a rendered polygon to give it addeddetail and color; often called a skin whenapplied to a character model.turn-based divided into discrete rounds thatadvance when certain conditions have been met(for example, all players have moved theirpieces).waterfall development model a software productionprocess that works by first assessing therequired functions, then breaking them intomodular subsystems, writing them, integratingthem, testing that they fulfill the specified functions,and shipping. Generally held to be goodfor large, well-understood systems but less effectivefor projects requiring high efficiency andfunctional innovation.

319Index of Game Titles & Developers 319Index of Game Titles & DevelopersAAbandon EntertainmentDARK AGE OF CAMELOT 278–285AGE OF EMPIRES 63–73, 103, 115RISE OF ROME EXPANSION PACK 115AGE OF EMPIRES II: THE AGE OF KINGS115–125ALIENS ONLINE 277America OnlineNEVERWINTER NIGHTS 300ANACHRONOX 207ASHERON’S CALL 299–309BBARBIE FASHION DESIGNER 149BLACK & WHITE 151–160Blizzard EntertainmentDIABLO 287DIABLO II 61, 79–90Bohemia Interactive StudiosOPERATION FLASHPOINT 19–28BRITISH OPEN CHAMPIONSHIP GOLF 6, 173Bungie SoftwareMYTH: THE FALLEN LORDS 161–169CCARTOON MAYHEMSEE CEL DAMAGECEL DAMAGE 41–50CIVILIZATION 63COMMAND & CONQUER 103–104, 106–108COMMANDOS 172CRASH BANDICOOT 209, 211CRASH TEAM RACING 212CYBERSTRIKE 300DDAIKATANA 207, 256DARK AGE OF CAMELOT 277–285DARK FORCES 54DARK ZION 282DARKNESS FALLS: THE CRUSADE 278DAWN OF MANSee Age of EmpiresDEFENDER 289DEUS EX 180, 195–207DEUS EX 2 202DIABLO 287DIABLO II 61, 79–90DOMINANT SPECIES 254DOOM 30, 169DRAGON’S GATE 278DRAKAN: ORDER OF THE FLAME ??–40DUNE 2 103, 105–106, 221DUNE 2000 110DUNGEON KEEPER 151, 156EEidos InteractiveCOMMANDOS 172DEUS EX 180, 196–207DEUS EX 2 202Electronic ArtsSYSTEM SHOCK 2 6–17Ensemble StudiosAGE OF EMPIRES 63–73, 103, 115RISE OF ROME EXPANSION PACK 115AGE OF EMPIRES II: THE AGE OF KINGS115–125Epic GamesUNREAL TOURNAMENT 91–102, 201–202,205EVERQUEST 277, 301

INDEX OF GAME TITLES & DEVELOPERS 320FFALLEN AGE 282FIRETEAM 287–297FLIGHT COMBAT 181FLIGHT SIMULATOR 154FLIGHT UNLIMITED 5, 173FRONT PAGE SPORTS: BASEBALL 290GGALAXIAN 289Genie’sCYBERSTRIKE 300GOLDENEYE 176, 220GRIM FANDANGO 57HHALF-LIFE 9, 15, 172, 256HERETIC 261HERETIC 2 237, 262HEXEN 261IINDIANA JONES AND THE INFERNAL MACHINE224Ion StormANACHRONOX 207DAIKATANA 207, 256DEUS EX 180, 195–207Irrational GamesSYSTEM SHOCK 2 5–17, 175, 181JJAK & DAXTER: THE PRECURSOR LEGACY209–217JEDI KNIGHT 51, 57THE JOURNEYMAN PROJECT 127JUNCTION POINT 197JUSTICE LEAGUE TASK FORCE 80LLionhead StudiosBLACK & WHITE 151–160Looking GlassBRITISH OPEN CHAMPIONSHIP GOLF 6, 173THIEF: THE DARK PROJECT 5, 7, 10, 13,171–181LucasArtsDARK FORCES 54STAR WARS STARFIGHTER 223–235MMAGIC SCHOOL BUS 289MARATHON 161Mattle MediaBARBIE FASHION DESIGNER 149METAL GEAR SOLID 172MicroProseCIVILIZATION 63MicrosoftASHERON’S CALL 299–309MultitudeFIRETEAM 287MYST 127–128, 149MYST III: EXILE 127–135MYTH: THE FALLEN LORDS 161–169Mythic EntertainmentDARK AGE OF CAMELOT 277–285DARKNESS FALLS: THE CRUSADE 278NNaughty DogCRASH BANDICOOT 209, 211CRASH TEAM RACING 212JAK & DAXTER: THE PRECURSOR LEGACY209–217NEVERWINTER NIGHTS 300Nihilistic SoftwareJEDI KNIGHT 51, 57VAMPIRE: THE MASQUERADE—REDEMPTION51–62

321Index of Game Titles & Developers 321OOperation Flashpoint 19–28PPAC-MAN 289POLITIKA 254Poptop SoftwareTROPICO 137–146POPULOUS 151Presto StudiosTHE JOURNEYMAN PROJECT 127MYST 127–128, 149MYST III: EXILE 127–135Pseudo InteractiveCEL DAMAGE 41–50QQUAKE 7, 14, 53, 93, 96, 176, 180, 251, 287QUAKE 3: ARENA 96–97, 99–100QUARTERBACK CLUB 80RRAILROAD TYCOON 137RAILROAD TYCOON II 137, 141THE SECOND CENTURY expansion pack 137RAINBOW SIX 251–258, 266RED ALERT 103, 106, 108–110RED ALERT RETALIATION 110Red Storm EntertainmentDOMINANT SPECIES 254RAINBOW SIX 251–258, 266REDEMPTIONSEE VAMPIRE: THE MASQUERADE—REDEMPTIONRIVEN 127–128, 130–133, 135ROGUE SQUADRON 223–224, 228ROLLERCOASTER TYCOON 142S7 StudiosDEFENDER 289SHADOWBANE 282SIN 256SOLDIER OF FORTUNE 237, 246, 259–271Tactical Non-violent Version 263–264Sony Computer EntertainmentJAK & DAXTER: THE PRECURSOR LEGACY210–217SPELLBINDER: THE NEXUS CONFLICT 277, 284STAR TREK: VOYAGER 173STAR TREK: VOYAGER—ELITE FORCE 237–250STAR WARS STARFIGHTER 223–235STARCRAFT 53Surreal SoftwareDRAKAN: ORDER OF THE FLAME 29–40SYNDICATE WARS 156SYSTEM SHOCK 173, 289SYSTEM SHOCK 2 5–17, 175, 181TTAZ 289TERRA NOVA 5–6, 173, 193, 289THEME HOSPITAL 156THIEF 3 202THIEF: THE DARK PROJECT 5–7, 10, 13,171–181TIBERIAN SUN 103FIRESTORM expansion pack 108TOMB RAIDER 29, 32, 35TOTAL ANNIHILATION 103TRESPASSER 183–194TROPICO 137–146Troubleshooter 197TROUBLESHOOTER 197TurbineASHERON’S CALL 299–309

INDEX OF GAME TITLES & DEVELOPERS 322UULTIMA 5, 198ULTIMA ONLINE 277, 288, 293–294, 301ULTIMA VIII 290UNDERWORLD 5, 173UNDERWORLD 2 197UNREAL 14, 180UNREAL TOURNAMENT 91–102, 201–202, 205VVAMPIRE: THE MASQUERADE—REDEMPTION51–62Vivendi UniversalDARK AGE OF CAMELOT 278–285VOYAGER 6WWARCRAFT 63–64WARCRAFT II 64, 103WARCRAFT III 282Westwood StudiosCOMMAND & CONQUER 103–104, 106–107TIBERIAN SUN 103–114FIRESTORM expansion pack 108WARCRAFT 63–64WARCRAFT II 64, 103WARCRAFT III 282WOLFENSTEIN 184Wombat GamesDARK ZION 282XX-COM: UFO DEFENSE 288X-MEN 289X-Wing 220, 223–224, 228, 232

323 Index 323IndexBe sure to also use the Index of Game Titles & Developers beginning on page 319.Symbols.AVI 88.DLL 177Numerics3D Studio 66, 2803D Studio Max 6, 30, 80, 92, 104, 116, 172,184, 238, 246, 252, 255, 260, 263, 288,2913Dfx 164, 168AAbandon Entertainment 279, 281–282Adaptive Optics 6, 172AdobeAfter Effects 104, 172Illustrator 42, 104Photoshop 6, 20, 30, 42, 52, 80, 104, 128,138, 162, 172, 184, 210, 238, 260, 278,300AGE OF EMPIRES 63–73AGE OF EMPIRES II: THE AGE OF KINGS115–125AI 176, 178, 191, 200, 202, 294problems 178, 191Alias|WavefrontMaya 52Power Animator 6, 162, 172StudioPaint 162Allegro Common Lisp 210ANSI string object 233AntimatorPro 172API 59, 124AppleFinal Cut Pro 128QuickTime 128QuickTime VR 131AppleTalk 163ArghRad 261Arthurian legend 278artificial intelligenceSee AIASHERON’S CALL 299–309Autodesk Animator 66automated testing 72Avid 111Media Composer 104BBattle.net 81, 86–87beta testingSee testing, betaBink 132, 138, 152, 238BLACK & WHITE 151–160Black Ops 252Blackley, Seamus 183BlueICE accelerator 104BorlandJBuilder 238budget xi, 2–3, 31, 49, 53, 58, 144large 204limitations 13, 303marketing 204memory 248, 269physics 192problems xiismall 5, 52underestimating 133, 181bureaucracy 281CC 233vs. C++ 33C++ 33, 177, 213, 223, 233

INDEX 324CEL DAMAGE 41–50Character Studio 138, 280–281Chey, Jonathan 5Clancy, Tom 252, 256co-development 101color palette 66compositingproblems 110CRASH BANDICOOT 216customer service 283cut-scene 317DDARK AGE OF CAMELOT 277–285data 317databasedeveloping with 68DDA 317deathmatch 273, 317DeBabelizer 6, 172debugging 229, 231Deluxe Paint 104Denman, Stuart 29design 34, 232Designer Script 262DEUS EX 195–207DIABLO II 79–90DigidesignPro Tools 128Direct X 20, 65–66, 72Direct3D 59, 80, 202DirectPlay 39, 65–66, 72, 124, 253DirectShow 124discreet3DS Max 20, 42, 128, 130–131, 138, 152,278, 280–281Combustion 128Flint 104DOS 180DRAKAN: ORDER OF THE FLAME 29–40DreamWorks InteractiveTRESPASSER 183–194Dromed 180DS 262EE3 284, 289, 302, 317editormap 162problems 180ElemediaSX2.0 Voice Codec 289EmagicLogic Audio 30engine 317exploit 317Ffeature creep 35–36, 47, 62, 109Filemaker Pro 6, 104FIRETEAM 287–297first-person shooter 317first-person sneaker 317Foley 216GGame Object Assembly LispSee GOALgameplay 317Gaming Zone 124GDC 311–312, 318Ghoul 246, 264, 267Glide 59, 80GNU C++ 210, 278GOAL 213–216Gresko, Ray 51Grossman, Austin 183HHDTV 133Holland, Larry 223Huebner, Robert 51

325Index 325IIntelVTune 30Internetperformance problems 295IPX 66ISP 65JJAK & DAXTER: THE PRECURSOR LEGACY209–217Java 55, 99, 166KKlingon 238Llaunch 9, 134–135, 283, 305retail 305timing 100, 224, 282weaknesses 307LECgl 228Leonard, Tom 171level 318license 219, 221Lightwave 3DSee NewTek, Lightwave 3DLinux 216, 278, 282port 98Lisp 213–215localization 69, 141, 211MMacromediaFlash 224, 229, 235Marathon 163, 169MaxScript 190Maya 210memorybudget 248, 269usage 232MetrowerksCodeWarrior 128, 162for Play Station 2 224, 234MFC 140MicrosoftChat Service 288–289Developer Studio 80, 152, 288Direct XSee Direct XDirect3DSee Direct3DDirectPlaySee DirectPlayDirectShowSee DirectShowDirectSound 289, 293DirectSound3D 80IIS 288–289Interdev 288MFC 140SQL Server 288–289Visual BasicSee Visual BasicVisual C++ 6, 20, 30, 52, 104, 116, 128,138, 172, 184, 210, 238, 252, 260, 278,300, 303Visual C/C++ 162Visual SourceSafe 238Visual Studio 42, 80, 92, 196XboxSee XboxMicrosoft Systems Journal 230Miles Sound System 128, 138, 224milestones 2, 59, 200–201, 210, 226, 302, 306,308missing xiiplanning 226testable 200video 133Min, Art 287MMORPG 283MMPOG 318Molyneux, Peter 151motion capture 318MSN Gaming Zone 301

INDEX 326MUD 273, 299–300, 309multiplayer 65–66, 71multi-user dungeon (MUD) 56music 186MySQL 283MYST 133, 135MYST III: EXILE 127–135MYTH: THE FALLEN LORDS 161–169NNDLNetImmerse 278, 280NetImmerse 3D 277NewTekLightwave 3D 104, 196, 262–263, 300Nintendo 64 228NTSC 133, 211Oobject-oriented design 68, 98ObjectSpace STL 224Ogg Vorbis 20OpenGL 59, 224OPERATION FLASHPOINT 19–28OpusMake 6, 172Oracle 283oriented bounding box (OBB) 38PPAL 211Paramountand licensing 238patch 318pathfinding 167–168, 202Patmore, Alan 29performanceoptimizing code 67–68personnelloss 258Photoshop 210physics 183, 187–190, 192, 305, 308budget 192calculations 211engine 41, 256problems 192realistic 187pitaSim 42Planet BlueTulip 224Play Station 2 227–229, 232–234Playstation 110Playstation 2 209, 224, 234post-production 111processing 216proto-mission 200QQERadiant 52–53QUAKEengine 261, 303QUAKE 2engine 237, 248, 264, 267QUAKE 3engine 239, 246–247level editor 243QuakeHelper 261QuickTime VR 131RRAD Game ToolsBink 80, 128, 132Ragaini, Toby 299RAINBOW SIX 251–258Raven SoftwareSOLIDER OF FORTUNE 259–271STAR TREK: VOYAGER—ELITE FORCE237–250RCS 6real-time strategySee RTSREDEMPTIONSEE VAMPIRE: THE MASQUERADE—REDEMPTION

327Index 327renderer 179, 318software-oriented 188Rendition 164ROFF 262–263Rotation Object File FormatSee ROFFRPG 318RTS 105–107, 113, 318Ssandbox 318Schaefer, Erich 79schedule 210problems 36, 112, 306scripting 166, 177–178sequel 75–77, 105SGI02 workstation 104Indigo 6Indigo 2 162skeletal compression 269SoFPath 263Softimage 30, 238, 260Softimage 3D 246SOLDIER OF FORTUNE 259–271Tactical Non-violent Version 263–264Sonic FoundrySoundforge 30SonyPlaystationSee PlaystationPlaystation 2See Playstation 2sound 57design 175foley 49propagation 202sound effects 49, 57, 88, 90, 162death 82Spanel, Marek 19Spanel, Ondrej 19staffingcontractors 294problems 165, 231, 257Standard Template LibrarySee STLStar Trek 237–250STAR TREK: VOYAGER—ELITE FORCE 237–250STAR WARS STARFIGHTER 223–235Star Wars: Episode I 231startup 1–3Stinnet, Daron 223STL 230, 233Stojsavljevic, Rade 103storyboard 110SYSTEM SHOCK 2 5–17TTCP/IP 39, 124, 163, 295testing 15, 25–26, 37, 45, 71, 76, 84, 87, 123,168, 254, 292audio 216automated 72, 120beta 70, 83, 87, 164, 288, 305, 308code 302compatibility 59focus 45inadequate 37, 258play 123, 303team 26tools 66texture 318THIEF: THE DARK PROJECT 171–181TIBERIAN SUN 103–114TOMB RAIDER 29tool development 291TRESPASSER 183–194TROPICO 137–146turn-based 318UUDP 295UNREAL TOURNAMENT 91–102UnrealEd 92, 99, 102, 196UnrealScript 99, 204Upton, Brian 251user community 296UUNET 283

INDEX 328VVAMPIRE: THE MASQUERADE—REDEMPTION51–62vertex compression 269Vicon 8 20Visual Basic 102Visual SourceSafe 300, 303Vivendi UniversalDARK AGE OF CAMELOT 277–285voice technology 292Vtune 42WWARCRAFT II 63Warner Brothers 41waterfall development model 318Winamp 42Winsock 65Womb Music 280Wyckoff, Richard 183WYSIWYG 34XXbox 41–42ZZone software 124

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

This Page Intentionally Left Blank

The Complete Guideto Game Audioby Aaron MarksTurn your musical passioninto a career with thisguide to the technical andbusiness skills needed tosucceed in the multi-billiondollar games industry.Learn how to create gameaudio from the ground up, as well as how to successfullymarket your business. CD-ROM included, 353pp,ISBN 1-57820-083-0, $34.95Finde-mail: cmp@rushorder.comwww.cmpbooks.comin your local bookstore.Order direct 800-500-6875fax 408-848-5784EXPERT SERIES