Rules of Game Design, Part 1
I have no idea how far this will go, and I know Noah Fahlstein is currently assembling a list like this, but here's a bit of jotting down some of the rules I've accumulated - either from hard-earned experience, or cribbed from designers much smarter and more experienced than I. Here are a few. These are specific to computer game & videogame development, but they may be applicable to other forms of gaming.

These are in the form of a brain-dump, so their order doesn't matter whatsoever. And all rules are made to be broken - these are no exception.

#1 - The First Few Minutes are ALL-important.
I've heard the this referred to as the first five minutes, the first ten minutes, and the first fifteen minutes rule. I guess it depends upon the attention span and circumstances of the player. As a game developer, you have a really tiny window of opportunity to strut your stuff and convince the player that your game is worthwhile. Even if they have already purchased your game, their initial opinions from the first few minutes will be the foundation upon which the rest of their experience will be based. It's absolutely critical to rock here - don't save all the cool stuff to the end. And make sure that the game is accessible enough that the player is feeling comfortable and reasonably competent on the controls within this time period.

#2 - The Player Shouldn't Have to RTFM
Kind of a corollary to #1 - Do you want your player spending their first few minutes with your game playing, or reading a dry documentation explaining what obscure key combos they need to hit to open the first door? Your game should be as self-explanatory as possible. This isn't to say that manual isn't important or useful - you MUST have it, and it can go into details and hints that may improve the player's experience. But it should be completely optional to the player.

#3 - The Bad Guys Always Have the Advantage
This is more important in strategy and action games, but make sure the player doesn't have the advantage of both mobility AND range over his opponents. That results in a very basic, cheap strategy that players WILL exploit. This is mitigated if the enemy has the advantage of numbers and will use it intelligently to circle around or box in the player (such as in a sniper game). But you just never want to end up in a situation where the player can win the level by just hanging out and shooting from a safe distance.

#4 - Provide plenty of feedback to the player!
One of the most frustrating and infuriating things to experience in a game is a lack of response to player commands. This could be as simple as not highlighting a button that the player is hovering over or showing it getting pressed - to something more significant like not providing a clear visual to show whether or not the player is doing damage to an object he is shooting. This may be difficult as a developer / designer, as you understand what's happening 'under the hood' - but remember your player doesn't, and he's going to need things spelled out to him (preferably with lots of cool special effects and satisfying noises).

#5 - Subtlety is usually lost on players
In a nutshell, if the player didn't notice it, it didn't happen. This is true everywhere - from creating differences between stats on weapons, to showing emotion from the NPCs, to giving players power-ups.

#6 - (Cribbed from Greg Costikyan) Imperceptible causes are meaningless and frustrating.
Sort of a corollary to #4 and #5, above - the player must always be able to determine cause and effect. If it's a cluttered, horrible combination of factors (as in a detailed strategy game), you need to enumerate them and show exactly how they are playing into changing the game state.

#7 - Cut out anything that doesn't serve the core gameplay
Rather than thinking of what you can add to a game, think about what you can take away. So many games suffer from 'feature-itis' that the parts that are supposed to make the game FUN are lost underneath a ton of 'added value' features. Cut out everything that doesn't make your game GREAT. Focus on features that enhance and reinforce the core game.

Sometimes this rule appears to be violated, but really isn't. X-Com is a classic example - the 'macro' game might at first appear to be separate and 'needless clutter' to the core gameplay (which was the tactical combat). But it did several things. First of all, it provided context - a meaning for otherwise meaningless battles. It provided a little break between missions. It provided a clear progression path for missions, and unique player-created sub-goals for missions (such as, "capture one of the aliens alive for study!"). And finally, it provided the player with some measure of control over what missions he was going to be involved in, and set his own level of challenge and resources.

#8 - The Interface Should NEVER be Part of the Challenge
The player should be challenged by your game. That's a big part of the fun. What shouldn't challenge the player is the interface. Ideally, your game should be able to play the same if your player's brain was directly hooked up to the machine. Forcing the player to "learn" the controls isn't fun. Now - mastery of the controls to pull off tricky maneuvers --- that's all well and good. Hitting A and B in combination with a move up to pull off a uppercut is fine - as is trying to complete a complex step it Dance Dance Revolution. But forcing the player to go all over the keyboard to perform a basic action is bad design.

Well, that's all I have time for now. More soon!

Labels: Game Design

- posted by The Rampant Coyote @ 8:23 AM (Permalink)