Fourth Entry:06/04/98
The art for the game is well under way, and the programming of the game engine is taking shape.

Last time I wrote, we were having an animation panic - trying to pare down our animation count, because it was the "critical path" on our schedule. I'm happy to report that that issue has been resolved. We now have eight animators on the team, and, in fact, they are almost done with the bulk of the regular gameplay animations. The only items left are the big story scenes and a few of the end-game puzzle animations. The backgrounds too (now called "environments") are nearly all completed. In other words, the art side of the project is well over the hump and actually ahead of schedule.

About a month or so ago, we had another, even larger bulge suddenly erupt in our orderly production schedule. Of course, I'm speaking of programming, the other large head on this multi-headed hydra we call product development.

GK3 is the first project I've worked on that we created a game engine from scratch. The closest I've come to doing this before was with GK1, when Sierra's traditional "SCI" engine moved to a new version, SCI 32. We made the commitment to move to the new system and fought bugs and snafus for six months. Despite this, we made our Christmas date - it just made what had been a very smooth project a bear.

Stable engines are wonderful for game development teams - it allows you to concentrate on gameplay and style issues and to get to market quickly. But gamers get bored if a company uses the same engine too often - particularly adventure game engines. Sierra's SCI and LucasArts' SCUMM come to mind. Also, new technology (like 3D) often doesn't work with old engines.

In other words, GK3 needed this new engine and so did Sierra. The G-Engine is a fabulous piece of engineering and allows the game to look remarkable. But the programming end of the project has been focusing on building first the underlying engine (designed by Jim Napier) and now the game interface on top of the engine, which allows the game room programmers (the ones who actually put the scenes and puzzles together) to be able to use high-level functions like "move character" or "play animation x" instead of having to hard code x-y coordinates and other nasty and bug-prone lengthy low-level details for even small actions. It was around February when we realized that we were not only not ready to start regular room coding (per our schedule), but that we were also not going to be ready for some months to come - the game interface level needed to be much larger and more supportive than previously scheduled for, or the room coding would be incredibly lengthy and tedious, and QA would be a nightmare. Through March, the programmers worked with off-team experts and our division head Mark Hood (who used to be an SCI systems programmer) to come up with a new plan that would still let us make our goal to ship this fall.

As a result, we have a very odd game development process going on right now. While the programming team works on strengthening the game interface part of the engine, the rest of the team is engaged in a pre-play test effort. Adam, our production assistant, and I are going through all of the game environments and writing the incidental messages (the main dialogue path was done months ago). When this pass is done in another week or so, all of the voice-over messages for the game will be written - a step not usually done until the game is play tested. We are also checking environments and animations. We have a tool called the Viewer, which allows us to bring in environments and animations and look at them one by one. By going over each and every written scene and puzzle sequence on paper then looking at each animation and each environment in the Viewer, we can find things now that need to be tweaked with the art, things that normally would not be seen until that section of the game was able to be play tested.

The artists, too, are getting all of their first-pass creation work done now, so in another month or so they can concentrate on doing "scripting" - creating text files that will run their animations. Then the animators will be writing the instructions that say which order and at what speed and sequence to play scene animations. This will give them greater control over their work and also make it very easy for the programmers to just plug it in. A lot of programmer time is usually spent just hunting down animations and props in various directories, finding missing pieces, talking to the artists, trying to figure out the sequence of play, etc. We are doing all of that work ahead of time for them.

You can see how creative one can get when one is motivated to ship a game! Although the process sounds unusual, it's not too much unlike GK2, when the AVIs (videos) were all done and plugged in very late in the process after the "game skeleton logic" for triggering the AVIs was done. The idea is that when the programmers are ready to code the game rooms in June, everything will be organized and debugged and tested already, so they can simply plug in the pieces. There will even be a way for Adam and me to go into text files and code the simple voiceover response-type messages ourselves (like LOOK on PEN) to take that off the programmer's plate and give us more control to add and delete things. You may wonder why we bother to try so hard to still make our ship goal of fall 1998 - why we all don't just go do other things until the game is playable and then do all the testing as normal, in the game itself. The cynics will no doubt say money. And for the guys upstairs, that's true. But for those of us in the trenches, there are more important motivations. I myself have now been working on GK3 since December 1996, as has much of the team. Imagine being pregnant that long - giving birth becomes an emotional necessity. And, too, we want to make sure that GK3 is just as impressive when it ships as it is right now. If a cutting-edge product sits too long, it's no longer cutting edge. Also, we're all motivated by the desire to see all of the game elements we're working on - animation, dialogue, environments - actually working together to see how the game feels. We'll do just about anything to make that happen, as soon and as smoothly as possible.

Every project has its own challenges, as you will remember from my first Designer Diary entry and my memories of GK2. Overall, GK3 has been less challenging in many ways, and we are confident that all the prework we're doing will significantly shorten the QA and polish time. In other words, you can still bank on this fall. I know I am, vacation plans and all.