Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Sierra Studios' Gabriel Knight 3
arrowPress Releases
January 19, 2021
Games Press
View All     RSS

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


Postmortem: Sierra Studios' Gabriel Knight 3

October 11, 2000 Article Start Previous Page 2 of 3 Next

1. Redesigning the engine. A month after I joined the team, we decided to rebuild the game engine and a little while later I took over as its architect. We spent a couple of weeks in roundtable design sessions with engineering advisors from other projects (including Jim Napier from SWAT 3) and used a low-tech Class-Responsibility-Collaborator (CRC) card design technique to hash out the systems we would need and how they would fit together. I thought all of this went pretty well, though it was slower than most of us liked. Once we started coding, though, things really got moving. The application core was rewritten in a weekend, and then individual systems (user interface, scene abstraction and configuration, font rendering, the console system, and so on) were developed and integrated as fast as we could manage.

In proposing the re-architecture, we gained the full support of upper management, specifically Mark Hood, the general manager of Sierra. They really had no choice, considering that the only other option was to cancel the project, but I think it's important to recognize the risk that they took with us and give them credit for believing in our ability to rebuild the engine. Throughout development, Mark was always 100 percent behind us, and never wavered in his desire for us to ship a triple-A title of the highest quality. Despite our lack of experience, we largely delivered what we set out to accomplish.

Unfortunately, I don't think a lot of the team members outside of engineering ever really understood why we rebuilt the engine. Looking back, I wish we had spent a little more time explaining to them the dire situation it was in. Although it took months to redesign and rebuild the game engine (a time that understandably confused and frustrated everybody), it ultimately improved our team's productivity immensely and made it possible to ship the game. The new engine was stable, flexible, and although it still had architectural problems (due to our inexperience), it worked properly and performed well.

Hand-drawn concept art.

2. Data-driven engine. GK3 is a content-heavy game that ships on three CD-ROMs and includes more than 800MB of compressed non-movie data (consisting largely of texture maps, MP3 dialogue and music, and animations). There are thousands of lines of dialogue and almost as many logic rules tying it all together. During the re-architecture, we went with a data-driven approach, putting as much as we possibly could into text files so that non-engineers could create and maintain content. We were very happy with the results.

One of the project's major successes in this area was its flexible scripting system, "Sheep," which used a C-like language and was implemented using a simple compiler and p-code interpreter. The compiler was built with our old friends Lex and Yacc from the Unix world. Originally designed just for the game's animated sequences, the Sheep engine ended up being used for custom rules processing, event handling, resource packaging, scene configuration, debugging, the development console, and even for a little bit of testing automation.

Construct a familiar symbol to open the stairs into the floor in one of the game's cooler sequences.

I can't stress this enough to developers: Build a scripting engine, even if you don't think you need one. Make it generic enough so that it can be reused in as many places as possible. I think many engineers are scared of building one because they think it will take too long to develop or that it will execute scripts too slowly. This was certainly the case with the original GK3 engineering team. I've found these fears to be completely unfounded -- a scripting engine will pay for itself many times over, and can be easily optimized to approach the speed of C++ code. Also, don't invent a new language. Pick a programming language that one of those "Teach Yourself Something Useful in 21 Days" books exists for, and you can buy copies for your scripters if they don't already know the language (although this wasn't necessary for the GK3 scripters). This will save you the time you would have spent documenting syntax and training scripters had you used a completely proprietary language.

Another benefit of Sheep was that when combined with our redesigned file and resource manager, we were able to cut down dramatically the time necessary to integrate art into the game. The old engine used C++ to reference art assets, which meant that artists needed to wait for the next build (at best) before they saw their work in the game. We reduced those days or weeks of waiting down to minutes or hours and almost completely removed the engineers from the picture. Under the new system, artists could check in their work and have one of the scripters integrate and demonstrate it immediately on the existing build.

We added clipboard support too, so that developers could use GK3's console to paste Sheep code directly into the game. The scripters could Alt-Tab away from the game, grab a section of test code from their text editors, Alt-Tab back into the game, and paste it into the console to see immediate results. With these kinds of features in place, content poured into the game at a blinding pace.

Poke around in here and you may annoy an arch villain.

3. The design. The game's design was a major success and deserves special mention. GK3 would have simply fallen over and died had we had a less experienced designer than Jane Jensen. Throughout the entire development process, the one thing that we could count on was the game design. It was well thought out and researched, and had an entertaining and engrossing story. Best of all, Jane got it right well in advance -- aside from some of the puzzles, nothing really needed to be reworked during development. She delivered the design on time and maintained it meticulously as the project went on.

Dynamic texture composition used to generate facial expression and eye movements: eyebrows + eyelids + eyeballs + mouth = expressive lip-synched face.

4. The audio. Audio designers and engineers rarely get the credit they deserve and often end up taking second place to the people drawing the pretty triangles. But GK3 is an adventure game, and as such it lives and breathes on the ability of its dialogue and supporting audio to immerse the player in the story. Many reviewers picked up on the great audio they found in GK3, often rating it as one of the best parts of the game (that is, those reviewers who didn't have a silly personal issue with Tim Curry cast as Gabriel Knight). From a development point of view, audio content was something we could always rely on. David Henry, GK3's composer and lead sound designer, had it all done long before we actually needed it, and was therefore able to spend time polishing the audio and adding lots of small details to it. And in stark contrast to the other parts of the game, integration and maintenance of the audio content went as smooth as glass.

5. A talented, dedicated core of developers. GK3 never would have shipped without the heroic efforts of critical developers in key places across the board -- art, scripting and logic, engineering, design, and testing. These people took over various parts of the project on their own initiative and kept pushing until things were done and done right. The loss of any one of these individuals would have severely crippled the game's chance of making it out in 1999, if at all. Among the crowd, two names deserve special mention. Halfway through the project, we picked up Jessica Tams as our content lead, who took over the content and put it in order. She wrote nearly all the scripts and logic for the entire game, completed them on schedule, and somehow made them all work despite the problems with the engine (more on these problems in a moment). Lead animator Ray Bornstein came onto the project with a year left to go, put the animations in order, created a realistic schedule, and made the animators stick to it.

Article Start Previous Page 2 of 3 Next

Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Experienced Game Developer
Disbelief — Cambridge, Massachusetts, United States

Junior Programmer, Cambridge, MA
Disbelief — Chicago, Illinois, United States

Junior Programmer, Chicago
Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist

Loading Comments

loader image