Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Monolith's No One Lives Forever
View All     RSS
September 25, 2018
arrowPress Releases
September 25, 2018
Games Press
View All     RSS
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Monolith's No One Lives Forever


June 8, 2001 Article Start Previous Page 3 of 3
 

What Went Wrong

1. Signing the deal. We were months into development before we had a signed contract for No One Lives Forever, although various publishers had green lighted the project no fewer than four times before then. During this interval, the project mutated constantly in order to please prospective producers and marketing departments. The game actually started off as a mission-based, anime-inspired, paramilitary action thriller intended as a spiritual sequel to Shogo and ended up as a 60s spy adventure in the tradition of Our Man Flint and countless other 60s spy movies and shows. The schedule fluctuated between a minimum of six months and a maximum of twenty-four, the intended feature set scaling accordingly.

Needless to say, it took us a while to get a handle on exactly what we were making, which tended to be a bit disquieting. Really, though, you can't take it personally. You just have to adapt and survive, which is precisely what we did. Each time the schedule changed, we came up with an entirely new proposal instead of trying to cram a 20 month game into 11 months. It just so happened that when the roulette wheel finally clicked to a stop, we were planning to make a 60s spy adventure game. As I mentioned, we were then able to draft a mission statement and stick to it, but we bled away many precious weeks prior to that point.

The schedule fluctuated between a minimum of six months and a maximum of twenty-four, the intended feature set scaling accordingly.

2. Fleshing out the team. It wasn't until some time after we had a signed contract until we had a stable team. Almost every aspect of the project was affected. We lost a product manager, two engineers (although, thankfully, one came back to the fold), and three 3D artists. Level designers came and went.

Part of the problem owed to our publisher woes. On two separate occasions, what was effectively the cancellation of the project resulted in our not being able to hire people we were planning to bring aboard. Without funding for the game lined up, it made no sense to bring on new employees.

Another source of instability for the team was the desire to provide stability for Monolith as a whole. In the aftermath of Shogo and Blood 2-which led to the restructuring of the company, the liquidation of our publishing efforts, and the resignations of a number of people either burned out by grueling development cycles or disillusioned by the problems that led to them-we had three projects entering development but only a handful of people experienced with LithTech, so we redistributed this modest wealth of experience to maximize our efficiency. In the full course of time, both Monolith and the NOLF team were better off, but it was a demoralizing, debilitating process, from which the team took months to fully recover.

One additional complication was the difficulty of hiring level designers who were not only talented enough for the job, but also capable of becoming valuable members of the team. In some cases, we hired amateur designers who were used to making levels for finished games and therefore found it difficult to put up with unfinished tools, missing features, placeholder content, and all the other compromises professional level designers have to contend with on a daily basis. In other cases, we hired professionals whose attitudes, productivity, and quality were anything but.

3. Inefficient pre-production. Given the prolonged uncertainty at the beginning of the project, it's not especially surprising that pre-production was neither as thorough nor as productive as it could have been. We had certainly done a tremendous amount of research, but not enough of it was focused on things that would benefit the project directly.

Most notably, planning for the game environments was too broad and unfocused to provide the foundation we had hoped for. As a result, level designers often started working on a setting with plenty of reference material but without the proper direction. A folder packed with miscellaneous images isn't especially useful compared to a handful of carefully selected references organized and agreed upon by everyone who will be involved in creating the area.

Another complication was that every time the schedule expanded or contracted, which it did on a regular basis those first few months, the feature list changed along with it. Unfortunately, most of the expansion happened late in the process-when the project jumped from 11 months to 18-which meant we had to add features at the last minute in order to fill out the development cycle. Under the circumstances, it was impossible to spec everything out fully before we signed the contract, effectively committing us to features we hadn't fully investigated.

It's easy to dive headlong into development the moment a contract is signed. The excitement of starting something new and the urgency you feel when you look at the schedule encourage you to get started right away. It's only months later when you're slaving to finish up all the partially implemented features and redo unacceptable levels for the third time that you realize that effort spent in pre-production pays for itself many times over during the final weeks of the project.

Cate Archer, the central character in NOLF.

4. Waiting on technology. Although our technology goals for No One Lives Forever were relatively modest, they were all so organic to gameplay that the delays we encountered in finishing them prevented us from tackling certain aspects of the game until far too late in the project. Probably the chief culprits were the terrain system, the animation system, and the vehicles, which all proved to be more challenging than we'd expected because, as I mentioned, they weren't investigated thoroughly enough before we agreed to them.

Ultimately, we were able to complete each of these features at least to our satisfaction, but the fact that they all took so long meant we didn't have time to take the fullest possible advantage of them. In retrospect, it was a mistake to sign up for so much technology centered on gameplay for a project of this scope.

5. Cinematic overload. This point is admittedly a bit self indulgent, but I'm the one writing the post mortem, after all. Anyway, if there's one aspect of the game about which I remain ambivalent, it's the in-game cinematics. I'm generally pleased with the understated camerawork and shot composition, and there are definitely scenes I'm proud of, but overall there's plenty of room for improvement. The problems fell into a couple of distinct categories:

Technical difficulties. Implementing in-game cutscenes in NOLF proved to be a frustrating, time-consuming ordeal, especially considering how many of them there were. As a result, I generally had to go with the easiest solution rather than the most desirable one. Due to time constraints, I also had to sacrifice many of the cutaways I'd hoped to do to keep the briefings interesting. To make matters worse, we'd done the motion capture based on the original script, so with the cutaways excised, I had a very limited pool of applicable animations to draw from.

The bottom line is that rudimentary cinematic techniques that filmmakers rely on and take for granted can be a massive headache for game developers. A movie director can say, "Hey, Joe, can you pick up the gun, check to see if it's loaded, and then go over and peek through the shades?" For a game developer, just getting a character to pick up the gun convincingly can be a technical nightmare. Any time a character interacts with an object, the environment, or another character, you're likely to spend a lot of time simply trying to make it look natural. When time is in short supply, complicated blocking that adds life to a scene get simplified.

Implementing in-game cutscenes in NOLF proved to be a frustrating, time-consuming ordeal, especially considering how many of them there were.

Conceptual flaws. The biggest problem was a conceptual blunder on my part. Instead of relying on my understanding of scene structure and exposition in film, I fell into the trap of thinking of game cinematics as stylistically unique, partly because games run so much longer than films and partly because the player, by stepping into the role of the hero, would seem to require more information than an audience watching the story unfold. The most obvious byproduct of this oversight was that I deviated from standard screenplay format, which made it impossible to gauge the duration of a given scene. In filmmaking, a page translates to roughly a minute of screen time. The NOLF script was far more dense than a screenplay, which made it easy to underestimate the how long a scene would run.

If you've played NOLF, you might be surprised to learn that my screenwriting problem has always tended to be divulging too little information. I favor tight pacing, defining character by action rather than dialogue, and subtlety over obviousness. When I was writing this script, probably because I was inventing my own format, I fell into novelistic conversational rhythms. The problem is that what flows on the page tends to drag on screen.

Unfortunately, by the time I recognized the mistake, it was way too late to do anything about it.

Applying the Lessons

Historically, Monolith has always been brilliant at making mistakes. We've already done most of the boneheaded things that tend to sink development studios. Fortunately, we've also been exceedingly lucky when it comes to surviving these mistakes. Perhaps part of the reason is that we're eager to learn from them so that we don't repeat them. In the five years I've worked here, Monolith has matured from a disorganized but enthusiastic young company to a focused, professional business.

Already, the experiences of NOLF have led to significant improvements to our scheduling, preplanning, team structure, and development process. We're more careful than ever before about what we're willing to commit to. We're even more tightly focused on quality and polish.

The expense of developing a game continues to rise dramatically. Meanwhile, the market isn't expanding fast enough to offset these costs. Unless you are financially independent enough to do whatever suits your fancy, the only viable solution if you want to stay in business is to find smarter, more efficient ways to create a competitive product.

 


 

Monolith Productions
The Operative: No One Lives Forever

Publisher: Fox Interactive

Number of full-time developers: Approximately 18 Core Team Members

Number of contractors: Music, Motion Capture Actors and Voice Actors

Length of development: Approximately 2 years

Release date: Gold on October 20th; Released around November 18th

Target Platforms: PC

Development hardware: Pentium 2/3 300-550, TNT2 and Geforce video cards

Development software: LithTech DEdit/ModelEdit, Microsoft Visual Studio (C++), Photoshop, SoftImage

Notable technologies: LithTech 2.x GDS

Project size:~ 1000 files; ~ 110,000 lines of code

 

 


Article Start Previous Page 3 of 3

Related Jobs

Experius
Experius — Culver City, California, United States
[09.25.18]

Unreal 4 Designer/Engineer
Cryptic Studios
Cryptic Studios — Los Gatos, California, United States
[09.24.18]

Level Designer, Magic The Gathering MMO
New York University Tisch School of the Arts
New York University Tisch School of the Arts — New York, New York, United States
[09.24.18]

Assistant Arts Professor, NYU Game Center
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[09.24.18]

Studio Design Director





Loading Comments

loader image