The Feature Creep Cycle
Posted by Rampant Coyote on July 18, 2011
So here’s the feature creep cycle, illustrated by user (including developer) requests:
1) Request – “Man, you really need this one little feature. It would totally take things over the top.”
Implementation time: 4 hours.
2) Request – “The new feature you added is awesome. But it’s got these bugs in it. And it looks kinda tacked-on. It needs some improvement.”
Implementation time: 3 days.
3) Request – “Wow, the new feature is so awesome, it makes the rest of the features that work with it look shabby and poorly designed by comparison. You need to improve those as well to bring them up to the new standard, and make sure they are all fully integrated with the new feature.”
Implementation time: 3 weeks.
4) Go back to step 1.
The truth of the matter is that none of the requests are wrong. This is the iterative cycle that really, really improves a game and polishes it. Except that it can never get polished to its full potential awesomeness. There’s always one more feature, one more improvement.And they always sound like THE feature that will make the product and take it “over the top.”
With games, I’ve long said that sometimes “feature creep” is the best thing that can happen. I’m not a big design document fan. I think they serve a great purpose, especially for something as complex as a role-playing game, but in the past I feel the industry went overboard. I feel a design document serves as the original “paper prototype” to force vague ideas into tangible form; as a “to do list” for a game through early to mid development, and as something of a schematic to show how the pieces of a more complicated game all work together. But many of the strengths and weaknesses of a design remain hidden until the game is off the paper and on the screen. It is only after it’s playable that some of the best ideas may be apparent.
So to that extent, those creeping features / scope are actually a very good thing. Taking a hardline approach against feature creep is foolish.
The problem is that these things can very easily destroy a project as well. The above illustration, where a quick-and-dirty feature that added so much to the game was a quick half-day project that ballooned to taking almost an entire man-month is an example. A couple of those may be exactly what the game needed to turn it from a good game into a great game, or double sales. Too many, and the project descends into hell, gets impossibly muddled, blows its budget and may never ship.
Sometimes the killer features are best reserved for a sequel, expansion, or update.
Being able to know how and where to draw the line is a critical skill. I’m note sure I’m all that good at it. Maybe I should participate in more Game Jams to get better at it.
Filed Under: Game Development - Comments: 7 Comments to Read
Maklak said,
Another problem is that this process is often interrupted before step 3 is completed. This speeds things up, but turns project into confusing maze of minigames or other features badly glued together.
It is also possible to have too many features. Some tool programs are popular because of interface simplicity and (relatively) low memory and CPU consumption.
Moonmonster said,
My general rule is to say No, unless the proposed feature solves an outstanding problem.
‘It would be useful if customers could also access this via the API’ is not going to happen.
‘It would be useful if customers could also access this via the API, and it also solves the issue of desktop integration’ might be worth a shot.
Sometimes the proposed feature really is just insanely useful and should be done, but in general, my rule serves me well.
Rampant Coyote said,
I think that’s a good default position to take, once you are satisfied with the design. There are a lot of things that would be “nice to have,” versus those that – to get totally mercenary – will sell x% more copies or make it blow away the competition. It’s difficult drawing the line. It’s especially difficult with game software, because developers put their hearts into it the way you rarely see programmers do with business software.
It’s also tricky with committed testers / customers who really, really want a particular feature. You hate to ignore their suggestions, but each one has to stand on its own merits and make a compelling case for itself.
Craig Stern said,
It’s funny; I’m pretty good about saying no to new features proposed by fans, but relatively weak about saying it to myself.
In TSoG, the main city, Ravinale, has a pretty prominent seedy underbelly. One of your characters comes from that background, and is a recovered drug addict. I was thinking yesterday: “Wouldn’t it be cool if you could buy drugs, then become addicted to them in-game a la Fallout?” It would be a neat way of exploring a topic that already gets some treatment in the game. But to implement that effectively, I’d need to come up with a system for monitoring the passage of time in-game, notifying the player as the drugs wear off and he begins to feel the effects of withdrawal. I’d also need to monitor various stat bonuses and penalties from being high and in withdrawal, respectively. I see this taking me a solid week to implement, and easily twice that to implement well (where other characters comment on your condition).
In summation: I think I need someone to track me during the day and just, you know, administer a light shock whenever I start writing down an idea for a new feature.
McTeddy said,
I’m actually a strong supporter of the Design Documents… and I rarely make anything without at least a small one. I’ve always found that a solid plan will speed up development exponentially and reduces the mistakes made in my code.
That said… I’m not against revising the design if it is needed. As you said… many issues will be found out once the game is actually playable. If something isn’t working… it needs to change.
So, I change the design doc rather than immediately implement the feature. This gives me time to review whether the fix is a “NEED” or a “Would be cool”. This gives me time to think about how to implement it without breaking things. This also lets me fit it into my prioritized list of features so that I know where this fix will end up in the schedule.
This forced break can often save me the wasted time of adding a feature that wouldn’t have added much to the project yet requires alot of work.
Zomblobs! Cytoglobe « Tish Tosh Tesh said,
[…] to add the following great link to The Rampant Coyote’s recent article on “Feature Creep”… a highly relevant article as I sort out exactly what I want to do […]
Smitfun! said,
This happens with design clients all too often as well.
“Could you move this over a little” or “Could you make this font bigger, we want this to scream….. could you also make this font larger, this needs to scream as well”
Is it just me or does having a half page ad screaming six things seem a bit loud?