How do you decide when your feature list is long enough?

Question

I know a bit about this question but I find that there are quite a lot of diverse opinions on the subject?

I know from a players perspective that more options is almost always good. But on the other hand if it has multi-player more means higher complexity (meta game) both for the developers as well as players.

On development complexity and time constraints always go hand in hand. Another would be resource and platform constraints. Possible economic ramifications of holding back for later is sometimes a reason as well.

So from people experience here aside from the above when should features be cut or be for later release?

Answer 1

I'd say it's a two-step process for us:

• Establish the game's goals.
• Determine which features help us reach these goals.

The feature list is long enough when those two points match up. So:

1. Establish our goals -- Figure out all the things that we want the game to do for the player/reviewer/whomever, then state them measurably. For example, with our latest (see alpha test vid here), we want to do these:

• Visuals: We want every review to mention that the visuals are unusual and sexy, especially for an indie title. This is important to us because gamers often use their eyes as a quick metric of quality (though, of course, it's just one of many!), and we want that to draw them in.
• Exploration: We also want to reward folks for exploring the game. To put that measurably, we want something around a fifth of the player's game time is spent doing neat little things outside the core gameplay. This is important to us because (IMO), much of the delight of a game comes outside of expected, core areas (we think about how clicking on pieces in Starcraft amuses us).
• Community: We want everyone to tell at least one friend about the game.

2. Determine features that help us reach those goals -- These almost fall naturally out of the above. So, the features that correspond to the above examples might look like this:

• Visuals: As a small studio, if we want sexy visuals, we can't go up against EA or Sony on realism. So to approach the goal of remarkable visuals, one of the game's features is a surreal aesthetic. (From this, we're able to determine which tools we need, and so forth.)
• Exploration: Tidbits corollary to the game's action fall out of this. In our most recent title, we dropped a quick reference to Ryo's questionable search for sailors in Shenmue. It was a silly throwaway, but people liked and talked about it!
• Community: We're asking ourselves all the ways to make a game worth mentioning to a friend. Making it fun is #1, of course. But we could also reward the players with a special item or level if they tweet about it. Pokemon made it worth while to have friends pick up the game -- there are some critters you could only get by interfacing with other people.

When we go through this process, it helps us determine:

• How much we need to implement for a minimum viable product (MVP).
• What's most important, what can wait, and what we can drop altogether.
• When we finally have all the features we need.

It's worth noting that we don't slavishly stick to these rules! More often than not, some awesomely interesting things come about as a result of mid-project prototyping and just general futzing around. Especially for small games such as ours.

Answer 2

Complexity doesn't make your game fun.

The right combination and balance of gameplay elements does. The player must be pushed to the extent of their skill-level and get a feeling of mastery from conquering challenges.

Your feature list should change whenever you feel the current gameplay isn't fun. These changes must be made within your budget / time constrains. Make sure any changes you make aadd value to your game.

Also, prototype early, don't just write up a huge feature list and assume it will all be fun when put together.

Answer 3

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

-- Antoine de Saint-Exupery

Answer 4

When the time and effort needed to include them is greater than the value they add to the game.

For example, if you were creating a sporting game or something where players are likely to want to showcase their skills, multiplayer is a must. Guitar Hero wouldn't be the same without it. However, a solely individual game, where you reach beginning to end on your own, following a story or plot doesn't need multiplayer. The shoddy multiplayer system in Grand Theft Auto San Andreas is testament to that (even though that company probably didn't find multiplayer too hard).

Also, features that don't really fit with the story of the game, just are there because they can be. If it's not completely essential to gameplay, it's probably a good sign that they can be pushed to a later release if time is an issue.

The thing is, extra features aren't the quintessential element of a game. An exciting storyline combined with enjoyable gameplay is.

Answer 5

While there is a degree to which variety in features is great (being able to do tons of random stuff in a GTA-ish game, having tons of variety in weapons and accessories in an RPG or Call of Duty-ish game, etc), I think more minimal gameplay focused tightly on a few core features can be highly effective.

Look at Portal, it took its one core mechanic and really effectively built its puzzles around that without needing a lot of extra clutter.

I think being strict about keeping the feature list as minimal as possible and really fleshing out a few core features allows for a more feasible project and often a more enjoyable experience (if Portal added RPG elements and driving sequences and slowmo and whatever other "cool features", would it have been as good? Would the core mechanics have been as polished?).

Now, as an indie dev I'm surely biased, but I think that usually "less is more" in features, and even though something might be cool or popular at the moment, if it doesn't make the overall experience noticeably better it should be cut.

Answer 6

I have found from my personal experience that it is best to avoid adding new unplanned features as soon as possible.

From a design point of view a feature which has been added during a spur of the moment "wouldn't it be nice to have feature x" period will add a lot of development time, might not integrate well with the code, and might not fit completely with the rest of your design.

In the worst case a project which has had a lot of these moments can feel like a messy, hacked together combination of features, which really should have had a lot more time spent on them in the design phase and look less professional as a result.

As a general guideline I try to follow these rules:

• If a new feature comes up early in the project, take the time to go back to the design phase and really see how this feature can work in with your product while still remaining consistent with the rest of the design.

• If the project is drawing closer to release, consider making a list of features to add to a new version.

• If you find that a lot of features keep coming up which you really want to implement, maybe you should consider going back to the design and look at why these new features haven't been considered earlier, possibly due to a lack of effort spent in the design phase.

Obviously this fits some projects better than others, but really if you have a feature come up late in the project, you will probably will fine without it, at least until you start working on a new version.

Answer 7

Keep lists short, be agile

Do not build feature lists at all, or if you do, build them very short, only worth a few weeks of development.

Develop in agile style - start with the few most important features at all, test, based on what works and what does not, and then think about if it is worth adding some more features (you will be able to judge them a lot better if you already have some experience with the basic gameplay).

How to judge individual feature

Other than than, I would agree with bennybdbc criterion, "When the time and effort needed to include them is greater than the value they add to the game.".

That said, you also need to consider "external" world:

• are you running out of money or out of time given by a contract?
• are you running out of the publishing media space (DVD full)
• are you running out of the performance space (new features would cause the game to run too slow)?
• is a competing game coming to be published soon?

Simple real-life issues like that need to considered as well, unless you are developing the game just for you fun.

Answer 8

When you run out of paper to write it on.

The definite limit is going to be the media size; you can't fit 10GB of features on a 4.7GB DVD, for example.

You don't want too many features as to overcomplicate the game, either. The best way is to wonder 'is this going to be significantly fun for the player? is it going to eat into our development time too much? is this even possible?'