Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Sierra's SWAT3 Close Quarters Battle
View All     RSS
January 19, 2019
arrowPress Releases
January 19, 2019
Games Press
View All     RSS

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


Postmortem: Sierra's SWAT3 Close Quarters Battle

March 6, 2000 Article Start Previous Page 3 of 4 Next

What Went Wrong

1. Over-Ambitious Design

The original design was extremely ambitious. Most of the individual features seemed doable, but added up they represented a tremendous amount of work. All of us had extremely high expectations for the game, but the total feature set turned out to be unrealistic given our small development staff and fixed schedule. Looking at it another way, the expectation was to create a graphics engine similar to Unreal, with a better character animation system than Half-Life, with better AI than both games put together, and multiplayer, and compelling SWAT officer gameplay. Right. No problem. Some of us suspected the design was over ambitious. In design meetings, we would say something like, “um, this is getting a bit complicated here,” but without a concrete schedule, our concerns were difficult to justify.

The levels for SWAT3 were designed using Worldcraft

As mentioned previously, eight months into development we had most of our core technologies implemented and were able to develop a schedule for the remaining ten months. As suspected, we simply didn’t have enough time to finish the game before Christmas, and had to cut back in several areas. This was painful for everyone because we felt the game wouldn’t be nearly as fun without the missing features. As every game developer knows, for every item on a task list there are usually several items that are every bit as important but are not recognized until during development. These “hidden” items are the hardest part of the schedule to justify, and in our attempt to come up with a schedule that would result in the fewest cut features, much of our padding was sacrificed.

The tight schedule, combined with our ambitious design, high personal expectations, and staffing problems, resulted in some of us putting in significant amounts of overtime during the last ten months of development. This left very little time for integration and play testing, and only through the team’s dedication did the product turn out as well as it did.

2. Staffing Problems

We had a difficult time finding the right people for both programming and art positions. Several people were transferred to our project after theirs had been cancelled or had shipped way past its deadline. Needless to say, this is a bad way to fill out a team. Some of them adapted well, but others were totally fried from the tremendous amount of overtime they had just put in, and had a difficult time getting motivated for a new project.

We had an especially hard time finding good programmers. We interviewed a lot of people, but our only external hire was the AI programmer, who turned out to be exceptional. The programmer responsible for the character animation export tools had just come from two cancelled projects and only lasted a few months. Another programmer was difficult to work with, refused to work overtime, and quit a couple of months before our ship date.

The art department also had difficulty finding the right people. Our lead level designer left during the middle of the project. That was quite a blow at the time, but his replacement was awesome and ended up creating some of the best levels in the game. One artist, who had just come from a project that was over a year late, refused to work overtime and had trouble getting along with the art director.

So, what could we have done better? We should have only hired and kept motivated people. Even those with less experience will contribute more in the long run than those who don’t want to be there. We should have been much more aggressive about hiring the right people early in the development cycle. This would have helped us finish the project sooner and given us more time for integration and play testing.

3. Concurrent Engine/Art Development

Due to our tight schedule, we couldn’t wait for the game engine to be completed before starting on the art. This was difficult for the artists, who were developing content for an engine that didn’t exist yet. They used Worldcraft and Quake to prototype some of our early levels, but since our engine used a different rendering algorithm (cells & portals), they could only do rough work.

Due to time constraints the engine and art for SWAT3 were developed concurrently.

Even after the engine was up and running, it was constantly evolving. Our design called for levels with an incredible amount of detail, and the engine was constantly being optimized to increase the frame rate. These optimizations would sometimes require the level designers to change the way they worked, and existing levels had to be modified. Engine changes would often cause rendering artifacts, and it was difficult for them to tell whether the problem was with their art or the most recent engine change.

The AI was also constantly evolving and frequently required existing levels to be changed. Things like valid door angles, minimum hall widths, and 3D path node placement were not finalized until late in the project.

From the start, we realized that concurrent engine & art development was going to be difficult, and it was. Fortunately our programmers and artists got along well, so this wasn’t as much of a problem as it could have been.

4. Failure to Track Design Changes

Our design document was basically a framework for the game, not a detailed specification of how each feature worked or how they would be implemented. That was fine, except that as we filled in the details, we failed to put the resulting documents into a centralized location. We had many impromptu meetings with the designer where we’d discuss how a feature would work and how it would be integrated into the game. Most of the time, the decisions made in these meetings were sent to the team via email. This worked okay initially, but as the project grew more complex and the number of design decisions increased, these “mini design documents” became increasingly difficult to keep track of. The current design was spread out among many separate documents and emails, and it was difficult to tell if the one you were using was the latest.

Design changes were frequently made due to programming or art limitations, and the reasons for each change were rarely documented. This was especially true at the beginning of the project. If the programming or art limitation was later overcome, then we were often hard-pressed to remember which features might be affected.

In the future, we should keep all design documents in a central location and keep them up to date. Features cut or modified due to art or programming limitations should be recorded as well. Emails are fine for discussing things, but once a decision has been reached, it should be recorded in the corresponding design document.

5. Limited Integration Time

In an effort to pack in as many features as possible, we simply didn’t give ourselves enough time for integration and play testing. For example, most of our character dialogue didn’t roll in until a couple of weeks before we were scheduled to begin QA. Integrating the dialogue took longer than expected, and only at the last minute did we discover that some of it could never even be heard.

The AI didn’t really come together until the last month of development. There were some minor problems in the character animation system that caused the AI programmer quite a bit of grief, and the pathing system went through several last minute changes. Having more time to integrate those modules would have made things much easier.

Our user’s manual was another casualty of our tight schedule. We were so focused on finishing the game, we simply didn’t give it the priority it deserved. When someone says the manual isn’t important, don’t believe them. People really do read the manual, and it should be play tested just like the game. We won’t make that mistake again.

Article Start Previous Page 3 of 4 Next

Related Jobs

Cignition — Palo Alto, California, United States

Game Programmer
Heart Machine
Heart Machine — Culver City, California, United States

Gameplay Engineer
Wargaming Sydney
Wargaming Sydney — Broadway, New South Wales, Australia

Gameplay Programmer, C++ - Vehicle Physics
Skydance Interactive
Skydance Interactive — Marina Del Rey , California, United States

Gameplay Engineer

Loading Comments

loader image