15
\$\begingroup\$

How can I prepare for feature creep during preproduction?

Feature creep is when you are in the production phase and decide "It would be cool if this were a feature!" That adds n hours to the development time which were not accounted for, and unless you are Blizzard, do not have the time for. You cannot anticipate it being a cool feature during preproduction, because the feature is only discovered during production.

What can I do during preproduction to account for or prevent or prepare for feature creep?

Should I allow feature creep and cut less desired features? Or will this create a problems since the architecture is not designed for the new features? Should I say no features unless they fit into the existing architecture?

I know this is a broad question, but I hope it doesn't get closed as such. This is a major issue in game development, and should be considered.

\$\endgroup\$
10
\$\begingroup\$

While of course there are no hard rules when it comes to pre-production, there are a variety of heuristics to help. Some feature creep is natural and necessary - no plan survives first contact with reality, and you may not know what would be "cool" until you see it.

First, stage your development. Draw up your outline into a feature map, and then look for ways to group your features into testable iterations, each with a deadline. Once you begin an iteration, resist adding new features to it. Any unforeseen technical needs should of course go into the current iteration, but new ideas for features should go into a list for future consideration. You can then consider whether or not to add it to an iteration once the current one is complete.

This follows from the MoSCoW method, whereby you categorize features like so:

  • Must haves - features that are vital for the current iteration to be stable, which is to say testable. If the iteration won't work without it, it's a must have.
  • Should haves - features which will have to get done at some point, but if the iteration goes over time can be pushed into the very next iteration. Things required by a publisher, for example, could go here.
  • Could have - features which you think may be important to the current iteration but could be dropped from the project. These are the all important polish features.
  • Won't have - items that potentially feed the backlog, features identified in this iteration to be considered for later iterations.

Ideally you want development to be a progressive refinement, not all-or-nothing. Working within a final deadline the least important features ought to be pushed to the end, so whatever you don't get to will be stuff that's okay to cut. Make sure to estimate how long each feature will take to develop and refine those estimates as you go. Never compress the schedule to make room for more features. Resist pushing deadlines (iteration or final) into the future - move or cut features instead, if possible. If you're coming up to your deadline and the game is still an unsaleable mess, then you know it's time to seriously reevaluate your decisions and consider cannibalizing the project before it turns into a time/money pit.

\$\endgroup\$
3
\$\begingroup\$
  • Plan to use a fraction of your available pre-production time for base feature set.
  • Base featureset should be low-risk, high-reward features, so you don't have creep on those
  • Base featureset is minimal and non-negotiable - they must be present - otherwise no solid basis to work from and you will be riddled with self-doubt / "should I replace this" syndrome
  • Make sure the earliest iterations of your game are attractive enough that you can afford feature creep. A fundamentally unimpressive game isn't going to make it far, let alone with creep.
  • Know beforehand what margin of creep you can afford, so you can use that margin wisely.
  • Use pre-built, highly-generalised technology like Unity, and use it canonically to improve flexibility so that feature creep doesn't impact too heavily on existing architecture
  • Don't build complex subsystems - an eXtreme Programming approach is suitable here
  • Have others(designers & coders) whose brains you can tap periodically to help you prioritise which features you will allow to creep, have someone experienced reviewing your code as primary go-to point for these questions.
  • You will still have to limit feature creep, so constantly prioritise and know where to draw the line

Ultimately, it's not something I would suggest to beginners, because you need to be able to make the right decision at every stage and that is not easy even for the most experienced. If you're not sure about what the right decisions are, then have a strict "no creep beyond this point" policy.

You can also see how the first point and the one about using a technology you know well means you need substantial experience both in rapid prototyping (game jams) and your chosen toolset.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.