Plan for Jay Barnson
by Jay Barnson · 01/21/2005 (9:55 am) · 4 comments
Rules of Game Design, Part 1
This is an extended version of something I originally posted on my blog last week. But since all of like two people are reading it, and I thought someone might pull out a tiny bit of useful information out of this --- or more importantly, might suggest some really good rules of their own to get added to the list --- I thought I'd post it here as well.
I have no idea how far this will go, and I know Noah Falstein 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 of Play 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.
It goes a little further than this, too. You shouldn't have your game ever 'win' itself without the player's involvement. This is unlikely to occur in a turn-based strategy game or a first-person shooter. But it's possible in a sim-city type simulation, or a mission-based game with allies, that you could have an inherent stability in the game where the player's involvement is unimportant to winning the scenario. The opening position is too strong, the allies are too capable, whatever. I haven't seen too many games with this problem, but it does crop up from time to time.
#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 - Imperceptible Causes are Meaningless and Frustrating. (Cribbed from Greg Costikyan)
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 influencing the game's state, and make this clearly available to the player. Or better yet, you simplify them so you don't need to.
#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. Just because computers are really powerful at number-crunching doesn't mean that you need to take advantage of this in your game rules.
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.
There's of course a zillion more rules that could be added here - I've already got a handful. But I'd like to hear what others have to say!
This is an extended version of something I originally posted on my blog last week. But since all of like two people are reading it, and I thought someone might pull out a tiny bit of useful information out of this --- or more importantly, might suggest some really good rules of their own to get added to the list --- I thought I'd post it here as well.
I have no idea how far this will go, and I know Noah Falstein 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 of Play 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.
It goes a little further than this, too. You shouldn't have your game ever 'win' itself without the player's involvement. This is unlikely to occur in a turn-based strategy game or a first-person shooter. But it's possible in a sim-city type simulation, or a mission-based game with allies, that you could have an inherent stability in the game where the player's involvement is unimportant to winning the scenario. The opening position is too strong, the allies are too capable, whatever. I haven't seen too many games with this problem, but it does crop up from time to time.
#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 - Imperceptible Causes are Meaningless and Frustrating. (Cribbed from Greg Costikyan)
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 influencing the game's state, and make this clearly available to the player. Or better yet, you simplify them so you don't need to.
#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. Just because computers are really powerful at number-crunching doesn't mean that you need to take advantage of this in your game rules.
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.
There's of course a zillion more rules that could be added here - I've already got a handful. But I'd like to hear what others have to say!
About the author
Jay has been a mainstream and indie game developer for a... uh, long time. His professional start came in 1994 developing titles for the then-unknown and upcoming Sony Playstation. He runs Rampant Games and blogs at Tales of the Rampant Coyote.
#2
#12 - If your game is predominantly multiplayer ... make sure there is some single player mode to bring people into the game and let the get comfortable. Also even in multiplayer ... add bots from the get go so people can get into multiplayer and play against the bots.
#13 - Don't forget to have peaks and valleys ... nothing's interesting if there aren't surprises and little changes throughout.
#14 - Always add some form of replay value ... even something simple like recording the time it took to beat a level as in Marble Blast or Aerial Antics can lead to hours of extra fun if you and a friend go back and forth beating each other's time.
#15 - Game controls ... either nail the absolutely perfect control scheme for your game or give the player a wide wide variety of options to control it ... support as many control types as possible.
#16 - Don't forget the easter eggs ... something it seems many games have been missing lately ... add those little special touches and secrets ... they just add to the lore of a game and they can also add replay value and most importantly a sense of character.
01/21/2005 (1:53 pm)
Good stuff!#12 - If your game is predominantly multiplayer ... make sure there is some single player mode to bring people into the game and let the get comfortable. Also even in multiplayer ... add bots from the get go so people can get into multiplayer and play against the bots.
#13 - Don't forget to have peaks and valleys ... nothing's interesting if there aren't surprises and little changes throughout.
#14 - Always add some form of replay value ... even something simple like recording the time it took to beat a level as in Marble Blast or Aerial Antics can lead to hours of extra fun if you and a friend go back and forth beating each other's time.
#15 - Game controls ... either nail the absolutely perfect control scheme for your game or give the player a wide wide variety of options to control it ... support as many control types as possible.
#16 - Don't forget the easter eggs ... something it seems many games have been missing lately ... add those little special touches and secrets ... they just add to the lore of a game and they can also add replay value and most importantly a sense of character.
#3
01/21/2005 (5:34 pm)
Great topic gents, and well presented.
#4
I've actually heard some contention on Teck's point #9 - that difficulty levels are a sign of weak design, and the designers are shrinking from the decision-making by setting the difficulty level. I don't agree, personally - but it's been argued.
01/22/2005 (9:25 am)
Some nice thoughts here - thanks guys!I've actually heard some contention on Teck's point #9 - that difficulty levels are a sign of weak design, and the designers are shrinking from the decision-making by setting the difficulty level. I don't agree, personally - but it's been argued.
Torque Owner Teck Lee Tan
#9 - Difficulty levels. Don't decide for your players what might be too hard for them. If there are 3 difficulty levels, and I am feeling particularly masochistic, let me pick the toughest one without having to play through the entire game on a lower difficulty first! That's called artificially extending the life of the game, folks, and is a big no-no in my books.
#10 - Artificially extending the life of your game. Going along with #9 is the awful habit of games telling the player that they can unlock these cool features by playing through the same bloody game twice. Or thrice. Or more. I don't have that kind of time, you hear?
#11 - Reaching the overarching goal. I can't think of a better example than this. If your goal is to save someone's life, make sure the player feels he/she is worth saving! I can't stress this enough. Prince of Persia: Warrior Within's overarching goal was to stop the creation of the Sands of Time in order to save his life. Honestly, I could care less about the prince in this game. I couldn't stand him. Why would I go through hours of bad puzzles and repetitive combat to save the idiot's life? The same applies to anything, really. Make sure your player can sympathize, empathize, understand the overarching goal, and actually wants to achieve it.