Hiro face a bunch of evil samurai warriors in Mini Ninjas

I recently finished working on Mini Ninjas, IO Interactive’s new game for Xbox360, Ps3, Wii, PC & DS, due for release September 2009. If you haven’t heard about the game yet, there’s a ton of previews to be found around the web.

During work on Mini Ninjas I had some experiences in dealing with complex feature interactions, that led me to create a simple tool for designing gameplay features.

It’s a tool which can be used during pre-production, when you plan out the feature set you want to include in your game.

It can also be used as a “change management” tool, when you need to get an idea of the implications of adding, changing or removing a specific feature from a game that’s already in development.

I call this “The Feature Matrix” and I’d like to share some of the ideas behind it.

The problem with new features

As you might gather from reading the previews, Mini Ninjas is a game which contain quite a large number of different features:

Ninjas, their weapons, skills, moves, magic spells (and so on) all need to fit perfectly together with all the enemies, bosses, animals, collectibles and a horde of other game features, in order to create a coherent game experience without too many bugs, exploits and “weird” behavior.

The biggest problem with creating a game with many features is not the time it takes to make individual, new features. It’s how these interact with the rest of the game.

Complexity rises exponentially as more features are added to a game... *sigh*

A game’s complexity seems to increases in a non-linear fashion when you add new stuff, because features need to interact with other features in order to have any effect on the gameplay. If they can’t interact or DO anything they aren’t much good, are they?

Let me exemplify:

Let’s say we add a new weapon to the game, then obviously it needs to be able to hit enemies and have some kind of effect, otherwise it’s pretty useless.

So the different “enemies” features need to be modified to interact with the new weapon. But a lot of other features may also be relevant to update:

• Does the weapon make enemies react in a certain way (stunned/panic etc.)?
• Does it make enemies play special or behavior animations?
• Does it release any effects like fire/sparks/lightning?
• Does it use ammo, and need to interact with an “ammo feature”?
• Does it appear in inventory and need icons and properties to fit in there ?
• Can it be sold and need price/rarity for a “shop feature”?
• Can the weapon be stored/found/picked up and need to interact with “loot feature”?
• Can it be dropped and need physics or to be able to obstruct pathfinder?

… and so on!

Actually you would probably discover that adding a new feature means you have to look into at least half of your existing features and modify something (big or small) in order for it to work smoothly. So adding a new feature is adding a large number of special cases, some of these being such big issues they might even be considered an entirely new features themselves. Cutting out features will also have the same kinds of implications.

As more features are added or changed the complexity skyrockets, and it quickly becomes impossible for most human brains to cope with the implications of adding, changing or removing anything in the game.

No wonder game development schedules slip and games are delayed!

Next Page »

Pages: 1 2 3 4

Tags: change management, development, feature matrix, Features, game design, what-if-scenarios

This entry was posted on Tuesday, August 4th, 2009 at 4:37 pm and is filed under game design.