Design Goals

I have played a lot of games, and in so doing I have seen a lot of the same mistakes, or at least design decisions that I disagree with, repeated many times.
I have also seen many excellent ideas in games that really helped them to stand out and be exceptional.

Recently, I’ve taken some time to think about the types of things that I do and don’t like to see in games, and from there I have created a list of what I consider to be good game design goals.

Of course, some of these are subjective – they are for making the type of games I like to see – but most of them are fairly general and should apply to almost every game.

Game Design Goals

1. The player should have to think.

While some amount of direction is necessary, the player shouldn’t be spoon-fed exactly what to do next every second, or every time that they complete an objective.  Occasional hints are fine, but the player should need to think and work out how to achieve their goals for themselves, rather than just following instructions.

Bad: The player is told exactly what to do each step of the way.
Good: The player is told roughly what to do, and can find information hinting at the solution, or work it out for themselves.

2. Controls should enable player actions rather than restrict them

The player should spend their time fighting your game’s challenges, not the controls.

Bad: A strategy game intentionally limits the number of units you can control at once, to force the player to make more clicks to issue orders.
Bad: A game makes the player repeatedly perform a no-brainer action, even though it is an obvious choice and draws attention away from the game’s main aspects.
Good: A game does not do these things.

3. Meaningful choices shouldn’t be automated

While the game should do no-brainers automatically, it shouldn’t remove any chance for the player to think for themselves.

Example 1: using the appropriate key to unlock a door automatically is fine (because using the key labelled for this door is a no-brainer, as is trying every key that you own one after the other.)

Example 2: the player should need to manually select to use a lever to pry open a sarcophagus, because both deciding to open the sarcophagus and working out which object to use require thought.

4. Puzzle solutions should be logical, and multiple

The solutions to all puzzles should be logical.  If the solution is something that no one would think of on their own, then it’s wrong.  An ideal difficult puzzle should have the player stumped for a bit, but once they work out the solution they should think “oh, that makes sense, why didn’t I think of that before?”

In addition, if there are multiple solutions to a problem that make sense, all should be possible.
If a tester has trouble with a puzzle, and instead thinks that the solution should be something other than it is – the extra solution should be incorporated and made available as an alternate solution.

5. Perception before trial-and-error

It should be possible for a perceptive player to avoid dying to any trap or hazard on their first playthrough.  They should not have to resort to trial-and-error gameplay, dying to discover that something is dangerous and then having to reload to avoid it.

Bad: The player steps on a perfectly ordinary piece of floor and it breaks and plunges him to his death without warning.
Good: The observant player can see a slightly raised section of floor which is a pressure plate, and can see a series of round holes in the wall from which arrows will fly if the pressure plate is triggered.  The unobservant player might step on the plate without noticing, but the observant player should be able to deduce the nature of the trap and avoid it.

6. Introduce features in a safe area

When introducing a new feature or player ability, it should be done in a safe area to give the player time to learn, play with, and understand that feature before they have to use it in a dangerous or time-critical situation.  The player should be able to retry the task as often as they like without penalty.

Bad: The player has to use a new movement mechanic for the first time.  A hint appears explaining the procedure as the player steps on an unsound platform, which immediately begins to shake (even while the player is still reading the hint).  After a few shakes, the platform collapses, throwing the player to their death.
Good: A new movement mechanic is introduced in an area where failing and falling down will not injure the player.

7. Fitting to the game world

Puzzles and challenges should be appropriate to the game world.  Something shouldn’t be included just for the sake of it if it doesn’t fit.

Bad: An area of a game involving exploring ancient ruins suddenly requires the player to solve an 8-tile puzzle to proceed.
Good: An area of a game involving breaking into a castle requires the player to avoid or overcome the guards.

8. Decisions should be apparent, even if the outcomes are not immediately clear

If an action that the player makes can affect something significant later in the game, the player should at least be informed that there is a decision to make, even if they cannot know the specific details.  This is much less important if the change is only aesthetic.

Bad: The player pulls a random lever and a section of the game’s later content becomes inaccessible permanently.
Good: The player is asked to murder an NPC; he can tell the quest giver that he won’t, or can do it.  If he chooses to do it, then there are consequences later.

9. Systems should be fun

Make sure that you ask your testers which parts they found fun and which parts they hated or found excessively frustrating.
Try to find ways to make hated/frustrating systems more fun, replace them with another system, remove them entirely, or at least greatly limit their frequency and/or make them optional.

Bad: An extremely unfun and frustrating minigame is mandatory and scattered liberally throughout the entire game.
Good: A minigame was deemed unfun during testing, and so was redesigned to be less frustrating, and the number of instances was reduced to mostly optional areas.

10. No random points of no return

The player should be able to go back to any previous part of the game area, within reason.
Areas should only be closed off for a good story or gameplay reason, and if closing off the area will permanently lock the player out of content in that area, the player should be warned ahead of time.

Bad: The player walks through a door and it permanently seals behind her, locking off access to an undiscovered secret area prior to the door.
Good: The player walks through a door and it closes behind her as part of an ambush, but she can re-open it later to return to the previous area.
Good: The player can freely travel to any previously-visited area of the current mission, even if some areas might be temporarily inaccessible at certain times.

User Interface and Control Goals

1. Consistent and optimal controls

Controls should be consistent, sensible, fluid, customisable where possible, and tailored to the benefits of the platform.
The player should not have to fight the controls.
If the game is being made for multiple platforms, its control scheme should be optimised for each, rather than all platforms using the same control scheme of the lowest common denominator.

Bad: Different keys do different (unrelated) things depending on context; the control scheme is not consistent.
Bad: Controls are clunky, slow, and unresponsive.
Bad: Keys for some actions are hard-coded and cannot be customised, or can only be partially customised in some circumstances. Multiple unrelated actions are bound to the same key (short press, long press) and cannot be configured to use different buttons.
Bad: A game’s control scheme is designed to be workable on a console controller with few buttons.  Some actions are awkward, such as holding one button to perform another, unrelated action. On the PC version of the game, this same control scheme is maintained, rather than allowing the player to bind a different key to each function.

2. The player should retain basic control of the game at all times

While there are times when the game may have reason to restrict the player’s ability to control their character, it should never take away their ability to perform such basic game functions as pause, reload, or quit.

Bad: A game has an unskippable section during which the main menu is disabled, and the game cannot be quit via alt-F4, so the only way to escape from that section is to forcibly quit (task manager / power-off)
Good: The player is tied up upside-down and holding a conversation with their captor.  All other controls are disabled, but the player can still enter the main menu to pause, reload, or quit.  The quickload key is also still available.

3. Freedom of movement

The player character should be able to move across the terrain in a realistic manner, without artificial constraints.  This includes climbing over any small obstacles or jumping off heights.  The player should also be able to control their movement precisely.  If there are any long control animations, it should be possible to interrupt them partway through and regain control of the character

Bad: The player has the ability to grab onto cables and slide along them, but cannot choose when to let go – instead, they have no choice but to hang on until the end of the cable.
Good: The player can grab onto cables and slide along them, letting go at any point of their choosing.
Bad: A player cannot walk off the slightest ledge and every area has precise “invisible walls” controlling exactly where the player can and cannot move.
Good: A player can freely walk off any ledge, climb any small obstacle, and generally navigate the terrain with as much agility as a normal person, within reason.