Postmortem: Heretic II
by Jake Simpson

April 19, 1999

If Will Shakespeare were around today, I’d like to think he might make the quote "If graphic violence be the food of gaming, then code on". Looking back on Heretic II, I think we can safely say we followed that to the letter.

Heretic II was designed as a third person action game from the word go. It had actually been proposed a while back here at Raven but at the time the technology to do it convincingly just wasn’t there, so it was shelved until it could be done right. After seeing what Core had done with Tomb Raider, it was decided to take that proposal from the shelf, dust it off, and see what we could do with the latest Id Quake II engine. The emphasis was always to be an action game, rather than an exploring style ala the good Lara, or even Hexen II; we wanted cool worlds, cool monsters, violence, exciting ways to hand out death, and lots of it.

The team.

Raven has an onsite complement of about 50 people, and during the development of H2, almost everyone had their fingers in the pie at one point or another. Since this would require some major management, the team ended up with ‘middle managers’ for each of the major disciplines. Jon Zuk handled Mapping, Jeff Butler handled the 2d texturing and skinning, Brian Pelletier handled both the 3d Modeling, and overall project design, Pat Lipo was the programmers’ code god, and I was handling whatever fell off Pats back.

The main core coding team consisted of John Scott, who handled the front end, all 3d card support and was our bug finder extraordinare, Mike Gummelt & Josh Weier, who were responsible for the AI and the Buoy system, as well as lots of very pretty special effects, Marcus Whitlock, who dealt with the Client prediction end of things, as well as the Camera itself, Bob Love who handled all object placement, as well as all entity related coding, Josh Heitzman, who implemented the whole client effects system (of which, more later), as well as updating our physics system, Pat Lipo who was herding us all in the direction he wanted us to go as well as implementing our hero Corvus, and me, who handled the software renderer, the EAX and A3D sound systems, and pretty much anything else that no-one else did.

The mapping core team consisted of Michael Ramond-Judy, Matt Pinkston, Mike Renner, Tom Odell, Jeremy Statz, Tim Jervis, and our glorious leader Brian Raffel, all being governed by Jon Zuk, the design lead. Its tough to point at any one map and say that it was one persons work, since everyone worked on lots of maps, so it was decided that way that no one persons style would become to prevalent.

From the Art standpoint, we had Jeff Butler in charge of texturing, working with Rob Gee, Kim Lathrop, Gina Garren, with help from Mark Nelson, and of course, our project lead, Brian Pelletier.

3D wise, we had Jeff Lampo, Jeff Dewitt, John Payne and Eric Turman creating and animating 3d objects, and special mention should be made of Brian Shubat who stepped up to create the famous Corvus animations, so next time you see Corvus scratching his ass, you know who to blame.

The amazing maestro of Kevin Schilder of course handled sound & music.

Many other people in Raven helped out with H2, but it would take a complete article to go through them all and their contributions, so a big thank you to them goes here.

Implementation.

After the decision to go on this project was made, one of the first things that occurred was commissioning the fantasy artist Brom to create some conceptual art. This helped shape the direction and flavor of the worlds that these creatures would inhabit. At this point, a technology demo was commissioned, to ascertain if a 3^rd person game could be built within the Quake II engine, with a camera that would be intuitive. This was achieved within a month. The camera was in fact one of the easiest things to build. We knew what we wanted, and went out and did it. Once we demonstrated this demo to Activision, the green light was given, a delivery date was hammered out so we could be done for Christmas, and it was all systems go. Brian Pelletier took over at that point as Project lead, and the project design doc was hammered out. Pat Lipo decided on the critical systems we would need to address, and development commenced. There were lots of discussions about the wisdom of attempting to implement a software renderer, at which point the marketing department at Activision got involved and informed us that it was a requirement, since Europe is traditionally about 2 years behind the States in hardware, so most Europeans would not have 3d acceleration. Since traditionally fantasy games have a strong following in Europe, this was deemed important.

Development progressed over the year, as development does, in spurts. E3 came and went with our demo being displayed, to a lot of surprised and enthusiastic reactions. We recorded voice actors to portray Corvus, and the tome, we commissioned a Russian group known as Creat to do our pre-rendered sequences. A pre-release demo was hemmed and hawwed over, until we finally decided to do one, and as it was, we were a couple of days late with it, mainly due to us trying to get the load/save option working correctly. In the end, we figured it was better to have a demo without it, rather than making people wait. After that, we hit crunch time hard to get the game done. Unlike many projects, not much was actually left out from the original design document. We did have some worries with the in-game cinematics, but Rick Johnson came to our rescue with a scripting system he was developing for the fledgling Soldier Of Fortune. When it came to Quality Assurance testing our product, QA at Activision was especially tough on us due to having just released a product that was not as bug free as it might have been. But this was really in our favor, since it forced us to tighten up and examine our code more thoroughly than we might have.

Modeling.

Our models, as the modders out there can attest to, aren’t your regular run-of the-mill Quake 2 .MD2’s. We modified the whole modeling system so we could have models with a rudimentary backbone. This was required to allow corvus to look around when the camera was moved. It’s a nice bit of realism, and added a lot to the feeling of character immersement. The new format also allowed for the creation of code reference points of the models, so we could create special effects at a specific point on the model, say corvus’s hands or feet. The new model type was called a Flex Model, and was a product of SoftImage. SoftImage was used for almost all our animations, which were not, contrary to popular belief, the product of motion capture. 3DSMAX was used to create all our static world objects, and the simpler animations. One other implementation that came into great effect on the Flex models was the divided animation system. This allowed us to split off animations at Corvus’s waist, so we could have him running and shooting at the same time, without the need for gobs of animation data. As it was, Corvus ended up with almost 1600 frames of animation for the retail version of H2, and that’s not including the cinematic frames…

Quake II System refinements / modifications.

Some of our biggest modifications were all under the hood so to speak. Obviously the client effects system – our client side special magical effects generator - was one of the biggest. With all the special magical effects that were being planned, it became obvious very quickly that the existing Quake effects code model would not be able to handle it. Besides, the reasoning went, it would be better to have as much of the client system handling the effects as we could offload. That way the server would be freed up to do more important game related stuff. The way it worked was an effect would be fired off from the game code on the server, pass across the network general information, like effect ID, location, its owning entity (so it would follow owners around if they moved), and then effect specific information per effect. The client effects DLL on the client would then handle updating the effects, and removing them when culled off screen or completed. Most effects in fact had no extra info, which helped out quite a lot network packet size wise. Programmatically, this whole system turned out to be a mixed blessing - as we will discuss later – although in game terms, it was a resounding success.

Other refinements included modifying the software renderer to handle 16 bit graphics. Originally, we were going to handle 32 bit graphics, and all modes of hardware renderers, and indeed, all the code was written. After viewing the slide show that resulted, we decided to scale that back a little. MMX implementation helped a lot, but still, it required some major re-writing of the very tight and very fast original Id code. We will always be indebted to our Chief Technologist Gil Gribb for helping out here.

The client prediction system required a major overhaul, bearing in mind that seeing Corvus perform his animations smoothly was critical to a fun multiplayer experience, not mention the fact that most of Corvus’s activity code was animation driven. Marcus Whitlock had his hands full of that particular activity, with a little help from Gil Gribb.

We added quite considerably to the whole sound system, splitting sound support off into a separate DLL. The idea was to have three separate DLL’s, one for the Default Quake II sound system, one for A3D support, and the last for Creative EAX support. We didn’t get to the EAX one before release dates where upon us, but with a lot of help from Micah Mason and Suneil at Aureal, we did get a 1.0 implementation of A3D in there.

Ways we kicked ass.

We got done on time. And inside of a year. This is a major accomplishment in this day and age of two year development cycles. Yes, we used someone else’s engine, but then so have other very public and very late games out there – or more to the point, not out there. And believe me, Id probably wouldn’t recognize their original engine much.
Our Camera actually worked. There are some other well-known 3^rd person games out there, which shall remain nameless that, with all the charity in the world, cannot be said to have a particularly workable camera. Since a game of this nature revolves (literally!) around the performance of the camera, we were especially proud of our implementation. Especially gratifying was the public announcement of some of the gaming communities’ luminaries of the impossibility of going back to the conventional 3^rd person games after playing H2.
Our Multiplayer worked out of the box – no patches required. A lot of other gaming companies seem to regard this as a second level priority – not worrying about it till late in the project. We were helped here since we were using the Quake II network model, which is a particularly stable one, but with all the touching and tweaking we did to it, it had evolved considerably. The addition of the client effects system as well as an enhanced bit packing system for networked entities increased the complexity quite considerably, so we feel we did a fairly good job of making it all work from day one.
The Client Effects DLL. People were amazed that H2 could run smoothly on a p166 with some relatively decent hardware acceleration. The Client Effects system was why. Moving most of the graphical special effect code from the server to the client freed up the server considerably to be doing more game related stuff, and also allowed for easier scalability on the individuals machine. Can’t handle the 10 times screen over draw of the ring of repulsion? No worries, just turn down your level of detail, and the sprites are drawn smaller, less of them, and scaled down faster. We didn’t do this at a system level, but wrote it in an effect-by-effect way, since different effects required scaling in different ways to make them look right. Also, since the camera was handled on the client too, it allowed us to write some clever code that dealt with the camera getting dumped in the middle of some constant client effects. For instance, Corvus backing into a fire... when the camera went into the middle of a fire effect, or a waterfall, Riva TNT or no Riva TNT, the frame rate just slowed to a crawl. We tried various different ways of trying to solve this, like stuffing in a bounding box around the fire that the camera couldn’t penetrate, but that ended up looking weird and unacceptable. In the end, we wrote some code for the effect that determined distance from the camera, and just culled it totally when it was too close. No one seemed to notice this, and it helped our frame rates no end.
Our Buoy system for AI navigation was a major help, and without a doubt was the reason our AI was better than most. Mike Gummelt and Josh Weier were responsible for it, and it consisted of beacons (or Buoys) being dropped in the maps for single play that the monster AI followed around. The buoys themselves had information embedded within them that allowed monsters not only to navigate the world, but also open doors if required, jump from ledges, run away, engage in group activities, and warn friends that you are on your way. Of course, we released right next to Half-Life which is the undisputed king of the current AI scene, so our advances were somewhat overlooked, but still, the team is proud of this system, and it was undeniably a factor in the critical success of H2.
Corvus and his many ways of death ROCKS! There is no doubt about it, hacking someone’s head off in a spray of blood with gibs flying everywhere was a lot of fun. We never saw a less than 8.5 out of 10 for any review, so it seems like the gaming community was with us on this. Multiplayer especially seemed to be fun, and we did hear some very chest puffing comments from our peers in the industry, especially after the demo came out. It seemed like no one was expecting it to be as much fun as it was, so it was nice to hear that other gaming companies where getting into it. Taking the time to balance the weapons and damage, and making sure the powerup shrines were placed appropriately paid off in spades when the game was released. The story and all that went with it definitely helped us in making the game a success, but at the bottom of it was plain, violent fun. And not the sort that can be accused for making kids run amok with an Ak47. Not many kids can conjure up a Red Rain bow.

Ways we didn’t kick ass.

One acknowledged misstep we made was not commissioning a Linux Server version of Heretic II to be released at the same time as retail. Half-Life demonstrated the wisdom of having Linux code available at launch time; witness the number of servers around on launch day. Heretic II never caught up on this, to this day. We do have a Linux version in the works now, but its been delayed by the EP, and then the EP bug fixes, but it may be a case of too little too late.
Don’t rebuild your physics system unless you really have to. We did this, and it turned out to be a much larger albatross than we imagined. It didn’t help that our resident physics expert who implemented it left for pastures new either. The idea originally was to integrate the new physics systems with the AI more tightly, fix one or two legacy bugs with physics from the Quake engine, and add some cool features like proper friction, and inertia. As it turned out, we introduced more bugs than we fixed, and the AI integration was never used.
The Client Effects DLL. Although this was an extremely helpful system, it also turned into a large pile of messy code. We ran into several problems both with removing some constantly occurring effects (such as the sphere of Annihilation), if the packet with the removal code got lost, then we were in trouble. Mostly this was taken care of by the Quake system of automatically removing entities when it loses track of them. However, there were circumstances where client effects had no owner, but were set off in the world, and then left to the effects system to be removed… we sometimes had some problems getting them to go away if we had a large packet drop. Another aspect that gave us problems was the sheer complexity of the system. To begin with, it started out a very cool sub system, with some simple culling and a clear idea of its scope. However, with up to 11 programmers all attempting to add effects and code, it soon started burgeoning into a larger subsystem. At that point, there was no one person with a complete comprehension of exactly how it all worked, with predictable results.
Given the above point, it naturally leads us onto the old adage that ‘too many cooks can spoil the broth’. Since almost every programmer at Raven had at one point or another been into the code base, there was a fair amount of redundancy in routines and so on. It’s a credit to Lead Programmer Pat Lipo that in fact it went as smoothly as it did. However, inevitably, coding conflicts arise, as do competing sub systems. I think it would be safe to say that we definitely found the point were too many clever people working together ends up a massacre of the innocents. It is worth pointing out here that the reason we had some much programming power on this project had little to do with the quality of the core team and everything to do with the sheer quantity of work, and looming deadlines that we had been assured were not going to move at all.
Release timing. We released a few days off from Half-Life. You can’t get much more unfortunate than that, unless you release the same day as Quake 3. With all the anticipation that had been built regarding Half Life, the release time was unfortunate. On the other hand, our release date had been set by Activision when we were first green lighted, where as the Valve guys tended to be more floating with theirs.

The EP.

Once the game was released, the decision was made to go ahead with a glorified patch referred to as the Enhancement Pack. The idea behind this was that H2 was pretty much free of major bugs, and as such didn’t really require a patch to fix anything. However, there were some bugs in the code. The first being a joystick mistake we made. This was fixed almost immediately, and released on the net. After that, most of the team was disbanded into other projects, leaving Pat Lipo, Marcus Whitlock and myself to complete the EP. We started out fixing the small bugs we knew were out there, and then moved into expanding the feature set of H2 to what we would have liked it to have shipped with. Most notably we added a female model, custom skin selection, autodownloading of skins, models, maps and so on, A3D 2.0 support, EAX support, some new deathmatch levels, correct prediction of Corvus related effects and sounds, a couple of new spells and a plethora of other smaller helpful additions. Once we were comfortable with all the additions we had made, we decided to try a small public beta test of the EP. This was an extremely successful thing to do it turned out, with much helpful commentary coming back from those involved. In fact, we ran into feature creep quite a lot at the end of this burst of activity, which mainly came from the extremely helpful and cool suggestions we got from the beta testers, some of which where obviously too good not to include. We did suffer a bit from the existing H2 community over the EP, since we thought we’d be done just after Christmas. That was a bit optimistic as it turned out, but our mistake was announcing an approximate release date for the EP. The Heretic II community was not best pleased about this, and made no bones about announcing it. Part of the reason for the lateness was due to the construction of the female model. With 1600 frames to build, and all done from scratch due to the limitations of the model format, it took longer to get it right than we estimated.

Lessons to be learned.

Do a Linux version of your game (assuming it’s a client/server architecture game) as you develop. This is an important factor, and is now one that is almost assumed for all games, in the same way that a game suffers if there is no multiplayer option. You don’t have to go all the way, just making a dedicated server will be enough here. We messed up here, and didn’t recognize the demand there would be for this. We won’t make this mistake again.
Keep in touch with your producers marketing department. It is paramount that they understand the game in all its nuances, and understand what the game means to YOU the developer. Communication is of the essence here, and it will pay off big when launch time comes around.
Limit the number of programmers involved in the project. Throwing bodies at a project with a looming deadline is not necessarily the way to get it done on time. If you do use contractual programmers, or programmers from another project, be sure you have the code they need to do well defined, and broken into modules. Sounds obvious, but it often isn’t.
Have a good project lead. Often the difference from a kick ass game and an ok one is the ability of the project lead to describe the vision in his head to you, the developer. We were lucky in that we had a damn good one. The concept art helped a lot too.
Don’t hand out demo dates. Another mistake we and Activision made was in announcing a date for the demo. We were two days late, but to the frothing masses out there, two days can be an eternity. When the demo for Hexen II was late, Brian Raffel received over 400 mails in an hour demanding to know why it was late. Some even included death threats. Scary eh ?
Don’t go out of your way to create extra code for upcoming Demos. E3 is important, but its not the be all and end all of whipping up interest in an upcoming game, and quite often can be a drag on real development. The only time there is an exception to this is if you have new technology to show and you are looking for a producer – if you don’t already have a delivery date then it doesn’t much matter.
It IS possible to get games done in a realistic time frame. Having a “when its done” mentality may work for Id, but then they are, well, Id. Most of us aren’t. Having a deadline and sticking to it shows a discipline in work practices, and is terribly focussing when it’s a month away. One big plus to actually making a delivery date is that all you marketing will be right on track. Money spent on end caps at Best Buy will not be wasted.
A private Beta test can shake your code tree in ways you never imagined. This is not to attack any QA group, but it can act as a great precursor to the actual Quality Assurance process. QA-ing almost always costs you, the developer, money. Private beta tests out on the wilds of the Internet costs nothing, and you end up with a legion of loyal fans that will beat your game better than anyone that’s paid for it. It was a great experience of ‘Real World’ testing that we will most certainly be repeating.
Supporting and being available to your community can bring rewards that are indefinable. We made a point of making sure we perused the message boards daily, answering all questions and mail as much as we could. This results in the community feeling that you care, and that you are approachable by them. In some ways this back fires, since there always some that will cause you trouble, and you open yourself up to abuse by them, but by and large, this is almost always a positive thing to do. Suggestions can get made that you would never hear before, and so on.

Discuss this article in the forums

Date this article was posted to GameDev.net: 11/6/2000
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Postmortems