Feature Creep: Tales from the Trenches

Contents

Too Eager to Please Keeping People Happy Beware the Insider Tales from the Trenches

Many cases of feature creep have been documented in articles available on Gamasutra. Some of these include:

Postmortem: Ritual Entertainment's Sin
Ritual Entertainment found both the value and costs of changing requirements:

Because it was so easy to add commands to the scripting language, the programmer would usually oblige. We added two to three commands to the scripting language daily. In the end, we had over 400 script commands total. So, while we did experience some feature creep, and though these last minute details did push our release date back even farther, we were able to add a lot of detail near the end of Sin's development cycle.

The Psychology of Artists and Programmers
This article describes a classic case of "developer gold-plating":

Game programmers are very competitive with each other, and the score is often measured in features, not in depth of game experience. For example, I know high-profile coders that don't respect Myst because it isn't technically innovative. Lots of artists that I know think Myst is a successful game that has a powerful impact on its users. This extreme focus on the technical abilities of the game leads to ever-greater features, sometimes even at the expense of the overall game experience.

Postmortem: Raven Software's Heretic II
Raven Software experienced feature creep that improved their product but caused them to miss their date:

Once we were comfortable with all the additions we made, we decided to try a small public beta test of the Enhancement Pack. This was an extremely successful thing to do, it turned out, as much helpful commentary came back from those involved. In fact, we ran into feature creep quite a lot at the end of this burst of activity, which mainly came from the extremely helpful and interesting suggestions we got from the beta testers. We did suffer a bit of criticism from the existing H2 community over the Enhancement Pack, because we originally predicted that we'd be done just after Christmas. That was a bit optimistic as it turned out, but our mistake was in announcing an approximate release date for the Enhancement Pack. The Heretic II community was not pleased about this, and made no bones about announcing it.

Postmortem: Westwood Studios' Command and Conquer:
Tiberian Sun
Westwood Studios did some feature-trading, and ended up wishing they had cut even more to make room for features that were added:

Tiberian Sun started strong and we developed a robust and large feature set we intended to fulfill. The project started smoothly, but as we progressed, the temptation to add new features not included in the design document grew. These features arose out of shortfalls in the original design, omissions from the original design, and input from fans.

Everybody stresses the importance of working off of a design document and not deviating from it. Unfortunately, this just isn't realistic since every product evolves during the course of development and sometimes the original design proves to be lacking. A team has to be able to incorporate new ideas during development if the final project is to be better. However, the flip side of this idea is that the team must be able to cut features diplomatically when it is in the best interest of the project …

Looking back at the project, I think we could have been more aggressive in cutting or changing certain features to make sure their returns were really worth the development investment. I'm a firm believer in the idea that less is more and that fewer but more fully developed features are the way to go. If a feature isn't amazing, you should cut it or make damn sure it becomes amazing before you ship the product.

Postmortem: Surreal Software's Drakan: Order of the Flame
Another case of feature creep causing schedule slips:

Drakan was originally slated for release in February 1999, but ended up being released six months later. Even with careful scheduling and task planning, we failed to meet the final deadlines. Part of the problem was that we didn't account for the time the team would spend creating versions of the game for E3 and for magazine and Internet demos. Each demo pulled nearly two weeks of time away from our normally scheduled tasks. The majority of the scheduling problems were due to feature creep and other improvements that were considered necessary during development.

Postmortem: Sierra's SWAT3: Close Quarters Battle
A case when the schedule really couldn't move, so the feature set shrank:

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.

Discuss this article in Gamasutra's discussion forums

________________________________________________________