At the Office

Home

On the Couch

At the Office

In the Library

Mailbox

Neighborhood

Pitfalls of the Working Game Designer: More and More Features

Feature creep is a well-documented bane of game development: growing the feature set for a project over time, while not making corresponding cuts or adjusting the schedule. Adding more and more work, but expecting the schedule to stay the same, is a recipe for disaster.

There are generally two mechanisms that contribute to feature creep. The first, and most commonly understood, is endemic to trying to schedule development months and years in advance. On the front end, it’s difficult for anyone to project out every single thing the game is going to need to do and have by the time it’s done. Even if the designer can do this, it’s practically impossible to get everyone else on the team to understand all the elements and their relations; after all, if they were interested in doing that, they’d be designers, right?

As development progresses, and the game begins to take shape, it becomes clear that certain additions could enhance gameplay, that a few modifications, a few extras could provide real bang for the buck. Programmers, artists, testers, management, and design all contribute to the problem. After all, whatever little change they’re proposing couldn’t be that difficult, could it? Perhaps not, but when added together with every other little change, you would be adding months if not years to your production schedule, not to mention the extra testing time necessary to find all the bugs and do all the regressions.

[This is the point most external beta testers don’t get: no matter how valuable your suggestions, and no matter how simple they seem to you, every time you push for a change, you’re asking someone else to spend serious amounts of money. The threat of not buying the game (a $1-5 loss to the developer) pales in comparison to the investment needed to make the change (something like $3000 for each additional day of testing alone).]

This is where it helps to have an engineering lead who can lay down the iron fist. All changes need to come at a cost, because that’s the reality of making them happen. If features are going to be added, other features need to be cut or the schedule needs to be extended. No matter who’s making the proposal, the costs have to be paid. Of course, a smart lead also puts a little pad into the schedule to slip in those features that really are both compelling and simple to add.

Designers tend to come under fire more than most for contributing to feature creep, and rightfully so. The second mechanism that promotes "the creep" tends to happen more with designers (although it is by no means unheard of in other parts of the team): fixing by adding. A feature or game system that looks good on paper may not work once it’s put into the game engine. The first reflex is not to cut the system—after all, it’s one piece of an elaborate architecture of game systems—but to modify it. If the team has built its tools well, the designer can do this on their own, but all too often they have to get an engineer to do it for them. Rather than adding new features, this adds more work to existing features, which is just as damaging to the schedule.

Even worse, fixing the original system may entail adding additional systems. Let’s say, for example, that the AI is supposed to path through an area with dynamic objects in it. In most situations, they can push these objects out of their way; however, in some cases, the objects will get so packed into the space that they can’t move them. The initial response will be “Well, let’s get the AI to recognize this condition and react to it”. As logical as that may seem, you’ve suddenly introduced a major undertaking in contextual awareness; you’re talking about months of work, even if you have the talent on your team to tackle the problem. Your AI engineer will likely balk, and the next fallback is usually to propose a new rule for the AI: if you’re stuck, try jumping. However, you’re still introducing a new feature, which means more time, more testing, etc.

Fixing by adding is always going to contribute to feature creep. You’re much better off fixing by subtracting. For our example, take the dynamic objects out of the scene. Now the original system will work, and you have one less thing you have to test. Sure, making these adjustments may take additional time, but it’s time that should be accounted for already in the schedule, and at any rate it’s going to be cheaper than trying to build a new system on top of an old system, and if the new system breaks, the last thing you want to do is add yet another system. Mind you, there are places where additions are necessary, but unless they are absolutely essential, you’re better off cutting than adding.

Ultimately, you have to build from the core design out. Buildings are built from the foundations up, not the top down. If you front-load all of the core design in the schedule, then whatever’s left at stake can be cut without changing anything fundamental, and if you happen to be able to add a few touches here and there, so much the better. If the core design doesn’t work, you’re going to be going back to the drawing board anyway. A design is a lot like a recipe: combine some of this flavor with that texture, and in the end you produce something the consumer is going to enjoy. You can’t fix a broken recipe by adding more and more ingredients, and neither should you take that approach to a design.

Just remember that every construction project runs over time and over budget. Building a game world is a lot the same. The blueprints need to be flexible enough to accommodate the changes that need to be made, and the more that can be simplified out, the better. No one ever made a better building by adding wing after wing, or floor after floor. Be clear on the core design, and fix problems by restructuring rather than adding.

Next: The Devil's in the Documents
Back to Top
Previous: Believing the Hype

Home

On the Couch

At the Office

In the Library

Through the Mirror

Mailbox

Neighborhood