Contents

Introduction What Went Right What Went Wrong Conclusion and Game Data

What Went Right

1. Focus on Core Gameplay

Development was basically broken into two phases. The first eight months were spent developing the graphics engine, application architecture, and assorted tools. We then took a step back and put together a rough project schedule that covered the remaining ten months. At that point we confirmed what we suspected all along: our design was too ambitious, and we were going to miss our deadline by several months. With our set-in-concrete-change-it-and-die ship date, we had no choice but to reduce the feature set and focus on core gameplay. This resulted in some difficult late-night sessions between our team and upper management, as we negotiated which features could be cut and still have a viable game. We ended up breaking features into three categories: required, optional, and later version, with the optional features prioritized by importance to gameplay. While the team was disappointed to let go of so many features, in the end we implemented most of the optional ones, and many others we hadn’t considered at the time. Our tight schedule simply didn’t allow for much feature creep, and our focus on core gameplay helped us ship on time.

Conceptual sketches for SWAT3 hostiles .

2. Using Worldcraft

Early on, one of our level designers convinced us to use Worldcraft, the level editor used to create Half-Life. At first we planned to use 3D Studio Max, but it wasn’t really designed as a level editor. Worldcraft was a much better choice: not only was it great for building and texturing levels, it also had a customizable entity system that allowed us to create our own objects (lights, doors, characters, etc.), each with their own unique set of properties. Our level designer was already familiar with it and could get started immediately. The file format was a bit weird (polygons are defined implicitly by a set of boundary planes), but it was text based and easy to figure out. Worldcraft’s batch commands made it easy to save the current level, copy it to a new directory, run the import tool, and launch the game, all by clicking a single button. Level designers could create multiple commands for different tasks: quick build with no lighting, full build with lighting, etc. This made it easy for them to preview levels without exiting the editor. Worldcraft had a few annoying bugs and limitations, but we developed workarounds. This saved us a ton of time, especially when you consider that many teams write their own level editor.

3. Character Animation System

In Gabriel Knight3 (another 3D game by Sierra), we used a vertex-based character animation system. This allowed for all kinds of effects, but had a serious drawback: changing a character mesh meant that all of the associated animations had to be re-exported. For SWAT3, we developed a skeletal animation system. All animations are applied to the skeleton, and the mesh (skin) is deformed to fit the skeleton at runtime. This allowed the character artist to work independently from the character animator, and we saved a lot of time and frustration as a result.

We used 3D Studio Max and Character Studio to create our character meshes and skeletal animations. We wrote two custom exporters: one for exporting meshes, and another for exporting animations. The animation exporter allowed the character animator and sound designer to trigger events in the game when certain frames are reached. This made it easy to add frame-based sound effects and other effects, such as footprints.

The animations themselves were motion captured, which had mixed results. All of the animations required a lot of hand tweaking, and it’s not clear how much time we saved over simply creating the animations from scratch. Simply giving the character animator a movie of the desired motion might have been just as effective, and would have cost a lot less.

Character animation was achieved through motion capture and a skeletal animation system developed for SWAT3.

Another important feature of the animation system was its ability to smoothly blend between animations. This eliminated most of the transition animations that would have otherwise been required. When a character is injured, for example, the animation system will smoothly blend from whatever their pose is to the first frame of the injury animation, play the animation, and then smoothly blend back to their previous state. We set up a simple transition table indicating how much time should be spent blending from one animation to another, and the results, while not always perfect, were much better than most games.

Note: I haven’t evaluated it, but RAD Game Tools has recently released a character animation library called Granny that looks very similar to what we developed. It’s definitely worth checking out.

4. Dedicated People

Many of the people on the team were experienced professionals who were dedicated to shipping the game. Our producer and designer were extremely enthusiastic and passionate about the game and its potential for success. Our designer had a strong vision but was also flexible about making design changes to fit the limitations of time and technology. Our producer supported our milestones and programming schedules, and backed up our decision to postpone multiplayer.

The art and programming staff got along great, which helped the development process go pretty smoothly. This isn’t to say that everyone always got along, but the two groups as a whole worked really well together. This was especially important given the engine was being developed concurrent with level design. When an engine change required modifications to existing levels, the artists were supportive and would help test the new features. When an artist requested a change, one of the programmers would do their best to accommodate them.

The art director was especially helpful. He worked closely with the programming staff to define art formats, procedures, and naming conventions.He did an excellent job designing the user interface, and built a working prototype to demonstrate how the menu system should work. When the art started falling behind schedule, he took on the additional responsibility of building several levels, working a tremendous amount of overtime in the process.

Despite not really coming together until the last month of development, the AI in SWAT3 has been rated as one of the best in the industry.

Our AI programmer took on the daunting task of modeling the behavior of SWAT officers and other characters, coming up with a true 3D pathing algorithm in the process. He was self directed and worked with very little supervision. While the AI didn’t really come together until the last month of development, many reviewers rated it as one of the best in the industry.

Near the end of the project, our QA lead jumped in and helped us place character start points and AI path nodes. He came up to speed quickly and became an integral part of the development team. This was pretty typical of most people on the team – they were dedicated to the project and put in the huge amount of time and effort required to ship the game.

5. Frequent Milestones

At the start of an eighteen month project, it seems like you have all of the time in the world. But the days go by quickly -- all of a sudden the two weeks you estimated for that easy feature are gone, and you wonder if two additional weeks will be enough to finish it.  Then two weeks later... you get the idea.  Milestones are a great way to keep things on track, and we used them frequently.

The programming team scheduled milestones at roughly eight to twelve week intervals.  Here’s how it usually worked.  First, we’d update the engineering document describing the current programming tasks.  Then I’d meet with each of the programmers and we’d come up with a list of tasks that could be completed for the milestone.  We’d consult with the art director and sound designer about the needed resources, and finally we’d present the milestone to the producer and designer for approval.  Once the milestone was approved, we’d all get to work. A week or so before the milestone was due, we’d wrap up any last-minute integration tasks and put together a demo.

This process worked extremely well. We met most of our milestones, and on several occasions delivered much more than expected. The milestones were close enough to be tangible, but not so close that the overhead of putting together the demo was a burden.  It was fun to bring in management and show them our progress, and seeing everyone’s work integrated in the game helped keep the team excited. The demos were often packaged and put on a CD, so people outside the team could see the game. We lost very little time preparing a demo for E3 – it was simply an embellished version of our latest milestone.

________________________________________________________

What Went Wrong