What Went Right
1. The Irrational Development Model.
In our hubris after leaving Looking Glass, we formulated several informal approaches to development that we intended to test out on our projects. Most of these approaches proved to be successful and, I think, formed the basis of our ability to complete the project to our satisfaction.
First, we designed to our technology rather than building technology to fit our design. Under this model, we first analyzed our technological capabilities and then decided on a design that would work with it. This process is almost mandatory when reusing an engine. Sometimes it can be difficult to stick with this when a great design idea doesn't fit the technology, but we applied the principal pretty ruthlessly. And many of the times we did deviate we had problems.
Another feature of our development philosophy is that everyone participates in game design. Why? Because all three of the Irrational founders wanted to set the design direction of our products, programmers were able to resolve design issues without having to stick to a design spec, and we strongly emphasized game design skills when hiring all of our employees and contractors. In all our interviews, one of our most pressing questions to ourselves was "Does this person get games?" Failure to "get" them was a definite strike against any prospective employee. Ultimately, the team's passion for and understanding of games was a major contributor to the design of the final product.
The final goal of our development process was to make decisions and hit deadlines. We focused on moving forward, and we didn't allow ourselves to be bogged down. We desperately wanted to ship a game and believed that the discipline imposed by the rule of forward motion would ultimately pay off in terms of the final product quality as well as delivery date. While there are features in System Shock 2 that could have been better if we had not rushed them (the character portraits for example), we still firmly believe that the game as a whole was made better by our resolve to finish it on time.
2. Use of simple, reusable game-play elements.
Concept Sketches of the Cyborg Midwife
The field of companies developing first-person shooters like id and Valve, among others, is impressive. From the outset we realized that we would have to work smarter, not harder, to make a game that could stand up in this market. It would be a futile attempt to create scarier monsters, bigger guns, or higher-polygon environments. Additionally, we realized that our design time and budget were very tight and that we would not have time to carefully hand-script complicated game-play sequences in the engine. Instead, in an attempt to shift the battlefield, we chose to focus on simple, reusable game-play elements. The success of Half-Life, which launched while we were in the middle of System Shock 2 confirmed our intuitions in this respect. We simply didn't have the time, resources or technology to develop the scripted cinematic sequences used by Half-Life. We consoled ourselves with the knowledge that we were not even trying to do so.
This strategy melded very well with our acquisition of the System Shock license, as the original System Shock had already been down this road. We decided to expand on elements that we liked in System Shock and then add similar new systems. Each such new system was evaluated rigorously in terms of game-play benefits, underlying technology, and design-time requirements.
For example, take the ship's security system. Early on we decided that we wanted to continue the surveillance theme from System Shock, which we could leverage throughout the game to provide lots of game play for very little implementation cost. We realized that security cameras would be trivial to implement using existing AI systems (they are just AIs pruned of many of their normal abilities) and that once we had cameras that could spot and track the player, we would be able to build several game-play elements out of them. Cameras could summon monsters to the player, so much of the game play consisted of avoiding detection by security cameras and destroying cameras before you were seen. Because cameras scan fixed arcs, the player can utilize timing to sneak by cameras, pop out and shoot them at the right moment, or get underneath them and bash them with a melee weapon. Once a player is spotted, monsters flood the area until the player is able to shut off the security system somehow or the system times out. This introduces the need to deactivate security systems via security computers that are scattered throughout the level.
This type of system was technologically simple to implement and required minimal design effort. While not completely formulaic, the basic procedure to set up a camera and security system could be shown to designers quickly using a few simple rules. From this one system and a couple of associated subsystems, we derived a large amount of game play without having designers create and implement complicated scripted sequences and story elements. When you throw together many such systems (as we did), you end up with a lot of game play.
3. Cooperative development.
System Shock 2 was truly a cooperative development between Irrational and Looking Glass. Looking Glass provided the engine and a lot of infrastructure support (such as quality assurance), while Irrational handled the design, project leadership, and the responsibility for marshaling resources into the final product. Both entities contributed personnel to the development team. Inevitably, some friction arose from this process while we sorted out who was responsible for what. However, this cooperation was ultimately successful because both sides were interested in developing a great product, and we were able to compromise on most issues. (On the most mundane level, Irrational ended up providing late-night, weekend meals for its development team and for Looking Glass on some days during the week.)
Our cooperative arrangement was founded on a contractual agreement, but we avoided falling back on this contract in most cases. We preferred to resolve issues through informal discussions. Conceptually, Irrational was to be responsible for the development of the product and Looking Glass was to provide A/V content and quality assurance services.
During the early stages of the project, a deal was worked out whereby a small number of Looking Glass personnel were subcontracted to Irrational when it was determined that Irrational's development budget could not cover all the System Shock 2 development costs, and as compensation for the late delivery of the Thief technology. Unfortunately, these personnel were not always available on time - a situation which caused us much concern. We knew that this "resource debt" could never really be paid off until Thief shipped - nothing is so difficult as prying resources away from a team that is trying to ship a product before Christmas. It wasn't until December 1998 that we first began to see some of these promised resources. However, these "resources" - real people - had just finished up Thief and were totally fried following the grueling crunch to ship Thief. The saving grace and reason that this arrangement was ultimately successful was that these developers were all talented and experienced and already knew the technology. Their addition to the team gave us a solid boost during the final months in our ship cycle.
The other benefit of the cooperative development agreement between Irrational and Looking Glass was that our respective engine programmers could share knowledge. The ability to walk over and quiz engine programmers about systems proved to be an invaluable benefit that more than compensated for the lack of a rigorously specified and documented engine. Without a formal understanding of the engine, we had to resolve engine issues in a personal and informal manner. This process relied on the personalities of the responsible individuals on the engine team. Thus, the Irrational programmers balanced their time not only according to the complexity of their tasks but also according to how much support was available from the engine side.
Overall, Irrational's relationship with Looking Glass was an unusually close one and ultimately successful as a result of our mutual respect and willingness to work with each other. Despite our partnership being based on a formal contractual arrangement, it was our ability to work flexibly above this legal level that enabled the development to proceed smoothly.
4. Design lessons from System Shock.
Though the System Shock license was wonderful, there were some problems. The biggest was simply the challenge of living up to the original. Fortunately, we had the freedom to pay homage to System Shock legitimately by reusing elements from it. Additionally, we had access to some of the original developers, including our own lead programmer Rob Fermier.
A psi-attack against a
Hybrid in Engineering
As with most sequels, we faced the challenge of keeping the good elements of the original game while not blindly copying them. We knew that most players would want a new story set in the same world, with the same basic flavor as the original game, yet we also wanted to reach out to a broader audience. We resolved these issues by identifying the key elements that made System Shock so good and reinterpreting those elements using current technology. Some elements made it through largely unchanged (for example, the storytelling logs and e-mails, the über villain Shodan and her close involvement with the player throughout the game, and the complexity of the world). Other elements were reinterpreted (such as the look of the environment, player interface, and techniques for interacting with the world). A small number of items were simply cut, most notably the cyberspace sequences - we were fairly united in our opinion that these just didn't work well in the original.
Notably, as with the original System Shock, we opted to omit interactive NPCs in the game. System Shock eschewed living NPCs because the technology of the day was simply inadequate to support believable and enjoyable interactions with them. It's been four years, and that technology is still not available. So we continued the tradition of System Shock and provided players with background information using personal logs and e-mails gleaned from the bodies of dead NPCs.
Perhaps our biggest deviation from the original revolved around the player interface. It's commonly accepted that System Shock's interface, while elegant and powerful once understood, presented a significant barrier to entry. Our primary goal was to simplify this interface without dumbing it down. We devoted more design effort to this task than to any other system in the game, and it required many iterations before we were happy with it. We adopted a bi-modal interface in which there are two distinct modes (inventory management and combat/exploration) between which the player can toggle. This was a risky decision. This bi-modal model was mandated by our desire to keep the familiar and powerful mouse-look metaphor common to first-person shooters while retaining cursor-based inventory management. How we switched between modes became our biggest design challenge. Sometimes these mode changes are explicitly requested through a mode change key, and sometimes they are invoked automatically by attempting to pick up an object in the world. So far this system seems to be working well, though only time and user feedback will tell whether we really got it right.
5. Working with a young team.
The System Shock team was frighteningly young and inexperienced, especially for such a high-profile title. Many of our team members were new to the industry or had only a few months' experience, including the majority of artists and all the level builders. Of the three principals, only Rob had previous experience in his role as lead programmer. Neither Ken, the lead designer, nor I, the project manager, had previously worked in these roles.
It's not totally clear how we pulled off our project with our limited experience. Partially, it must have been due to our ability to bond as a team and share knowledge in our communal work environment ("the pit"). To a certain extent, inexperience also bred enthusiasm and commitment that might not have been present with a more jaded set of developers. We also worked hard to transfer knowledge from the more experienced developers to the less seasoned individuals. Rob worked on an extremely comprehensive set of documentation for the functional object tools, as well as a set of exercises ("object school") to be worked on each week. These kinds of efforts paid back their investment many times over.
This is not to say that our progress was all sweetness and light. The art team, for example, floundered for a long time as we tried to integrate the junior artists and imbue a common art look in the team's psyche. We had a lot of very mediocre art midway through our project and the art team was stagnating. Ultimately, management had little to do with the art team's success - they were largely able to organize themselves and create a solid, original look.
On the management front, our inexperience was apparent. We blundered through the early stages of development with scheduling and management issues. A large problem was our failure to assign specific areas of responsibility and authority early on. Bad feelings arose as a result, which could have been avoided if we had clearly delineated areas of responsibility from the start.