How to design an awesome game, part two : Ideas are a dime a dozen

In part one, I said that I was going to focus on awesome gameplay, as opposed to awesome graphics or sound or etc.  And since awesome gameplay rests on having an interesting and unusual gameplay mechanic, this means that we need to think about ideas.

It’s often said that in the game industry that ideas are a dime a dozen;  they’re virtually worthless on their own.  And to a certain extent, this is true.  In terms of time and manpower, implementation details are far more costly and make a far greater impact in the bottom line;  that is, whether or not a game is good.

People say this because there is no shortage of good or even great ideas. Brainstorm for a minute or two and anybody even vaguely familiar with the gaming industry can generate a dozen or more, just by copying and recombining elements of existing games in a slightly new way.

But if our goal is to make an awesome game — not just a good or popular one (and let’s not kid ourselves;  awesome games frequently do not do well in the market, despite rave reviews) — then we need an awesome idea to start with.  I’m going to assert that the difference between a good game and an awesome game rests entirely in the quality of the initial idea.

(I’ll also assert that the difference between a good game and a great game is entirely unrelated to the core idea.  And since great games sell better than awesome games, most game makers don’t even attempt to make awesome games — awesome games usually require a lot more work, and usually earn a lot less!)

So what separates a good idea from an awesome one, and how can you distinguish between them?  More beneath the fold.

I’ve been putting a lot of thought into this, and have been working out a framework for classifying awesome ideas.  My suspicion is that any idea which passes all of these requirements is likely to be an awesome idea.  Which isn’t to say that any game based upon an awesome idea will automatically be an awesome game; just that it has the potential to be one.

The idea can easily be expressed in 25 words or less

Simple rule of thumb:  If the central idea is more than 25 words or two sentences long, then it is almost definitely too complicated to be awesome.  The very best ideas can usually fit down into 15 words or less.  Complicated ideas are always much more difficult to convey to a development team (if any), and to end users, and so tend not to be as intuitive or compelling.

The idea does not mention a licensed property

This is another basic rule-of-thumb one.  If particular central idea has spent words mentioning popular television/film/etc characters or settings, then it almost certainly isn’t an awesome idea.  There’s nothing necessarily wrong with working on licensed games, as long as you recognise that you’re working on a game first, and a licensed property second.  This is one reason why licensed games have such a bad reputation;  the folks making them start with the license and then try to figure out a game to make based on it, when they should be working the other way around.

Awesome game ideas are rare enough to come by without restricting yourself to the ones which will work with a particular licensed property you want to use.  If you want to do something awesome, make the awesome idea first, and then go looking for an appropriate licensed property to match the idea later, if you must.  The best place for this is in the full game design document, not in the core game idea.

The idea contains an active verb

An awesome idea contains a verb which says what the player does in the game.  Be extremely skeptical of ideas which contain the verb “is” or “are”, or which merely describe a setting, as in:  “The player is a renegade cop out to get revenge for his murdered partner” or “It’s an FPS set inside a giant torus, which spins so that outside surface of the torus is always ‘down’.”

The idea generates its own game mechanics

I get an immediate gut reaction when I hear an awesome idea.  I suddenly get a mental cascade of game mechanics which seem to just fall out of the core idea automatically;  they’re simple and obvious, and totally natural extensions of the core idea.  By comparison, the usual “dime-a-dozen” ideas which tend to spark good and great games usually require a lot more work to develop their appropriate gameplay mechanics.

As a basic example, the core idea from Portal (A puzzle-based first-person game where the player can place persistant teleporters onto any surface) immediately brings to mind images of getting past obstacles by putting one teleporter on the ceiling beyond the obstacle, and another on a nearby wall, and of using the portals to attack enemies by dropping them through the floor into dangerous locations.

On the other hand, the core idea of Halo (An FPS where the player is a cyborg supermarine, assaulting enemy forces on a ring world) doesn’t immediately generate any gameplay mechanics at all;  you can pretty well infer that there’ll be a bunch of guns since it’s an FPS, but you don’t have any specifics about the particular weapons that will be used or about just exactly what you’ll be doing during the game, so you have to start generating interesting gameplay mechanics without the help from the core idea.  For example, one of these gameplay ideas from Halo was to have health bars for both health and shield. Your shield takes damage first, and will regenerate after a while.  Health will not regenerate without a health pack, etc.

Halo’s idea was not awesome;  it was actually a pretty standard “dime a dozen” idea, even at the time.  But while Halo was a great game due to its great tuning and the production values particularly on its graphics (at least, up to the Library level), I don’t think anyone would go so far as to call its basic premise awesome.  At least, not in the same way that you would about Portal or Katamari.

The idea, as stated, does not describe an existing game.

In other words..  “The player collects objects smaller than himself, and collecting those objects slowly makes him larger” is no longer an awesome idea, as it has already been used.

So, where does this leave us?

Theoretically, we should now be able to work through these frameworks to make ourselves awesome game ideas without too much trouble, just by avoiding the pitfalls.

Here are a couple possibilities, from five minutes brainstorming:

  1. The player shoots harmless “magnets” at enemies.  After shooting two enemies, those enemies are smashed together, destroying anything between them.
  2. A scrolling shooter where the player takes control of any enemy ship he attacks, losing whatever ship he was using before.
  3. A platform game where the player may drastically grow and shrink at will.

Any of these could be turned into a really innovative game.  To my knowledge, none of them have been done before, and they all seem (to me) to imply a lot of possible gameplay mechanics that would easily strap on;  #1 could have switches and puzzle elements which require being smashed by enemies.  #2 could have impassable areas which the player must shoot through, to take control of an enemy on the other side.  #3 could have dozens of maneuverability puzzles based upon the player’s size and ability to shift.

I’ll have a bit of a think, and maybe select one of these three (or maybe something entirely else!  No sense to limiting myself to what I came up with in just a five minute brainstorming session), and we’ll move into the real design phase in the next “How to design an awesome game” post.