|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Activision's Heavy Gear 2
After a long series of successful titles such as MechWarrior 2: Ghost
Bear's Legacy and MechWarrior 2: Mercenaries, Activision
held a dominant position in the giant-robot genre. Due to the commercial
success of this series, though, a tidal wave of similar products developed
by worthy competitors began to flood the market. Fortunately, Activision
found a new and exciting universe in Dream Pod 9's Heavy Gear
pen-and-paper-based game, and in the fall of 1997, Activision Studios
began production on the futuristic giant-robot simulator Heavy Gear
II. To create such an experience, Activision assembled a new team of its best and brightest in the areas of programming, art, design, and management. A very aggressive schedule was adopted targeting a fall 1998 release date (a 13-month development schedule). Our original staff consisted of a lead, graphics, AI and tools, multiplayer and shell programmer. We had a lead artist, two 3D modelers, a 3D animator, and two 2D artists creating texture maps for the models and terrain. We also had a lead designer who managed a group of three game designers, all of whom transformed the storyline from paper into a computer game. Our management group consisted of a director, a producer, and an associate producer, who controlled the schedule and the development and direction of the game and saw to the many needs of the other production staff. We programmers were chartered to create a new game engine and I took on the role of AI, scripting system, and tools programmer. At the heart of this engine was a rock-solid memory management and leak-tracking class. Yes, that's right. Before anyone ever dreamed of fancy graphics or stunning game play, we had to deal with this mundane task. Every C++ class and structure used by the Darkside engine had roots within this base class. This architecture allowed to us to detect memory leaks and overwrites as soon as they appeared in a given day's build, which allowed us to address problems immediately rather than during a grueling cycle at the end of the project. I cannot stress the importance of this type of planning and execution enough for teams who want to craft a state-of-the-art game engine. Focusing on the reliability of the application will also greatly increase the immersion factor of any game that's created with it. After all, what destroys immersion more than a hard system crash? Hats off to our lead who took us down this path. The decision was made to target the game only for machines outfitted with 3D-accelerated video cards. This issue was hotly disputed within our team for a while, but when our management group realized that in order to pull off realistic 3D graphics, software emulation was a dead deal. This had profound effects on the schedule, as it freed our artists and programmers from dealing with the time-consuming and tiresome work of generating alternate LODs for such a purpose. This decision also eliminated a huge chunk of our QA test plan, which could have pushed back the release date of the title significantly further. We had to choose between putting out the highest quality game we could and targeting a consumer market that barely existed at that point, or publishing a game that had a greater current market base and little or no novelty by the time it was released. I suppose it is something all of us developers must deal with in these days of rampant technological change.
The AI system was another great challenge, as it would dictate much of the feel of the game. It would also be a key tool for our design team as they implemented the complex storyline. We decided at the high level to go with a pure "autopilot" approach, in which enemy and friendly AI alike were able to function intelligently without any script at all for individual units. We wanted to be able to put a unit into the world and have it go do whatever it thought it needed to do. Internal to this was a high-level strategic system, a team-based tactical system that employed a knowledge base, and a low-level, unit-specific order execution system. The goal was to take much of the burden off of the design staff, and give the game a consistent and distinctive feel across all missions. Nonetheless, our scripting system was very effective and had some nice features such as an in-game debugger complete with break points, single-step execution, and variable watch windows. It was based on LEXX/YACC-based C grammar, which hooked into a powerful and easily extensible virtual machine that resided in the Darkside engine. Our scripting system was hooked in to our custom game API, which in turn was coupled to prototypes defined in a file called STDHG2.H, which ostensibly replaces STDIO.H (a file well known to all of you C programmers out there). Amazingly enough, STDHG2.H was used not only to compile the scripts, it was also used in the compilation of the Darkside engine itself. This convenient relationship between the scripting language and the engine source code, plus the fact that the C language is widely documented, easily justified our decision use a scripting language based on C. Scripts were used mainly to monitor mission progress and objectives, special behaviors (convoys and patrols, for instance), and interactive control of the action. Our goal was to keep these scripts as simple as possible. The autopilot handled all strategic, tactical, and low-level operations of unit behavior, yielding control only at the request of a script. The autopilot was the default AI handler in the engine. Scripts could override this system by posting event callback requests as shown in Listing 1. Our multiplayer system was crafted using a proven proprietary networking SDK developed at Activision. This reliance on preexisting technology allowed us to get multiplayer functionality in the engine and working very early on in the development cycle. Designing and integrating multiplayer functionality is often left until the end of a project, and that can create all manner of problems. Getting this level of complexity into our development schedule early probably saved the Heavy Gear II team an additional six months of work. ________________________________________________________ |
|
|
Features
Introduction
Heavy
Gear II allows game players to suit up in a giant, high-octane,
humanesque battle tank called a "Gear." The player is then required
to outfit a wily band of AI Gears (called "squadmates") and arm them
to the teeth. Their small but heavily armed reconnaissance force must
infiltrate and overcome a rich variety of environments including swamps,
icy wastes, angry red planets, and the weightless reaches of outer space.
The action in Heavy Gear II is much faster than in other giant
robot simulators, as Gears are substantially smaller than Mechs and
much more fragile. This requires squads to rely primarily on stealth
and cunning rather than brute force and wanton destruction. Players
are forced to pick their battles wisely or face annihilation from the
superior enemy legions that infest the various worlds they traverse.
When pilots are tired of playing against computer opponents, they can
pit themselves against human enemies in multiplayer mode with a number
of game types to choose from including "steal the beacon," "king of
the hill," and good old-fashioned deathmatch. 
