I'm a very systematic, process-oriented designer, and so I tend to think that the best way to design is to establish a list of values, then work through a thorough design process, using the values and context to weigh each design decision. I'll write a much longer post on this later, I'm sure.
All those caveats aside, I do believe there are 3 very generic guidelines that can improve any game, and that I will always follow in every game that I design. 2 of them are about teaching players, and 1 of them is about usability, so I suppose that gives a pretty accurate picture of what my priorities are.
1. If you want to change your players' behavior, you need to change your game design.
Letting players loose on your game for the first time can be a very jarring experience for new designers. It's the moment that you often find out the game that you thought you made isn't the game your players think you made. And the players are always right, so let me save you months of frustration by telling you not to try and fight it.
Almost all of the funniest war stories game designers tell each other are really about the difference between how the design team expected the players to use a system, and how the players ended up actually using it. There are some very famous example of this effect, which deserve a post of their own later. The important thing to take away now is that the players are not just crazy. They're using your game in the way that they've been encouraged to, either mathematically, psychologically, or socially.
Practically any behavior can be encouraged, discouraged, or prevented by careful game design, especially reward systems. If players are misbehaving, it is likely because the game design is allowing or even encouraging it.
2. The game must teach the player what the game expects the player to know.
I was watching a friend play Mirror's Edge the other day. He'd been playing it for several days, and was well over halfway through the game. After reinforcing in mission after mission that the game is about running across the rooftops, relying on speed and agility to save you, the game suddenly stumped us with a new requirement: After trying everything we could think of to get high enough to jump over a barbed wire fence, we finally noticed that when we stood on the ground next to the back door of a truck, we had the option to interact with the door, and enter the truck.
After all the learning we had done in the game, the game suddenly required us to know that it's possible to hide in the back of a truck and wait for it to be driven through a checkpoint. This was something the game never taught us previously, which made us angry when we finally realized what we were expected to do. We had been trying to play the game the "right" way, and suddenly the game decided that the right way was now the wrong way. Which leads me to a sidenote...
Corollary 2A. The game should never teach the player to do something the player is expected not to do(!!)
While it was frustrating to waste so much time on what should have been a simple task, the real damage may have been done to our ability to enjoy the game in subsequent levels. My friend and I have now both been trained to think that Mirror's Edge is a game that's almost always about finding a way through the rooftops and using speed and agility, but also sometimes a game about clicking on the back door of a truck to hide in them.
For the remainder of the game, when we are presented with a challenge that we can't figure out, we will now be compelled to doubt that there is a movement-based solution to the problem, and start walking around trying to interact with things that never did anything before, just in case the designers decided to throw us another curve ball. Walking around and clicking on things is specifically what the game is not intended to be about, so by adding that to the list of problem-solving options at our disposal, that unnasuming truck is forcing players away from the core of the game's fun.
This example also serves to illustrate how important guideline number 1 is: if your players are walking around slowly clicking on things when you want them to be flying through the landscape having fun, figure out what aspect of your game encouraged that behavior and remove it.
3. Whatever actions the player will perform the most often must be the easiest actions to perform.
This guideline doesn't just apply to designing games, but to designing anything at all. (Despite this being a game design blog and me being a game designer, I believe that many tenets of good design apply to any type of product.) Because of that, it will actually be easiest to convey with examples from industrial design.
Take a look at this image of an alarm clock's UI buttons. There are tiny buttons to change the time zone, the year, the time, and a giant snooze button. What's the ratio of the number of times you want to tell your alarm clock to snooze versus do any other thing such as change alarm time, set the time or date, or anything else? I'd guess in my case it's over 100:1. How silly would it be if the snooze button were the same size as, or even smaller than, the time zone button?
A hammer only does two things, and one of them is much less common, but still important. This hammer is a pretty fancy model with an ergonomic grip and a curved handle. Which do you think the shape of the handle is optimized for, hammering in nails with one side, or pulling them out with the other? It actually looks like they've put some effort into angling the claws so that there'd be better leverage when pulling out nails, but I can guarantee you they wouldn't allow nail-pulling comfort to interfere with nail-hammering comfort or effectiveness.
Ok, these are insultingly obvious examples, but there are lots of videogames that are more like a swiss army knife, where you've got to locate and deploy the tool you're looking for before you can use it. Depending on the action you're trying to perform, even hitting one extra keystroke, clicking one extra mouse button, or expanding one extra menu page can build up into a huge amount of perceived inconvenience over tens and hundreds of hours of use.
I'll delve into this more later, but let's take some quick examples from an MMO. In this type of game, there are a set of actions that players are frequently expected to perform:
- Determining how difficult a challenge an enemy poses
- Looting mobs
- Finding and accepting quests
- Turning in quests
- Evaluating a given piece of gear against current equipment
- Purchasing new abilities
- Joining a team
Again, take note of how this rule interacts with the previous rules: Players need what's important to be easy, but if the "wrong" things are presented to them as the most easy to do, they'll be taught to perform those actions frequently, and if you want to stop the players from doing something, look at what aspect of your UI design is encouraging them to do so and change it. One quick example: if your game is not about players tracking down and terrorizing other players, don't show enemy players and their screennames on the rader/minimap.
I hate to encourage the idea of immutable game design rules, but I do believe that any designer who follows these 3 guidelines will produce games that are of higher quality and more likely to be perceived of fun, regardless of their mechanics.