Gabriel Knight 3 (GK3) is a traditional "Sierra-style" murder-mystery adventure game that tells its story through a complex, nonlinear mix of dialogue trees, scripted sequences, movies, and puzzles. Most of us should be familiar with this kind of game -- it's paced at the speed of the player, and involves a lot of "inspect the monkey" and "use the banana on the monkey" type of interaction to move the story forward. GK3 differs from its predecessors technologically in a variety of ways, but most important is the fact that it moves the genre to full 3D.

GK3 offers a freely roaming camera that lets players go where they please and zoom in on whatever they like. This isn't just a gimmick -- this single feature changes the game radically, making it more like an interactive movie and less like an interactive comic book. As we found out, moving from 2D to 3D is not just one-third more work, it's more like three times as much work. It affects nearly all aspects of the game, including both the design and the engine. It's not as simple as just drawing your actors and environments with polygons instead of sprites. Suddenly you have to start worrying about camera angles and dramatic effects that were never possible or necessary in 2D, at least not without resorting to a prerendered movie.

Another part of GK3's design was the ability to give the player the option to turn off cinematic camera cuts during dialogue sequences. The idea was that players could be the director and choose their own camera as the action was unfolding. This had a serious and very expensive effect on the art: it meant that artists could take no shortcuts with their animations. In a prerendered movie, an animator has full control over the camera and can avoid bothering with anything that's outside of its view. This saves a lot of time. In GK3, because players may at almost any time decide to take control of the camera, they would be able to see the action from any angle they pleased and go "behind the curtain" so to speak. Therefore, the animators needed to make sure that the entire scene could be both viewable and good-looking from any angle. This increased their workload by an order of magnitude.

Previous Sierra adventure games, including GK1 and GK2 as well as the Space Quest and Leisure Suit Larry series were built using the "SCI" game engine. SCI was developed and maintained by Sierra Oakhurst and, for a variety of reasons, Sierra Northwest (the division I worked for) decided to stop using it. This single decision probably affected the project more than anything else did -- it meant that GK3 was to be the first adventure game Sierra had built completely from scratch in a very long time.

From the start, the project had some important things going in its favor. Sierra hired an experienced engineer, Jim Napier, who got the game started by developing the G-Engine, a 3D rendering, sound, and animation toolkit that provided the low-level foundation for us to build the game upon. After the engine's completion, Jim unfortunately had to leave the project to start on the fledgling SWAT 3 as its lead. The G-Engine was on the whole a successful part of GK3; it provided a stable base for the game and was easy to use and understand. The team was also able to reuse some of the tools and concepts that SCI had provided, such as the content database and lip-synching tools.

Despite these initial advantages, the project faced problems almost from the start. The team had to build a new game engine and most of the related content development tools from scratch, but team members severely underestimated the time, cost, effort, and experience required to construct these tools and establish effective development processes around them. The initial development team was not up to this task.

Hint: Don't walk on that bridge on the left

In the early days of the project, the engineering team must have been living in a magical dream world -- I can't find any other way to explain it. When I joined the project in early 1998, GK3 had already been in development for more than a year and a half, and it was scheduled to ship at the end of that summer. I realized that this would never happen because at that point the game was a hacked-up version of a sample application that Jim Napier wrote some time earlier to demonstrate the G-Engine. Sample code being used in a production environment should send shivers up the spine of any experienced engineer. Malignant growths of code were added haphazardly whenever a new feature was required, making the game extremely unstable and difficult to maintain. This problem fed on itself and grew worse over time. One example of this problem was the game's horrendous startup time. The file and resource system, while sufficient for a sample application's minimal resources, completely fell over when faced with the tens of thousands of files and hundreds of directories in GK3. The game took over a minute just to start up and display the title screen.

There's a big ugly demon behind that veil.

Most of the game's non-art content, such as a story sequence involving simple dialogue exchanges between two characters, was initially hard-coded into the game in C++. This was a nightmare for a couple of reasons. First, engineers were creating content instead of working on the engine, and engineers are generally not the best people for creating good content (and they tend to be very slow at it as well). Second, the tiniest changes to the game, such as choosing a different line of dialogue or altering an animation sequence, required recompilation. This made the content development process unbelievably inefficient. Artists would potentially have to wait weeks to see their work integrated into the game. This resulted in engineers resenting artists "chucking art over the fence" and probably inspired similar resentment on the art side.

If GK3 was to ship at all, all of this had to change. And so it did.