The Rules of Design
What is the source of ‘quality’ in a videogame? What is it that ‘good’ games have that ‘bad’ games do not? To obtain answers to these questions we must first be clear about the nature of games; at their most primary level, all games exist as the product of two factors; design and implementation. Think of design as the soul of the game and implementation as its body.
<!–[if !supportLists]–> 1. <!–[endif]–> Design is the concept, structure, intention and direction of the game – design is the responsibility of the designers
<!–[if !supportLists]–> 2. <!–[endif]–> Implementation refers to the skill with which the concept of the game is realized – implementation is the responsibility of producers, programmers and artists
Art and Programming are easily measured. If the game looks good, art has succeeded, if the game runs well, programming has succeeded. Design is not so easily measured – if the game is fun and immersive, design has succeeded.
It’s clear to anyone with a vested interest in the game industry that design is critical; if a game isn’t fun, no one will play it. A game could have the most brilliant coding and breathtaking art but if the underlying design is flawed the game simply won’t be fun. Every market, from PC to console to handheld is experiencing a glut of good-looking, high production releases. With technological advances and middleware evening the field, the spectrum differentiating a hit from a flop is narrowing – no longer will good graphics guarantee a commercial success. The video game industry has a young, savvy and discriminating audience – an audience with a decreasing patience for poor design.
If game design is so important, the discussion surrounding it must have long ago whittled down a tight list of guidelines to ensure the future is safe from poorly designed commercial disasters – right? Wrong – regrettably, although many books have been written on the topic and lectures given, the ‘science’ of design – pure design – has not yet been defined. Whereas art and programming have generally recognized measures of quality and established ancillary educational institutes, design still lurks in that magic realm of intuition and debate.
So why is it so difficult to release innovative new games?
Because it is important to have a clear gauge of design quality and project deadlines before beginning a project. Unless the designer is also the studio head and the publisher, there is a good chance that the design team will spend large amounts of time marketing, bargaining, begging, cajoling and compromising the design before the project even gets the green light for development. There is, currently, no way to provide publishers (much less, ourselves) qualifiable design reassurance (other than “He’s like Mario, only faster, and blue”). Is it any wonder that companies clog the game shelves with the same old thing?
What is lacking is the science to the process of design. Perhaps attempts have not been made to qualify good design because of the assumption that design is a creative process and creativity can not be defined by a list of rules.
In responding to this assumption, it is of foremost importance to make a distinction between design and writing. Writing is the medium of the story – similar to what is done in books and movie scripts. Although a good story is of paramount importance, video games are not books nor movies – video games are interactive and there is much more at work in a game than just a story.
Game interactivity is a science that is essentially somewhere between psychology and mathematics; designers are tasked with creating a rewarding, compelling and engaging user experience. The scope of achieving these ends has, so far, been determined by the intuition of experienced individuals and trial and error testing.
Although nothing is going to replace experience and talent, everyone can benefit from a set of rules – a starting point or a reference for the design process. Even if is nothing more than a checklist of things not to do, the creation of such a list begins to ease the esoteric burden from the ever-so-carefully monitored designer. Designers can use it as a guideline to check against new ideas or as a reference in negotiating features with other departments of the development team. Most importantly, a succinct, bulleted list of dos and don’ts would be an invaluable defense against time wasting ‘wild feature chases’ or demoralizing second-guessing.
A perfect, prioritized, list of design rules does not exist; there is no panacea of game design, no written law that will tell you exactly how to fix your game. Rather, the guidelines must be general, pertaining to all genres and platforms and offering conceptual requirements that can be applied creatively to any situation.
The focus of design should be user experience – reward, satisfaction, accessibility, adaptation, expectation and association – all psychological motivators of the sort that management gurus and lab psychologists have been aware of for years.
I’ve given more than enough introduction, so here’s my list with detailed explanations following:
<!–[if !supportLists]–> 1. <!–[endif]–> There should always be a clear objective
* <!–[if !supportLists]–> And little ambiguity to achieving that objective
* <!–[if !supportLists]–> How to do it ‘right’ should be easily determined – doing it ‘perfectly’ should be difficult – both should be rewarding
<!–[if !supportLists]–> 2. <!–[endif]–> Respond immediately to user actions
* <!–[if !supportLists]–> The user should be certain his input was received
* <!–[if !supportLists]–> Make results immediate, whenever possible
<!–[if !supportLists]–> 3. <!–[endif]–> Do not draw attention to irrelevant information
* <!–[if !supportLists]–> Cut the fat to make a sleek game
<!–[if !supportLists]–> 4. <!–[endif]–> Do not offer the user irrelevant options
* <!–[if !supportLists]–> Don’t bother the user with decisions you can make yourself
<!–[if !supportLists]–> 5. <!–[endif]–> Do not overwhelm the user
* <!–[if !supportLists]–> Introduce new concepts one at a time
* <!–[if !supportLists]–> Keep expectations of user knowledge minimal
<!–[if !supportLists]–> 6. <!–[endif]–> Do not underwhelm the user
* <!–[if !supportLists]–> Minimize non-gameplay story progress
* <!–[if !supportLists]–> Get ‘up to speed’ quickly
* <!–[if !supportLists]–> <!–[endif]–> Keep the learning curve and tutorials short
<!–[if !supportLists]–> 7. <!–[endif]–> Do not ‘punish’ the user
* <!–[if !supportLists]–> <!–[endif]–> reward success as your primary motivator
<!–[if !supportLists]–> 8. <!–[endif]–> Always explain how to fix failures
* <!–[if !supportLists]–> <!–[endif]–> If the user did something wrong, tell him how to do it right
* <!–[if !supportLists]–> <!–[endif]–> Even if the objective is to figure out what to do, give hints
<!–[if !supportLists]–> 9. <!–[endif]–> Remain consistent to user expectations
* <!–[if !supportLists]–> <!–[endif]–> Set clearly defined format and gameplay standards and stick to them
<!–[if !supportLists]–> 10. <!–[endif]–> ‘Dressing up’ cheapness will hide nothing
* <!–[if !supportLists]–> The same content in a different ‘color’ is completely redundant
<!–[if !supportLists]–> 11. <!–[endif]–> Make the most important option the most accessible
* <!–[if !supportLists]–> <!–[endif]–> ‘Options’ include any form of user input or response from ‘shooting’ to selecting ‘start’ from the menu
<!–[if !supportLists]–> 12. <!–[endif]–> ‘Fewer key presses’ is always good
<!–[if !supportLists]–> 13. <!–[endif]–> ‘Fewer keys’ is even better
<!–[if !supportLists]–> 14. <!–[endif]–> Make pausing, saving and resuming as accessible as possible
<!–[if !supportLists]–> 15. <!–[endif]–> A poorly designed feature is worse than a nonexistent feature
Why 15 items? A ‘useful’ list of design rules must not be too long –if it is, people won’t use it. Just as importantly it must not be too short or it will be too general and equally useless. 15 elements is short enough for each to be considered and detailed enough for each to be understood.
1: There should always be a clear objective
This is the most important design rule. The user won’t play long if he doesn’t know what the objective is or how to achieve it. Once the user knows what is expected of him, he then has the freedom to decide how he will do it, when he will do it and how much he’ll explore along the way. Do not expect the user to have read the manual, or even to have watched the in-game cut-scenes.
This rule applies to the overall objective as well as to every minor task encountered throughout the game. Objectives should form a chain, trickling downward from the ultimate game objective to smaller objectives that can be completed through mastery of the core game mechanics (the skills the user develops with play).
In any situation the user should ask himself only one question: “how can I use what I know how to do, to get through this?” To ask this question, he must first have a concept of what he is trying to accomplish.
A clear objective ensures that when the user is ‘stuck’ becoming ‘unstuck’ is a matter of more practice and not more searching or pondering. This is an important distinction because in the former situation, the user will be encouraged by the sensation of ‘getting closer’ to achieving the objective whereas in the latter situation the user has no idea how long he will be wandering before he stumbles upon a clue.
The essence of this rule is that the user’s concerns should always be strategic (even if the ‘strategy’ is ‘kick or punch?’), not mundane.
2: Respond immediately to user actions
The user should never wonder if a button press was registered by the system. Each time the user provides input, be it a button press, verbal command or camera-recorded movement, there should be an immediate indication of receipt. In most cases, the user input activates some form of in-game action – shoot, jump, build, etc. which has both a visible and audible effect. Where this rule more often fails is in menu actions such as selecting an item or changing a setting.
Every user action is performed in the attempt to produce an effect in-game. Ideally, the user’s success is determined immediately. If the user shoots an enemy, he immediately wants to know if the enemy is dead; even a one-second delay could be excruciatingly frustrating, given a hectic situation where the user is managing multiple enemies.
Gamers do not want to be bothered by juggling multiple concerns. The fewer secondary details that the user needs to keep in mind (such as determining which actions have produced satisfactory results), the more enjoyable the game experience will be.
Psychologically, a human learns through trial and error; an action is taken and the result is gauged. The closer in time these two events occur, the stronger the association is and the quicker it is ‘learned’. Just as touching a lever that delivers an immediate shock is a lesson not soon forgotten, taking an action in-game and seeing its immediate result is an effectively learned association.
3: Do not draw attention to irrelevant information
It was already stated in rule 1 that a clear objective is the most important design consideration. An important step in ensuring that the user is not confused is regulating the information presented to the user. All information presented to the user should promote the story arc. Of course, this ultimatum does not account for important human touches like comic relief. Non essential communications should be either subtle or clearly delineated from the game experience so that there is no confusion.
A related concern is the presentation of visual information. As graphics engines become increasingly more sophisticated background worlds are becoming increasingly lush and realistic. Whereas in old, sprite based games, it was easy to differentiate plot devices (such as pickups and doors) from the background; modern games must be careful to create contrast between items that may be interacted with and those that may not.
Visually, the game should be arranged in order of importance – the most important aspects should stand out the most and progress in visual obscurity to the least important. Frustrations can quickly mount for players who can’t identify the very tools they need to succeed.
4: Do not offer the user irrelevant options
One of the greatest failures of game design is the inability to recognize desirable interactivity. Asking the user to make an obvious decision is excessive, irrelevant and, in some ways, insulting. A good rule of thumb is that if you already know what the user will select, don’t bother asking the user. If you find that this rule cuts out 90% of your game, you really don’t have a game at all – you have a story where the user is periodically called upon to press a button to turn the page.
Another, related, failure is the ‘false’ option. Do not offer an option if it immediately returns to the user back to the same decision branch. An example is offering the user two dialog options:
“Go to hell!”
“Yes, I would be willing to help you”
The user selects the first option and the game responds, “hmmph”, ending the dialog and forcing the user to reinitiate the dialog at which point the same two dialog options are offered – the only way to proceed is to select the second option. This is fake interactivity.
Should the first option produce a lasting result such as instigating a fight, the decision becomes valid and the user will think twice before acting impolitely in the future.
5: Do not overwhelm the user
Expect that the user knows nothing; assume only what you have taught the user in-game. Think of your game as a completely controlled environment. The user should be given an opportunity at game start to get a feel for all of the basic controls; a simple sandbox situation with prompts to ‘try’ all of the relevant actions is ideal (and more effective than any pedantic and time-consuming tutorial).
New concepts should be introduced one at a time. Give the user the opportunity to test new concepts and try out new ‘moves’ as they are introduced – if you don’t they will be soon forgotten.
*A little note for the writers: Keep the story simple, even if the game is a sequel – it needs to be something that the user can relate to.
6: Do not underwhelm the user
Assume that the user has no attention span when unoccupied. Immerse the user in game-play as soon as possible and introduce the story from there; ideally the pre-story should be inconsequential – the users should feel that they are creating their own story which begins with their involvement.
Do not waste time on condescending tutorials – no one likes to be taught. Users will learn best from their own trial and error and early discoveries will develop critical positive reinforcement for the game experience. Free-form gameplay with prompts should suffice as an introduction and if your game is just so complex that it absolutely needs a tutorial, make it as short and as active as possible – let the slower users repeat it if they don’t get it the first time through.
*One more note for the writers; Keep the story interesting; this is escapist entertainment so give them excitement, discovery and new experiences.
7: Do not ‘punish’ the user
This is another important rule borrowed from psychology. Game playing is a voluntary experience – most people do it for recreation. Do not shame, punish or otherwise irritate the user.
There should be a careful balance between creating an ‘exciting’ experience, which requires the possibility of defeat and loss, and an ‘excruciating’ experience which is simply tedious and repetitive.
The user should expect a reasonable chance of success each time he undertakes a difficult task. The game ceases to be exciting as soon as he expects to fail.
If a user fails a critical task, do not allow him to dwell on the failure – immediately reengage him and restart him on a new attempt. Accordingly, save points should be spaced relative to difficulty so that the user never has to repeat too much to make a repeat attempt.
Another important consideration is that the condition of failure should rest on a skill in which the user has invested pride. Certain failures the user will endure, others he will not. For example, in a fighting game, navigating a maze is not a skill in which the user has invested pride. All of the user’s focus has been on quick reactions, chaining combos and timing blocks – this is where his pride is and where he expects challenges. Navigating a maze of precarious ledges that leads, often, to death will quickly undermine the user’s enjoyment of the game.
Essentially, punishment comes down to a question of ‘fairness’. Fairness is arguably a subjective measure, yet experience shows that unfair design is universally recognizable.
8: Always explain how to fix failures
Nothing is more frustrating than failing a task and not knowing why. If a user is to learn from the experience and increase his chances of succeeding the next time, the cause of his failure must be clear. If time ran out – draw attention to the clock, if an ally died – display a message or an animation. By indicating the source of the failure, you should also be providing a hint for how to solve it. If a user continually fails, count the failures and provide progressively more leading clues. No designer will balance a game perfectly for every user so a dynamic system that naturally suggests the route to success should be a priority of every design.
9: Remain consistent to user expectations
The user is making a time investment in playing your game. Aside from learning the controls, the user must adapt to the whole paradigm of the game world you have created. As mentioned above, it is important to gradually introduce the user to the game world and teach him how to interact with it. Therefore it is of the utmost importance that the conventions you set are not broken later in the game. If your missile launcher destroys everything it hits, don’t expect the user to consider using it to activate a switch or, in a golfing game, if the object of driving is to set up the shortest possible putt, make sure that a short putt is actually easier to execute than a long putt.
The less the user has to think about how to interact, the deeper his immersion will be.
10:‘Dressing up’ cheapness will hide nothing
Never think that you can fool the user into replaying the same content without his noticing. Randomly ‘shuffling up’ or ‘re-skinning’ the same defeated challenges in a different sequence will not make them any fresher – it is the process that a user remembers, not the order or even the look.
Develop an engine, teach the user how to use it and then vary the objectives within the constraints of the engine. A fps that crosses a wide range of terrain themes but contains no gameplay beyond shooting advancing enemies and searching for ammo is significantly less compelling than one in which the user must use his wits to shoot his way out of a variety of unique situations.
Creativity is key, to take stock of your creative options, go to the lowest level of player-game interaction and devise puzzles around every nuance. Take shooting for example; you’ve got shooting for precision, shooting for quantity, shooting conservatively, shooting aggressively, shooting quickly, shooting in patterns – they all involve the same base mechanic but they vary the process and the experience.
This is not to say that replay is a lost cause. If it is presented as a reward, subtle variation of the same game experience is perfectly welcome – it’s a bonus so the user does not feel that the designers are cheating him.
11: Make the most important option the most accessible
This is another key step in making the game experience intuitive and immersive. If the action is common or important, give it a prominent button. If a menu option is used 80% of the time, list it first and start the cursor on it. If the user is most likely to attack, make that the default action. This principle should extend to every aspect of the game experience. The user should never have to undergo a sequence of actions or choices just to arrive at a single result. PC games have lots of keys; most other platforms are much less blessed and require greater creativity of design.
12:‘Fewer button presses’ is always good
There are actually two principles here under the same umbrella; reducing both excessive cycles of interaction and mindless repetitive, button-smashing controller abuse.
Planning for fewer presses:
Organize your interface so that the user makes the minimal number of button presses to perform an action. When possible, integrate effort-conserving mechanisms that can range from as simple as enabling the user to ‘press and hold’ to saving and predicting user decisions.
No more smashing and mashing:
Playing a game should be a mental experience – the controller is simply a conduit between the user and the game. The less strain placed on the controller, the more comfortable the experience will be for the user. Because it is something that requires no experience or practice, pressing a button rapidly ‘enough’ gives little satisfaction. The winning ‘strategy’ to a game should never be changing your hand position so that you can pound a button rapidly with your index finger. Besides, the last thing a game should do is give the user blisters.
13:‘Fewer buttons is even better
Adding extra keys is a tactic too often used by lazy designers. All but the most dedicated, self-righteous gamers will appreciate the low barrier of entry allowed by an intuitive and simple interface.
Each button introduced to the user is a further obstacle to immersion; it is a new ‘starting point’ that must be learned and absorbed before it can become intuitive. The multitude of interactive options intrinsic to your game should be accessed through creative use of existing buttons and not through new buttons (for example, consider jumping on an object of type X to create a ‘vortex’ attack, rather than a dedicated button or selecting ‘vortex’ from a list of potential actions).
The buttons on a controller or a keyboard have latent combinational potential. Consider what can be done with one button and creative timing: A, AA, A pause A – the list is rather limited. Now consider what can be done with two buttons: A, B, AB, BA, ABA, A+B, A pause A, A pause B, etc. The list is rather extensive and all of these combinational possibilities should be considered before adding a third button.
The human brain can more easily adapt new concepts to its existing paradigm than to redefine that paradigm. The task of the designer is to make the reuse of existing buttons intuitive. For example, a single button to cycle weapons and a second button to select a weapon and also to fire it, is much more intuitive than a system assigning each weapon to a different button. A user is actually more likely to memorize the number of button presses needed to access a desired weapon than to memorize the location of that weapon’s button on the keyboard/controller.
14: Make saving and resuming as accessible as possible
This one could be derived from other points on this list but it is too important to leave to extrapolation.
The entirety of the user’s dedication to your game is safeguarded by your saving system. Should that system fail, the user will likely curse your existence and quite possibly inflict irreparable damage upon his controller, console or computer.
It is surprising how many different ways there are to implement a simple save and load system. At the forefront of your development of this system should be a number of questions:
<!–[if !supportLists]–> 1. <!–[endif]–> Can the user move from gameplay to saving in under two seconds?
<!–[if !supportLists]–> 2. <!–[endif]–> If saving is automatic (‘checkpoint’ based) will the user be made aware?
<!–[if !supportLists]–> 3. <!–[endif]–> If the user fails and must revert, will his frustration level be acceptable?
<!–[if !supportLists]–> 4. <!–[endif]–> Will his reverted status be unchanged from when he saved?
<!–[if !supportLists]–> 5. <!–[endif]–> Is the user aware of when and where he can save?
<!–[if !supportLists]–> 6. <!–[endif]–> Is it difficult for a mildly emotional and irrational player to accidentally delete his game? (Damn you Banjo-Kazooie!)
<!–[if !supportLists]–> 7. <!–[endif]–> Are computer-selected reversion points intelligently selected? (Do they avoid surprising a returning/respawning user? Do they conceal imperfect state recreation?)
<!–[if !supportLists]–> 8. <!–[endif]–> Is it impossible for the user’s only save to be in a ‘stuck’ state? (out of fuel, one bar of life, etc)
All of the above questions should be answered ‘yes’.
15: A poorly designed feature is worse than a nonexistent feature
Users will notice bad design. It will rub them raw every time they play your game. They will complain about it. They will be reminded of it when they consider buying your next game.
Users will not notice nonexistent features. Perhaps, they will notice an indefinite ‘absence’ or a sense of incompletion, but, unless the game is unplayable, this is nothing they can specifically fault you for.
If you recognize that a game feature fails one of the preceding rules and it can’t be fixed, you should seriously consider removing it. Of course this does not mean that entire sections of the game should be canned because of poor design, rather a designer must locate the germ of the flaw and strategically effect its removal with the minimal amount of collateral damage.
As the designer, you are responsible for watching the project as it develops and safeguarding it from the insidious creep of bad design. Bad design has many sources; designer laziness, miscommunication with art or programming, feature juggling, delegating the supervision of implementation, and even ‘helpful’ rouge designers. Whatever the threats, there are two things to remember; one: the design is a wonderful and delicate creature that honorable designers must strive to protect; two: ignorance is no longer an excuse for failure.（Source：ventrice）