When Do Good Ideas Become Bad Ideas?

My first games suffered because I didn't realize that more content makes the game worse. I still have Version 23 of the rule book for a game where you settled court cases with rock paper scissors. It's 25 pages long and full of unnecessary mechanics and constructs. Nobody understood how to play it, and nobody wanted to play it after their first exposure. It was a huge failure that made me more careful about getting a game ready for playtesting.

Here are a few rules of thumb to stick to:

1. If you can't explain how your game works in under 2 minutes, then your game is too complicated.
An example of a game that's too complicated: http://www.youtube.com/watch?v=20085bVFeMA
An example of a game that's delightfully uncomplicated: http://www.youtube.com/watch?v=o3BJReS891s

2. Test your mechanics separately. Each mechanic in your game can sometimes be considered as its own game. Write a small game description for the mechanic, including the objective, the rules, and the components, and test it out. Ask yourself: can this mechanic be replaced with a simpler mechanic that does the same thing?
The game Power Grid is an excellent example of that separation: the auction phase is a separate game from the resource purchasing phase and the network expansion phase. They're linked together by the fact that you need money to buy new reactors, resources, and network locations, and you only get money after all of those phases are complete for a round.

3. Pretend that you are making a basic came, and that your grand ideas can be included as expansions to that game. When you decide to add a new mechanic, think to yourself: would this be appropriate for a basic game, or does it fit better in an expansion?

I've never published a game, so take this with a pillar of salt. But I just pop them off into different games.

I started out in Game Design wanting to to a global political simulator, well i needed two things for that, one was role playing that would be less than balanced, but still not broken, and one was a option for an "everybody wins" scenario, combining co-op with competitive.

As I started experimenting I ended up with a game premise that fit more as a spoof of sci fi tropes than serious political conflict, what with he wants to save her, but he wants to kill him before he does. So I cordoned off the big political game until I had more experience and worked on Sci fi.

The battle mechanic I was working with was too complicated, but I liked it, so It's now it's own game, and it has nothing to do with the concept it came from. It's about Animals.

Well planets and space and 3 dimensions was a little much, so I decided to simplify it down into one battlefield with a fantasy motif, and when I fix it, I can go scifi with it. The fantasy game needs mechanics for fewer players that allow some roles to "play themselves" and as I experimented with one such role in particular, I found a mechanic worked poorly for terrestrial travel, but perfectly for aquatic travel.

Now I'm almost done with a pirate game featuring that mechanic.

You don't have to be so compulsive with different themes as I am. But if you have a working game based on trade, and you think of a good battle mechanic, write it down, but don't stick it in your trade game unless it needs it.

I don't think a good idea becomes a bad idea.

But good ideas can become too big for the game you are trying to create.

As you design, just keep your target audience in mind. What do they want from your game? Will a specific mechanic increase or decrease those players' enjoyment of the game?

If you are designing an FPS for bloodthirsty 13 year-olds, then an in-depth crafting mechanic may be unnecessary and over-complicate your design.

Remember; the players' two main resources are time and brain power/energy. Those 2 resources should be focused on the most enjoyable(to them) aspects of your game.

My favorite subject!

Didn't see any replies that said this so... The way I see it is that any feature, mechanic or content bit will typically have value and cost. Value in how much fun, or strategy or immersion it brings, and cost in how the learning threshold is raised, how much longer a game takes and so on. The common beginner mistake is to underestimate (or worse not being aware of) the costs. For each thing you want to add, weigh them against each other and their total weight against the weight of the other things. This weight will of course be completely subjective, but that is fine. We're talking about creating enjoyment and that is pretty subjective too.

I feel that cost tend to grow exponentially while value is at most added, or serialized, which means that you'll be worse off the more stuff you put in. This is my reasoning that justifies "removing until it breaks" and "less is more."

/Henrik

I'll rephrase some things other people have said.

The focus needs to first be that the game is winnable. Can the players interact and achieve victory in the game? This needs to be achievable with the least number of components and mechanics possible within the theme.

If you have a game where you want players to try and move a hidden color of pawns off of the game board while a neutral set of adversaries can attack the pawns [like say an island infested with hungry dinosaurs attacking families, where there's not enough life boats, but any pawn or dinosaur can be moved by any player].

Just get the game to the point where its winnable. As in, there's a board, pawns, dinosaurs, and rules for movement. NOTHING ELSE. Play the game and make sure your initial set of rules functions.

The game probably won't start out engaging or fun at this stage, that's fine. Spend time IDENTIFYING where the game is falling flat. Write this down, and then work on solving those problems by either changing what's there, or introducing more game mechanics.

Good ideas are good to have - but if you want to keep your game simple and streamlined, its always best to keep it in a state where stuff is added, not where stuff is needed to be taken away. Always add to the game as a direct response to a problem that you see in the game. Introduce one small thing at a time, and then playtest until you know whether it serves its purpose and make the kill it or shelve it call. Then identify the problems and playtest again. Don't shove a bunch of new things into the design at the same time - because then you don't know what is or isn't working specifically.

This process is a long one, however it will reduce the amount of streamlining you'll need to do, and you always know you can back it to an earlier version and retry a specific fix to a problem. All those great ideas you had, can be used in other games of course :-)

Addendum:

When we say, "keep your game simple" or "cut the fat" or "simplify it", we really do mean that; however, a game doesn't stay that way. You have to get it down to a point where it's playable and fun at a basic level. Then, you can add stuff back in.

In a way, your prototype is like your trunk of cool things, and you are a magician who constantly performs shows. You only have so much time to do your show (play the game) and your trunk can only fit a certain volume of cool stuff (game content). You want the show to be as interesting as possible, so you have to leave things out, even if they are amazing. When you build your game, think of yourself as packing a trunk full of cool things; "What will I bring with me to really impress these people?"

That is my analogy of the night.