Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Quake 2 Dev - Part 1

Quake 2 Dev - Part 1

Ratings: (0)|Views: 125|Likes:
Published by Evil-Soft.com

More info:

Published by: Evil-Soft.com on Apr 24, 2013
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





by Brian Hook 
the procedures in place at id are notperfect, they have resulted in the time-ly shipment of several popular prod-ucts, so take this for what you will.This column is pretty dry and matter-of-fact — it’s more like a laundry list,to be honest — so while it may not beamusing and entertaining, I hopemany of you will find it informative.And just to be clear, this is
a recipefor success.This month, I’ll be talking aboutsome of the programming methodolo-gies that we’ve used during Q 
development. Next month, I plan todiscuss the tools that we employ, bothsoftware and hardware, and some relat-ed issues.
Team Programming
he programming staff at id consistsof three programmers: JohnCarmack, John Cash, and myself.Programming tasks are split into threedistinct groups: graphics, game logic,and “glue.” The graphics subsystems(OpenGL and software rendering) con-sist of the actual code used to render ascene and are encapsulated into two.DLLs, REF_GL.DLL andREF_SOFT.DLL. The game logic is alsoput in a .DLL, GAMEX86.DLL, whichhandles all game-specificstuff such as monster intelli-gence, weapon behavior,physics, and power-upeffects. Finally, the “glue”code, which consists of win-dow system interaction,input management, sound,CD management, networkprotocols, and other not-easy-to-categorize crud, islocated in the executable,QUAKE2.EXE.The sweet spot for ourteam size is working out tobe three programmers. Thegraphics subsystems are mydomain; the game logic is John Cash’s responsibility;and the glue code is usuallymodified by any of us. JohnCarmack is the grand dicta-tor and architect — he modifies broadexpanses of all the code at any giventime and is responsible for the overallarchitecture and making sure that thepieces of Q 
2fit together logicallyand efficiently.The current triangular hierarchy thatwe have in place is extremely efficientbecause John Carmack is the absoluteruler of the programming team. Eventhough Carmack is the undisputedboss because of his position within id,both Cash and I have extreme respectfor him, and it is this respect thatallows Carmack to manage the devel-opment process effectively. It is farmore important to have respect fromyour employees than arbitrary authori-ty over them. Also, by taking care of implementation details and minutiae,Cash and I allow Carmack to concen-trate almost exclusively on large,sweeping architectural issues.Also, a key to making the team pro-gramming approach work, at least forid, is that John Carmack is responsiblefor both the architecture and the initialimplementation of any new technolo-gy. This lets him reconcile any unfore-seen implementation and design inter-actions that may have globalrepercussions within the code base.Another nice thing about the delega-tion of responsibilities is that there is
How I Spent My Summer Vacation,or What I Learned While Working on
lot of people in the game industry have asked me about the software devel-opment processes used at id software, so I thought I’d take the time towrite an article about the processes and philosophies used at id softwarewhile interspersing my own opinions and reflections on them. While
 Brian Hook’s last 
Game Developer
col-umn will appear in next month’s issue.Tell him how much you’ll miss him viae-mail at bwh@wksoftware.com.
very little adversarial competitionbetween programmers. Neither Cashnor I is presumptuous enough to chal-lenge Carmack’s dominance, and sinceCash and I work on separate subsys-tems, our work is complementaryinstead of competitive in nature. Thelines of code ownership are clearlydefined and are something with whichwe’re all very comfortable — and werespect each other enough that wedon’t feel any urge to edit someoneelse’s code. This lets us work in a realteam atmosphere, and we manage toavoid the whole “Who’s The Man?”jockeying that is so common amongcomputer programmers.One problem that team program-ming presents is source control. Asashamed as I am to admit it, id softwaredoes
use source code control. Rightnow, this discrepancy is largely theresult of expediency. We recognize theneed for proper source control, but wehave enough of a working system thatuntil source control becomes a crisis,we won’t address the problem — espe-cially when we’re this close to shippinga product. Our next generation soft-ware hopefully will be developed com-pletely within the framework of a large-scale source control system. Personally,however, I use MicrosoftVisual SourceSafe on mymain workstation simplybecause I like to have ahistory of my changes atall times.Another issue that ariseswhen multiple program-mers work together is cod-ing style. It’s importantnot to get wrapped up inreligious issues such as tabsize, brace and parenthesisplacement, or indentation style— you should be able to adjustto any style, even if it irks you.Fighting battles over something as per-sonal as this simply is not worth theeffort — make some compromises andmove on.Other coding style issues, however,are worth specifying at the outset of aproduct’s development. Standard-ization and consistency are very impor-tant when working on large projects.Files, data structures, APIs, and vari-ables should have a clean, consistent,and intuitive naming convention sothat there is little room for confusionwhen looking at someone else’s code.Static and global variables should betagged as such, be it by a prefix, suffix,or some other convention. Parameterordering should be consistent: Is a des-tination address the first or last para-meter? Are prefixes used in
mem-bers? Where are global variablesdeclared and under what conditions?Are globals stuffed into a single globalstructure or just tossed out into theglobal namespace? How are manifestconstants differentiated from
dec-larations? How are directory structuresorganized?
or quite some time (over adecade now), computer scien-tists have been talking about mod-ular software, component soft-ware, or “software ICs.” Thetheory is that programmers shouldbe able to purchase a thoroughlydebugged and optimized prepack-aged software library (who are wekidding?) from some third-partydevelopment house and just dropit into a program — voila, instantnew features and functionality.Obviously, there is a differencebetween that theory and the harshrealities of creating a product that hasto ship to real people on a real calen-dar. Libraries are written by program-mers, and programmers are human,and humans make mistakes. Manytimes, these programmers will evenhave a different set of priorities thanyour own.This is the crux of the problem. Thesoftware component that you pur-chased might look great on paper, butwhen you drop it into your programand then spend a week looking for abug that turns out to be a part of yournew magic software IC, well, you tendto snap out of your dream world prettyquickly. Anyone who has wanted tofirebomb Redmond, Washington, afterusing Microsoft’s DirectX knows whatI’m talking about. And when a fix forthat bug isn’t going to arrive in a time-ly fashion, you’re suddenly in the posi-tion of hacking around broken code, aprocess pleasantly known as “comingup with a workaround.” Deal withenough “workarounds,” and you’lleventually reach a cross-over pointwhere you realize that you may havebeen better off if you’d just written thecode yourself.And bugs aren’t the only problemyou’ll encounter — there are perfor-mance issues to contend with also.With W
, GLQ 
, and Q 
2,we had to work around some prettyserious performance problems inMicrosoft’s DirectSound. DirectSoundworks the way it’s supposed to, but it’sslow enough that you get all teary-eyedremembering the days of Sound Blaster16 programming under DOS.Finally, not only do you have tocontend with bugs and performance
issues, but there’s always the specterof flexibility. That nifty new librarymight do everything you need
,but when you’re six months intousing that library, and you
havea couple new features implemented,and the library owner isn’t amenableto adding those features… well, you’rein trouble. You now have the optionof undoing months of work andrewriting everything from scratch, atwhich point you’ve tossed awaymonths of effort, or you forego theextra functionality, which may not bea feasible alternative. And, of course,if you want to port to a developmentplatform or operating system onwhich the library is not available,you’re in deep trouble. You canaddress many of these problems bylicensing the source code to whateverlibrary you’re using, but at that pointyou’re in the position of actuallylearning someone else’s code, not tomention maintaining, extending, anddebugging it. At some point, you mayfind that you’d have been better off writing everything yourself fromscratch.Don’t get me wrong — I’m not say-ing that using externally developedlibraries is absolutely a bad thing, butsome tradeoffs are definitely involved.We have a hard enough time dealingwith bugs in our compiler, the Win32API, Microsoft DirectX, and hardwaredrivers without adding someone else’scode to the mix. So the unofficial poli-cy at id is that we engineer all of ourown code unless we absolutely have nochoice, such as the necessity of depending on DirectX. It may not bethe most effective use of our resources,but it leaves our destiny in our hands,which has a certain warm and fuzzyappeal to it.
Programming Languages
s technology-oriented as id soft-ware is perceived, we’re actuallyknuckle-dragging primates when itcomes to our programming languageof choice. We use good old ANSI C forthe majority of our development.Objective-C, a version of C withobject-oriented extensions, was thelanguage of choice for tool develop-ment back when id was usingNextStep. However, during the subse-quent move to Windows NT, id wasforced to abandon Objective-C infavor of ANSI C for these tasks. We’recurrently evaluating the performanceand robustness of OpenStep forWindows NT, and if it turns out that itdoesn’t suck, we may switch back tousing Objective-C and OpenStep fortool development.id software still uses ANSI C for itscore development; we have severalcompelling reasons why. We stressportability, and ANSI C is about asportable as a language can get — it’savailable across a wide range of plat-forms, and most ANSI C compilers areextremely stable. ANSI C is no longerevolving at a frantic pace, so it’s stablein terms of syntax, feature set, andbehavior. Mechanisms for interfacingANSI C with other languages, such asassembler, are well-defined and pre-dictable. Compilers and developmenttools support ANSI C more than anyother language. Finally, ANSI C isa pretty WYSIWYG language —when you look at a chunk of C,you can be reasonably certainwhat kind of machine code willbe generated.C++, on the other hand, does
share these wonderful fea-tures. C++ is stuck on top of Cusing the programming languageequivalent of duct tape andtwine. It’s still evolving at a dis-turbing rate. It’s being designedby a committee. Compilers andtools that support C++ are con-stantly missing features or incor-rectly implementing them, andthe language, as a whole, is solarge that understanding all of it isnearly impossible. Any given chunk of C++ code, assuming it uses even asmall portion of the language, can gen-erate seemingly random assemblycode. While you can pick up a booksuch as Bjarne Stroustrup’s
 Design and  Evolution of C++
to help you under-stand why C++ is such a screwed uplanguage, it still doesn’t address theissue that C++
a screwed up lan-guage. It’s constantly evolving, gettingbigger and uglier, and pretty soon it’sgoing to implode under its ownweight.Seven years ago, I bought BorlandTurbo C++ 1.00 the day it wasreleased (yes, I’m that big a geek), andover the course of the ensuing five orsix years I used C++ as my only pro-gramming language. In that time, Ilearned most of its weird intricacies,adjusted to them, and accepted themas necessary evils, the price I had topay for object-oriented programming.When I started working at 3DfxInteractive, I had to start using ANSIC again because I was developing aprogramming library, Glide, thatneeded to be used by a lot of develop-ers, many of whom would not befamiliar with C++.The amazing thing to me was thatwhen I switched back to ANSI C, I wasactually
— I discovered a new-found appreciation for ANSI C’s sim-plicity (at least compared to C++).Sure, I lost some nice syntactic sugar,and I ended up missing classes and vir-tual functions a bit, but I was willingto eschew these niceties in return forsimplicity. By using ANSI C, I neverhad to crack open a reference book,

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->