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

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

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.