Fifteen years ago today, the campy shooter No One Lives Forever 2: A Spy in H.A.R.M.’S Way was released. To celebrate its anniversary, we present this classic postmortem of the game's development.
In honor of the 15th anniversary of the release of the campy shooter No One Lives Forever 2: A Spy in H.A.R.M.’S Way, we present this classic postmortem, which first appeared in the January 2003 issue of Game Developer magazine.
Sadly, this venerable franchise from Monolith Productions has not received the rerelease that it richly deserves, and that many are clamoring for, due to what seem to me insurmountable licensing issues. But the story behind its design is still fascinating.
This in-depth look at what went right and what went wrong during development was written by Craig Hubbard, who was Monolith's creative director at the time.
When creating a sequel to a critically successful first-person action-adventure game, it’s not enough to measure up to the original. In order to meet fans’ higher expectations, you have to surpass it.
Unfortunately, the dizzying rate at which game technology evolves means you’ll probably be rewriting major engine components, such as your renderer or physics, as well as adding and revising game systems and overhauling tools and exporters. Your characters and environments will probably be more detailed, with more animations, more special effects, and more layers of complexity. In other words, you’ll spend more time on less content.
There’s also the problem of keeping people motivated. No one wants to spend a year and a half rehashing a game they just spent a year and a half developing. So you have to evolve the design sufficiently to excite the team, present new challenges, eliminate or rework elements of the first game you didn’t like, and explore new gameplay concepts.
At the same time, you have to stay true enough to the essence of the previous game that you don’t completely alienate your fan base. You’ll find that many fans really want more of the same, only better, so you have to strike a balance between evolution and reiteration.
Our mantra for the recently released No One Lives Forever 2: A Spy in H.A.R.M.’S Way (NOLF 2) was to create a game in the spirit of the original but not necessarily in its image. Judging by early reactions, we were fairly successful, although the game is certainly not without its shortcomings.
As proud as we were of the original No One Lives Forever (NOLF), released in late 2000 (for which I also wrote a Postmortem, available here), we didn’t want the sequel to be more of the same with different levels and new characters.
The surest way to doom a franchise and alienate a team is to make decisions based on what was in the original game. Instead, we chose to navigate by what worked well in the original game.
We began by evaluating reviews and fan reactions to NOLF, comparing the general consensus to our own opinions, and charting out a course of action building on the first game’s strengths without reiterating its weaknesses.
It was imperative that we identify elements that fans liked and disliked, but it was also useful to identify which things no one noticed at all. Every feature in a game takes time to design, develop, refine, and test, so squandering precious days or weeks on anything that won’t register with users is the last thing you want to do.
Based on our research, we determined the franchise’s key elements were: a variety of interesting locales; memorable events, such as falling out of an airplane or being aboard a sinking cargo freighter; humorous conversations, documents, and characterizations; and an intriguing story told through cutscenes and in-game encounters.
The franchise’s flaws included a lack of visual polish; frustrating stealth elements; overly long, tedious cutscenes; and the inclusion of superfluous weapons and gadgets.
These summaries helped immensely in characterizing the essence of the NOLF franchise, but they also pointed out some fundamental problems we would face in creating the sequel. For example, given our schedule, it wasn’t possible to produce the same variety of locales; because the content would be significantly more detailed, it would take longer to create.
We also wanted a stronger, more deliberate visual presentation, which meant devoting more effort to each set. Furthermore, NOLF had made it clear that the more time spent building level geometry, the less time could be spent implementing gameplay.
Other issues were easier to address. NOLF had included roughly 30 weapons and gadgets, with a lot of overlap. For example, there were three pistols, two sniper rifles, several very similar missile-type weapons, and a couple of gadgets — such as the camera disabler and robotic poodle — that where rarely used. NOLF 2 has about the same number of items, but with a wider variety, including such devices as the Angry Kitty, banana, and bear trap, to compensate for the absence of the redundant firearms.
Our efforts to make stealth more intuitive and rewarding resulted in a redesign of the entire AI system. We decided that if we were going to allow players to sneak around and spy on their enemies, those enemies had better be doing interesting things. So Jeff Orkin, our AI engineer, and John Mulkey, our lead level designer, spearheaded the design of a goal system that would give non-player characters a sense of purpose, as well as a Smart Object system that would provide them with cues on how to interact with the environment.
The key to these systems is their unscripted nature. An NPC may start off working at a desk with a typewriter, get up and head over to the vending machine for a can of soda, step outside for a cigarette break, lean against a wall, walk over to a window to admire the view, and even run off to the restroom for a potty break. To ensure that players would be able to observe these behaviors, we effected a system that let us designate hiding places in levels from which you can watch enemies without being seen. Our implementation left something to be desired, but it still served the purpose of making stealth easier.
A more important refinement was to make it easier for players to escape from enemies. In NOLF, we used a time-based solution to determine whether an NPC would give up its pursuit, but it had lots of limitations and never worked very well. In NOLF 2, your ability to elude an enemy is based on passing through junctions. When an NPC reaches an intersection and doesn’t see which way the player goes, it picks a course randomly.
Level designers can weight a specific direction to make this decision-making seem more intuitive, so that an NPC is less likely to investigate an alley than to continue down a major street. Designers can also specify what actions an NPC takes when it chooses a particular path. For example, if the NPC chooses to explore the alley, it may switch to slower, more tactical movement, whereas if it chooses the street, it keeps running.
Cinematics were another major consideration for the sequel. On NOLF, I implemented the cutscenes very late in the project. By the time I realized how long and tedious some of them were, it was far too late to do much about it. Also, the sheer number of cutscenes in the game limited the amount of time I could spend on each, which adversely affected the overall quality of the presentation.
By contrast, I finished the NOLF 2 cinematic script very early in the project. Once it was approved, we scheduled motion capture and placeholder voice sessions, which allowed me to implement first-pass cinematics that we could review for pacing, clarity, and continuity. Gradually, we began to finalize sets, animations, voice work, and pacing. Scott Albaugh, our primary character artist and animator, added the final polish with detailed facial animations and hair and finger movement. These touches really brought the cutscenes to life.
In retrospect, the conciseness of NOLF 2’s cutscenes may have overcompensated somewhat for the tedium of the original’s. Compounding the issue, I chose to tell a different type of story on this project in an effort to avoid stagnation, which alienated some fans wanting a narrative more in tune with NOLF’s but appealed to others who wanted something new. Ultimately, this conflict illustrates one of the perils of creating a sequel. You have to evolve the franchise enough to keep it fresh, but not so much that you transform it entirely. It’s a difficult balance to strike.
After the debilitating chaos of NOLF’s early months, we were determined to schedule a preproduction phase for NOLF 2 that would allow us to plan, prototype, and refine its core design before we started building publishable content or technology. The idea was that by the end of the preproduction period, we’d have a design that we could execute during production, refine during alpha, and test during beta.
Overall, preproduction was tremendously beneficial, with a shipping product remarkably faithful to the blueprint. Despite the inevitable setbacks and minor changes during production, our plan was solid enough to survive a complete rewrite of the renderer, new player physics, and various other technical and conceptual calamities. We remained flexible enough to revise and streamline as necessary, but it’s a testament to the value of preproduction that such changes were largely unobtrusive.
NOLF 2 was completed on time and on budget, evidence that an AAA title can be developed in 18 months with effective scheduling. A detailed plan allowing us to draw up thorough, itemized task lists was the key. The team’s experience enabled us to furnish realistic estimates, adding buffer time for insurance.
We also insisted upon a prioritization system that not only guaranteed that critical features would be completed first, but also allowed us to jettison low-priority items (should time become an issue). Because both Monolith and our publisher, Fox Interactive, agreed upon this plan during the preproduction phase, cuts made during production were much less painful.
We were also smarter about how we scheduled the project. We allowed longer alpha and beta periods to ensure more time for play-testing and polish. We made sure to leave more room for E3, demos, and marketing and PR materials, as these interruptions had blindsided us on NOLF. The result was that in spite of all the obstacles and unforeseen challenges we faced on NOLF 2, we hit our ship date with a product that we’re very proud of.
We knew early in preproduction that NOLF 2 would be more focused than its predecessor. Given the amount of extra detail that had to go into characters, environments, and objects, we couldn’t hope to produce the same amount of content without forsaking quality, unless we streamlined the content creation and management pathways to let us work faster and more efficiently.
The single most important tool we added was the referential prefab system, allowing us to populate environments with objects that refer back to one original source file. In other words, edits made to one file propagate throughout the entire game. For example, if the sound department wants to add a sound to a door opening and closing, they only have to modify a single prefab instead of tracking down every single instance of that door in the game.
The primary advantage of this system is that it puts the power in the hands of the people who need it, without any programmer intervention. A level designer can create a block of geometry that represents a desk, with which he or she can plan the layout of a given room. The art team can then build a nicer-looking desk of roughly the same dimensions to replace the block. Level designers can hook up the drawers to open and close and add work nodes so that AIs can sit and type or fill out forms.
Other important improvements included robust exporters for 3DS Max and Maya, which let us build and texture geometry in professional 3D packages and import it into our proprietary editor, where we added gameplay. Rather than enumerate every improvement, I’ll just say that the decision to focus on upgrading our tools not only saved us immense frustration but also led to significantly higher quality content than we would have been able to produce otherwise.
On NOLF, certain lead positions remained unfilled for months after the contract was signed. As a result, some of the most crucial people on the project arrived when it was already well underway. They inherited decisions that had been made without adequate expertise or experience, leading to redesigns, cuts, and inconsistent quality.
At the beginning of NOLF 2, we had great leads and good project management across the board. These key personnel were able to produce the detailed, organized documentation we needed in order to communicate with each other and our publishing partners. They were also able to provide accurate time estimates that led to a realistic schedule. The simple fact that we achieved most of what we set out to do without missing our ship date demonstrates the value of competent leadership.
The cooperative multiplayer component of the game proved challenging, but as we had hoped, it ultimately was far more complementary to the single-player game than competitive modes would have been. Much of what constituted the cooperative experience came directly from the single-player game, but some of the features we developed chiefly for cooperative play worked their way back to single-player and resulted in a better product.
For example, we added the radar feature for co-op play but quickly realized its value for solo play, which in turn led to tracking darts which allow players to mark enemy positions. In contrast, the competitive modes we added to the original NOLF really didn’t benefit the single-player game at all. Furthermore, we found that traditional multiplayer divided our efforts, which resulted in a whole slew of new bugs, distracting the QA department.
In retrospect, we would have been smarter to add competitive multiplayer as part of the NOLF support package, which is what we’re doing with NOLF 2. This approach allows us to focus our development and quality assurance efforts instead of diluting them across very different types of experiences.
Building a solid, stable team was the most challenging hurdle we faced; in addition to replacing a couple of people who went to other projects, we needed to expand the team in a couple of key areas. The process of advertising available positions, screening potential candidates, arranging interviews, and getting new employees on-site for training consumed enormous amounts of time.
To complicate matters, our initial recruiting phase included several bad hires. In some cases, new employees proved to be less skilled than we had hoped; in others, poor attitudes or work habits led to dismissals.
Another major snag was that several team members, including me, had to help out on Aliens Vs Predator 2 for several months. The time we invested in that project was well spent, but NOLF 2 paid the price; the work we should have been doing on NOLF 2 had to be delayed until we returned. Given how many interdependencies there are on a project of this complexity, such setbacks can be frustrating and costly.
While preproduction was incredibly valuable for NOLF 2, it wasn’t long enough. Ideally, we would not only have finalized the design but also fleshed out a solid playable prototype. We couldn’t manage both in the three months available.
While our plan had been fairly thoroughly laid out, it hadn’t been tested. This was our main problem. Therefore, any hitch we encountered affected the schedule. Needless to say, we ran into plenty of hitches and had to make lots of adjustments. By the time we shipped, we cut an entire mission from the game, numerous levels had been simplified, and our hopes of offering multiple solutions to every obstacle had been dashed (as I’ll explain shortly).
Our goal was to have a solid plan by the end of preproduction that we would then execute during production and refine during alpha. In retrospect, we should have completed a rough draft of the game sooner in order to identify weak links and pacing issues while there was still plenty of time to address them. As it was, we ended up making some drastic adjustments very late in the project.
For instance, we removed the entire exfiltration from Japan, which proved not to be as exciting as we hoped. In another case, we added an action-oriented level to break up a long section of slower-paced gameplay. These changes inarguably improved the game, but they should have been made earlier in the process.
Also, while the game was decidedly more systemic than its predecessor, we still spent a lot of time tracking down individual items that could have been systematized. These cases usually involved components that couldn’t easily be converted to prefabs. The windows in the main records building of the Siberian outpost were especially problematic, because they were all different sizes and shapes. If we wanted to change the amount of damage they could sustain before shattering or the radius of the resulting disturbance, we had to modify each one manually.
Finally, while play-testing helped balance and tune the game, it should have happened sooner. Thanks to observing playtesters, we made some crucial refinements to the stealth system and the opening missions, but we didn’t have sufficient time to play-test the entire game. Play-testing also revealed some design flaws that couldn’t be addressed without jeopardizing our ship date. While none of these issues was especially grave, they underscored the need to start play-testing as early as possible.
During our analysis of NOLF, it became clear that the sequel would require significant graphical upgrades to compete in the rapidly changing PC game market. Upgrading our graphics required a rewrite of major engine components, such as the rendering pipeline. Because many of these features were not completed until after production had already begun, the team was occasionally forced to rework content as new technology came online.
The most dramatic change was the new renderer’s occlusion system, which proved difficult to use and required a learning period for artists and level designers. During this time, the content team was in full production, meaning that environments were being created and detailed without a thorough understanding of the system’s intricacies. Consequently, several layouts had to be significantly modified after a great deal of time and energy had already been invested in them.
While our scheduling was vastly better on NOLF 2 than on NOLF, we still crammed things too tightly for our own good. Unexpected budget cuts early in production ate up most of our buffer time. The aforementioned team issues took their toll as well.
Most of us worked at least 100 hours per week during the last several months of the project, and some people were crunching even before that. In NOLF 2’s closing credits, special thanks are given to Metrolabs, the developers of XTZ caffeine and herbal energy drinks, whose products sustained several team members in the absence of adequate sleep.
Time constraints led to some disappointing compromises. My most painful concession was giving up on our ambition to allow multiple solutions to every problem, which resulted in various points in the game where you must procure a specific inventory item in order to proceed.
For example, in Chapter 4, which takes place at a Siberian military outpost, there was a point where you had to get through an electrified gate. Only one of several planned options survived. Unfortunately, the easiest option to implement from a development perspective was the least desirable from a gameplay perspective.
Another problem was that there still wasn’t enough time scheduled for public relations and marketing assets. We didn’t anticipate that people would want so much from us. While being overwhelmed with requests for interviews and screenshots is certainly a great problem to have, it would have been better for everyone involved if we’d been more prepared.
THE PRICE OF SUCCESS
I concluded the original NOLF Postmortem by remarking that Monolith had matured from a disorganized but enthusiastic young company to a focused, professional business. NOLF 2 is the proof. Although the game is by no means perfect, it’s a testament to the value of planning, organization, prioritization, and experience.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
