System Shock 2 Postmortem, Resurrected
-
Category: News ArchiveHits: 2534
To help celebrate the 15-year anniversary of the release of Irrational Games' System Shock 2, Gamasutra has resurrected a postmortem article that was originally written by the game's AI programmer/project manager Jonathan Chey well before he went on to contribute to Freedom Force, BioShock, and other unforgettable titles at the studio. Some great insight into how the FPS/RPG became such a classic:
The Thief technology was developed with an eye toward reuse, and I will refer to it in this article as an "engine." However, it is not an engine in the same sense as Quake's, Unreal's, and LithTech. The Dark Engine was never delivered to the System Shock team as a finished piece of code, nor were we ever presented with a final set of APIs that the engine was to implement. Instead, we worked with the same code base as the Thief team for most of the project (excluding a brief window of time when we made a copy of the source code while the Thief team prepared to ship the game). Remarkably, it is still possible to compile a hybrid executable out of this tree that can play both Thief and System Shock 2 based on a variable in a configuration file.
This intimate sharing of code both helped and hurt us. We had direct access to the ongoing bug-fixes and engine enhancements flowing from the Thief team. It exposed us to bugs that the Thief team introduced, but it also gave us the ability to fix bugs and add new features to the engine. Because we had this power, we were sometimes expected to fix engine problems ourselves rather than turning them over to Looking Glass programmers, which wasn't always to our benefit. At times we longed for a finished and frozen engine with an unalterable API that was rigidly defined and implemented - the perfect black box. But being able to tamper with the engine allowed us to change it to support System Shock-specific features in ways that a general engine never could.
...
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.
