next »

[Zaratustra]

These coalesced in my brain from many years of Gamasutra articles, wry observationing, and some heavy nights of drinking. Agree or disagree as you see fit. I may write more later.

#1: If the player doesn't see it, it doesn't exist.
#1.1: Don't bother designing things nobody will see.
#1.1.1: It's OK to design things only a few people will see, but don't complain when nobody notices. (see rule #2, #3)
#1.2: If you do something really cool, make sure the player notices.
#2: The player doesn't pay attention to anything.
#2.1: The player doesn't read the manual.
#2.1.1: The player doesn't read the readme.
#2.1.2: The player doesn't read the start screen.
#2.1.3: The player doesn't read the tutorial if they can skip it.
#2.2: The only way to get the player to read something is to not let them leave until they did.
#2.2.1: In which case they'll complain to you they can't leave and your game is broken.
#2.3: The player only notices that which you don't want them to.
#3: Keep it simple and use what you have.
#3.1: (Portal Rule) If your game has a gimmick, work the hell out of it. That's what it's there for.
#3.1.1: (Megaman Charge Shot Rule) Don't make a cool gimmick that obliviates the need for another game gimmick.
#4: Symmetry is the soul of wit.
#4.1: Everything that appears once should appear twice.
#4.2: Set the rule, then break it.

[salade]

saying to the player "hey loser, should have done the tutorial" is fair play usually.  to rule 3.1.1

[Alex May]

saying to the player "hey loser, should have done the tutorial" is fair play usually. 

Without going into the rest of the list, why do you believe this? Is it not the responsibility of the developer to ensure that the rules of the game are clearly explained?

[Cheater‽]

saying to the player "hey loser, should have done the tutorial" is fair play usually. 

Without going into the rest of the list, why do you believe this? Is it not the responsibility of the developer to ensure that the rules of the game are clearly explained?

But they are. In the tutorial.

[team_q]

I am a fan of subtle on screen help.

[Xion]

I'm with Quiggan.

But I must say that I always read the readme and tutorial unless the tutorial just covers what I already read in the readme.

[Cheater‽]

I prefer totoreals. They can have more immersiveness.

[team_q]

I find tutorials don't assume enough game play experience, so I skip unmandatory tutorials and hate mandatory ones. Great, so your game you can duck under shit and jump with 'A' cool, why am I needing to learn this again?

[Problem Machine]

#1.1: Don't bother designing things nobody will see.

I disagree with this. I don't think you should spend hours on it, but fleshing out the world behind the scenes with story bibles and the like will result in a realer and more 3 dimensional product, IMO.

[Chris Whitman]

I hate tutorials. I like it when things you have to learn come up in the context of the game.

[Lucaz]

Simple in-game explanations and a comprehensive help screen in the menu, or pressing F1 always work, except for a 4X ar some other overly complex game. The tutorial must be in parts, so more experienced people can skip pieces. If the player ignores all of that, it's his problem.

[Titch]

I dislike modern, lazy, non-manual reading players.

Whilst dynamic in-game help is so much more of a pain to program, it is so much better, more organic and breaks flow less. I bet if you set up the delays up right you could skip instructions if they player preempted them.

#5: Complexity does not equal depth

[Gnarf]

Complexity does not equal depth, but it is what allows for it. Simplicity denies depth. Simple is accessible. Depth is not accessible.

[Chris Whitman]

You know, I actually don't know what these are for.

I'm not saying they're bad ideas -- I think a lot of them are good ideas -- but do we really need to write rules for game design?

[Titch]

Complexity does not equal depth, but it is what allows for it. Simplicity denies depth. Simple is accessible. Depth is not accessible.

In my opinion, depth is more a natural progression of learning than complexity. A simple game with lots of depth, like chess, leaves less room for ambiguity because there are less contradictions in the rules to confuse players who are trying to learn without having learned all the nuances of the game.

[ஒழுக்கின்மை (Paul Eres)]

You know, I actually don't know what these are for.

I'm not saying they're bad ideas -- I think a lot of them are good ideas -- but do we really need to write rules for game design?

We don't, but I think he's being humorous.

But out of curiosity, I'd say the most important principles I know about game design are:

- make it enjoyable to control the character. enjoyable just to move around and do stuff. if you can't have fun controlling the character and doing stuff, you can't have fun with the game, levels, challenges, or any of that stuff.

- give the player a good idea of the setting: make it atmospheric if possible, make the player feel as if they a really are somewhere else, and not just in some weak simulation of it.

- if there are systems of some sort, balance them, don't make imbalances where there are dominant strategies and inferior strategies: if you have an option, make sure there's times that it's actually useful to do it, rather than something else that always works better than that option.

- if there are goals or puzzles or something, make them increasingly difficult as the game goes on, but not in a repetitive way, keep throwing new stuff at the player, so that it keeps them thinking. but don't make them unfair.

- if there's a story, write it well. it doesn't matter what the story is so much as how well it's written. a good writer can make any concept for a story into an interesting story, it's all in how you execute it.

[ஒழுக்கின்மை (Paul Eres)]

I do not think chess or go are simple, though. They may have simple rules, but that doesn't mean they are simple games.

[nihilocrat]

It would be better to characterize these as just a group of insights that hold true pretty often.

I would find it a little more useful if we defined a core set of rules which didn't deal with specific end products (like tutorials or help screens) but tried to address subconscious requirements / wants that players might have.

Example:

Bad way of saying it: "You should always force the user to confirm that they want to quit the game, and always have some sort of screen before the action begins"

Better way: "Make sure to delineate a clear border around your game, and signify when the player is entering or exiting this 'game space'"

Actually, there's a slideshow which gave some really good abstract pointers, I think I have it as a delicious bookmark, I'll have to hunt it down.

Also, the few design books I've read (like "A Theory of Fun") suggested that we get around to creating a critical vocabulary for deconstructing and analyzing games, most particularly design. A lot of design from a beginner's standpoint is a process of saying "well wouldn't it be cool to have this game, but with this other stuff in it?", probably because the only real critical material we have are game reviews which tend to do this really often.

As for complexity, look at MMOs. Too many formal rules (versus informal ones, mind you, which players can create) are going to exponentially increase the likelihood that the game will get boring quickly. The theme park MMO model, which focuses on loot and dungeons and levelling and such, is constantly fighting against its players' ability to get bored with the content.

edit: here's that presentation I was talking about: http://www.slideshare.net/avantgame/game-studies-download-30

[Gnarf]

In my opinion, depth is more a natural progression of learning than complexity. A simple game with lots of depth, like chess, leaves less room for ambiguity because there are less contradictions in the rules to confuse players who are trying to learn without having learned all the nuances of the game.

Chess is a complex game. Though its complexity arises from fairly simple and easy to understand rules. So, if you will, simple rules -- easy to learn, complex game -- hard to master.

[ஒழுக்கின்மை (Paul Eres)]

I'm sure it's better to develop these principles on one's own rather than to have a collection of them, though. I mean, it might be useful to have a lexicon for game design and all, but I don't think it'll make game designers any better at what they do. Far more important is just to play a lot of games, and to think about them. I've learned more about game design by playing terrible games (for instance, Ohrrpgce games) and learning from what they did wrong than I've learned any other method.