What Went Wrong
1. Poor level design process
Level design is a clearly defined professional activity in the game industry. It's a profession that mixes artistic and technical skills in equal measure, and the bar is raised on both fronts every year. Despite our understanding from the very beginning that the level building would be a problematic part of the System Shock development process, we didn't quite grasp how difficult and time consuming it would be, nor did we expect that it would eventually block the shipment of the game.
In hindsight, our failure to understand the amount of work needed to design levels is reprehensible given that we had seen the same problems emerge on Thief, and that System Shock 2 levels involved substantially more complex object placement than Thief. I attribute this error mostly to our denial of the problem - we had a limited budget for level designers and there is a long training time required to get designers familiar with the complex Dark Editor. So we locked ourselves into working with the resources we had. Since each individual task required from the designer (apart from initial architectural work) was relatively simple, it was easy to believe that the sum total of work was also relatively small. What we overlooked was the fact that System Shock 2 involves so many objects, scripts and parameters. As such, the work load on level designers was excessively large. In addition, we made a classic beginner's mistake and failed to provide adequate time for tuning in response to play-testing feedback. In System Shock 2 this was particularly important because the ability of the player to re-enter levels means that the difficulty of a level cannot be adjusted in isolation from the rest of the game. Often we had to impose global changes across all levels, which could be very expensive even when the change was relatively minor.
Cold comfort in Hydroponics.
We took a novel approach to the level building process by attempting to apply design levels using a production-line method. Using this metaphor, we attempted to divorce the different stages of work on the level: rough architecture, decorative and functional objects, architectural polish, and lighting. It was not considered necessary for the same individual to be involved in all stages of this production process. This approach had positive and negative consequences. The advantages were that we could track progress on levels, we could "bootstrap" levels fairly quickly, and we could (in theory) swap individuals in and out of different tasks. The disadvantages are fairly obvious, and most stem from the fact that the various stages of level design are clearly not independent (for example, architecture is ideally built with an understanding of the functional objects that are to be used in the level). Although I think our process was necessary in order to get the game out on time, it probably detracted from the quality of some of the levels. In addition, psychological factors, such as lack of ownership and training issues (stemming from unfamiliarity with levels) speak very strongly against transferring people from one task or level to another. Nevertheless, there were several benefits of our procedure - mostly the ability to employ particularly talented individuals to pinch hit on particular levels, and the psychological benefits of completing architectural work early in the schedule.
Perhaps the rudest shock in our level building process came from our misunderstanding of what part of the process would prove to be most difficult. Architectural work was actually fairly simple, because we intentionally kept our spaces fairly clean and did not attempt anything too unusual. However, placing and implementing our objects was far more complex and involved than we expected. One difficulty that we encountered was educating our designers in what was expected from them in terms of game-play implementation. Most of our level builders had previously built Quake or Unreal levels and were not familiar with the style of game play that we were trying to build in System Shock 2. Partially this was because we were simply exploring a style of game play that we did not entirely understand ourselves. But it reflected a failure on our part to properly educate the designers. Building prototypical spaces, looking at past games and conducting more intensive discussions about game play will all be part of our future projects.
Our other major design hurdle was the instability and inscrutability of Dromed, the Dark Engine editor. Dromed is a cantankerous beast and many man-months were spent struggling with its idiosyncrasies. Perhaps our biggest problem stemmed from the lack of support in one crucial area - the part of the engine concerned with translating the designer-placed brushes into the basic world representation. Like many complex 3D engines, the Dark Engine suffers from troubling epsilon issues (data errors caused by rounding inaccuracies) and other glitches that crop up during level compilation. Because the programmer who implemented the basic renderer and world representation was not available during the majority of the System Shock 2 development cycle, we had to work around these problems. It was often a frustrating process when the fundamental cause of the problems was not even known. Over time we developed a set of heuristics to avoid the majority of the glitches, but we were forced to lock down much of the level architecture before we wanted to in order to ensure stability.
2. Motion capture difficulties
The Dark Engine has a complex creature animation playback system and deformable mesh renderer. We encountered many problems with this piece of technology along our data integration path, and found quirks in the playback systems as well. Primarily, the system was hampered by the fact that data frequently had to be modified by hand, that mysterious bugs would appear in motions during playback which had not been present in the source data, and that few tools were available for debugging and analysis. We were ill-equipped to deal with these kinds of problems, having devoted few resources to dealing with the technology problems.
Our primary animation source was motion capture data. We were nervous about the technology from the start and attempted to minimize our risk by concentrating primarily on humanoid creatures with a small number of interesting variants such as spiders and floating boss monsters. In retrospect, this was a very wise decision, as we had a lot of trouble even with this simple set of creatures. Motion capture technology and capture services were contracted from a local company, but unfortunately this company viewed its motion capture work primarily as a side business and did not display much interest in it. In fact, they cancelled this sector of their business during our project, and we had to fight hard to complete the sessions that we had already scheduled with them.
Our capture sessions were hampered by our inexperience with the technology and by the fact that we did not plan properly for the sessions. We hadn't defined key poses, rehearsed the motions, or ensured that our motions were compatible with the technology. Optical capture technology, the technology that we used, can be glitchy and has difficulty with motions that have obscured markers, as in the death motions that were necessary for System Shock 2. Over the course of three sessions, we gradually refined our motions, but we spent a lot of time reshooting failed captures from earlier sessions.
Even in the best cases, most of our captures exhibit strange artifacts (feet pointing down through the ground, hands improperly aligned, and so on), whose causes are still unknown to us. In future projects we will hand-animate almost all of the data, and we will need to understand better what aspect of the conversion process introduced these artifacts into our final game animations, although the irregularities never appeared in our raw data. Motion capture technology, while highly efficient compared to hand animation, must be approached carefully to obtain good results.
3. Implementing scripted sequences
Xerxes, central computer of the Von Braun
Motivated by the dramatic scripted sequences in Half-Life, we attempted to introduce similar elements into System Shock 2. In doing so, we broke one of our rules: we tried to step outside the bounds of our technology. Although we attempted relatively simple sequences and ultimately got them working, they were time sinks, and the payback was relatively slight. For example, we scripted a hallucinatory sequence in which the player character rides through the interior of the alien boss-monster, known as the Many. This so-called "Many ride" was the source of innumerable bugs -the player would be thrown off the moving platform, manage to kill his projected self, bump into walls, and so on. We confirmed our intuition that the Dark Engine does not support complex scripted sequences well because the toolset (AI, moving terrain, and animation) is not optimized for this sort of behavior. The moral is, once again, to work with your technology, not against it.
4. Inexperience with multiplayer game development
Early in the project we were asked to identify the major risks associated with the project. Our number one candidate by far was the multiplayer component. This was the only new substantial engine feature that was to be added and it was a complicated piece of work. We were particularly nervous about this technology for a couple of reasons. First, it is usually much harder to make this kind of pervasive change to an existing piece of software than it is to build it in from scratch. Second, Looking Glass had no track record in shipping multiplayer technology and we were not confident that the development was fully understood.
Irrational did not want to introduce multiplayer support into System Shock 2 because we considered it a tangential feature that did not contribute to our core strengths. However, marketing concerns dictated it, so ultimately we acquiesced. Our lack of enthusiasm for this feature contributed to its developmental problems because we failed to monitor its progress adequately or raise concerns when that progress fell behind schedule.
Because this was the first multiplayer product developed by Irrational or Looking Glass, we did not properly estimate the time required for the multiplayer testing. We did not devote adequate quality assurance resources to this feature. Too much time was spent testing the multiplayer features over the LAN and not enough over the more demanding modem connections.
Given the difficulties posed by the multiplayer technologies, the engine developers working on the task made great efforts, and their early results were promising. However, the early departure of one of the programmers, and the fact that he was not replaced, ultimately doomed any possibility of shipping the multiplayer technology with the initial SKU. Reluctantly, we opted for a patch that would be available at the same time as the single-player box reached shelves. Our cooperative multiplayer game will undoubtedly be fun and will probably be enjoyed immensely by a relatively small number of our customers. However, we wonder whether our failure to deliver a promised feature in the box will ultimately hurt us more than the absence of that feature from the start would have.
5. Running a company while building a game
As the principals of the company, Ken, Rob and I didn't really understand what it took to run a business and simultaneously work in that business. None of the Irrational founders started the company to be businessmen, and we have always believed that the ultimate health of the company depended on us all staying involved in the development process, which is, after all, what each of us enjoys and wants to do. Unfortunately, as anyone who has run a business knows, there is a lot more to starting and maintaining a company than sitting around at board meetings smoking cigars. From the mundane matters of making payroll, organizing taxes and expense reports to business negotiations and contract disputes, there is substantial overhead involved in running even a small company such as Irrational. In our naïveté, we did not factor these tasks into our schedules and the result was that they mostly became extra tasks that kept us in the office late at night and on weekends.
System Shock 2
Irrational Games LLC
Looking Glass Studios Inc.
Release date: August 1999
Intended platform: Windows 95/98
Project budget: $1.7 million
Project length: 18 months
Team size: 15 full-time developers, 10-15 part-time developers
Critical development hardware: Pentium II machines, 200MHz to 450MHz with 64MB to 128MB RAM, Nvidia Riva 128, Voodoo, Voodoo 2, TNT cards, Creative Labs' sound cards, Wacom tablets, Windows 95/98. Also used SGI Indigo workstations.
Critical development software: Microsoft Visual C++ 5.0, Opus Make, 3D Studio Max, Adobe Photoshop, Alias|Wavefront Power Animator, DeBabelizer Pro, RCS, Filemaker Pro, and Adaptive Optics motion capture software.
As a result of our misjudgment, we just had to work harder. Rather than enduring a crunch period of a few months, the entire last year of the project was our crunch time, as we struggled desperately to fulfill our jobs as programmers, designers, and managers as well as keep the money flowing in (and out) of the company. Our tasks were complicated further by the need to reincorporate the company from an S-corporation to an LLC during the final two months of the project (a legal maneuver designed to allow me, an Australian national, to be allocated company stock).
As well as destroying our personal lives, our failure to judge the magnitude of our task meant that we had to devote less time than we desired to every aspect of our work. My programming time was severely curtailed and I was able to spend far less time on System Shock's AI than I wished. Simultaneously, I was unable to provide the level of direct management that I wanted, and I was forced to postpone company financial work until the end of the project or hurry it through. The results were less than optimal all around.
Ultimately System Shock 2 turned out better than I ever hoped it would. the final vindication for me was sitting in my office and playing the game in the final couple of weeks of the project, while waiting for EA to approve our final build. Despite the lack of sleep, the near-complete breakdown of my nervous system and the 18 months of time I spent working on the project, it was still fun to play. I like to think that we have managed to capture the feel of the original game by putting more game play into what initially looks like a fairly straightforward first-person shooter. It's been a great first project for Irrational Games and we look forward to doing even better the next time around.
Jonathan Chey was the project manager and a programmer on System Shock 2. He is also one of the co-founders of Irrational Games. Prior to founding Irrational Games, he worked at Looking Glass Studios and prior to that he received his Ph.D. in Cognitive Science from Boston University. He is currently working on his tan back in his hometown of Sydney, Australia. He can be reached at firstname.lastname@example.org.
The Team at Irrational Games (left to right):
First row: Steve Kimura/Artist, Jonathan Chey/Project Director, Justin Waks/Multiplayer Programmer, Mauricio Tejerina/Artist, Rob "Xemu" Fermier/Lead Programmer, Dorian Hart/Designer, Lulu Lamer/QA Lead.
Second row: Ian Vogel/Level Designer, Scott Blinn/Level Designer, Michael Swiderek/Artist, Rob Caminos/Motion Editor, Nate Wells/Artist.
Third row: Mike Ryan/Level Designer, Ken Levine/Lead Designer, Mathias Boynton/Level Designer.
Not shown: Gareth Hinds/Lead Artist.