We designed Heretic II 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 we shelved the idea until it could be done right. After seeing what Core had done with Tomb Raider, we decided to see what we could do with that original idea and id’s Quake II engine. We’d always intended for it to be an action game — we wanted cool worlds, cool monsters, and exciting ways to hand out death.

Getting it Off the Ground

After the company decided to go ahead with the project, we quickly commissioned the fantasy artist Brom to create some conceptual art. This art helped shape the direction and flavor of the worlds and the creatures that would inhabit them. Next, the company commissioned a technology demo to ascertain whether or not it was possible to use the Quake II engine to build a third-person game with an intuitive camera. The camera was actually one of the easiest things to build. This all took about a month.

Once we showed our demo to Activision, the publisher gave us the green light, and we hammered out a delivery date so that we could be done by Christmas. Brian Pelletier took over as project lead, and the team drew up the project design document. Pat Lipo decided on the critical systems we would need to address, and development commenced. We had many discussions about the wisdom of attempting to implement a software renderer. At this point, the marketing department at Activision got involved and informed us that a software renderer was a requirement because Europe is traditionally about two years behind the States in hardware, so most Europeans would not have 3D acceleration. Traditionally, fantasy games have a strong following in Europe, so building a game to meet European considerations was important for us.

Development, a Thumbnail Sketch

Development progressed over the year in spurts — as development does. We recorded voice actors to portray Corvus and the tome. We commissioned a Russian group known as Creat to do our pre-rendered sequences. We hemmed and hawed over a pre-release demo until we finally decided to do one (ultimately, we were a couple of days late with it, mainly due to a malfunctioning load/save option ). E3 came and went, along with the display of our demo (which brought a lot of surprised and enthusiastic reactions). After that, we hit crunch time hard to get the game done. We did have some worries about 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, QA at Activision was especially tough on us because they’d just released a product that wasn’t as bug free as it might have been. But this was in our favor because it forced us to tighten up and examine our code more thoroughly than we might have done otherwise.

Notes on Modeling

Our models aren’t your run-of the-mill Quake 2 .MD2s. We modified the whole modeling system so that we could have models with rudimentary backbones. A backbone was necessary 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 immersion. The new format also supported code reference points on the models so that we could create special effects at a specific point on the model, such as 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. We used 3D Studio Max to create all of our static world objects, as well as the simpler animations. The implementation of the divided animation system on the Flex models also worked really well. This allowed us to split off animations at Corvus’s waist, so that 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

Some of our biggest modifications were all under the hood of the Quake II engine (so to speak). Obviously, the client effects system — our client-side special magical effects generator — was one of the biggest changes. With all the special magical effects that we planned, it became obvious very quickly that the existing Quake effects code model would not be able to handle them. Besides (the reasoning went), it would be better to offload as many of the effects onto the client system as we could. That way, the server would be freed up to do more important game-related stuff. The way it worked was that an effect would be fired off from the game code on the server, pass general information across the network (such as effect ID, location, and its owning entity), and then send effect-specific information per effect. The client effects DLL on the client would then update the effects, and remove them when culled off screen or completed. Most effects, in fact, had no extra information, which helped out quite a lot. Programmatically, this whole system turned out to be a mixed blessing — as we will discuss later — although in game play 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 to that end). After viewing the slide-show speed of the game that resulted from these efforts, however, we decided to scale that back a little. MMX implementation helped a lot, but it still required some major rewriting 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, for a variety of reasons. Seeing Corvus perform his animations smoothly, for example, was critical to a fun multiplayer experience. Further, 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.

Concept sketch from Heretic II [zoom]

We added quite considerably to the whole sound system, and split sound support off into a separate DLL. The idea was to have three separate DLLs, 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 completed before the release dates were 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.