Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Designing Usable and Accessible Games with Interaction Design Patterns
Why are some games inaccessible to the mass market? This in-depth Gamasutra design piece references intelligent fixes that stop frustration and encourage smooth, fun play for titles ranging from God Of War II to Dungeon Siege.
30 Min Read
What separates games from other forms of entertainment is that they provide interaction, however providing interaction it in the wrong way e.g. different from how the player would expect it or how the player requires it, means that people get frustrated playing your game --or worse-- cannot play your game at all.
More and more people are interested in playing games who do not fit the profile of the “20 year old male” that the game industry predominately seems to target. Playing a first person shooter on a console requires you to master two analog thumbsticks, four buttons and a number of triggers and or combinations of these. Not everyone is capable of doing this easily, such as the elderly, while those who have never played games before, such as people with disabilities, all face an increasingly complicated game interaction that withholds or restricts them from playing games in the first place.
Games are different from traditional software systems in the sense that most software systems are designed with the purpose to either completely automate a user’s task (such as ATM software) making the user obsolete, or to support a user in performing a task, such as a word processor helping someone write a letter. Games are different in that respect as they are solely developed for entertainment or educational purposes.
Interaction design affects two game qualities:
Usability: if a player cannot figure out how to play the game, if the player has to wait, if it is difficult to learn to play the game or if game objects are awkward to use.
Accessibility: if a player cannot understand what is said in cut scenes or cannot hear the footsteps of someone sneaking up behind him or her, because the player suffers from an auditory disability or if the game does not support the use of specific input devices such as one handed controllers or sip and puff joysticks that allow severely physical disabled players to play the game.
Usability and accessibility are two different but strongly related qualities. Accessibility problems can be considered to be usability problems for particular group of players e.g. those with disabilities. Unable to understand what is said in audio only cut scenes is an accessibility problem for someone unable to hear, but it is a usability problem for someone playing a handheld in a noisy environment without headphones.
This paper will argue that many usability-improving solutions in games can be beneficial for players with disabilities and the other way around. Game accessibility & usability should not be confused with gameplay. Gameplay focuses on providing interaction in such a way that it is fun. For example, moving a paddle to reflect the ball in Pong. Usability and accessibility however, deals with providing this interaction in such a way as the player would expect it, e.g. go up with the joystick to make the paddle go up rather than some exotic combination of joysticks movements.
2. Usability & Accessibility problems in Games
Let's look at some common usability & accessibility problems that we found, we organized our specific problems into five problem categories.
Player has to wait
The player has to watch a cut scene that he or she has already seen before and cannot skip through it (same problem occurs with replays).
The player has to wait a long time for something to complete (e.g. creating a building in a RTS).
The player has to make a lot of decisions before they can start playing the game, (e.g. in a RPG first a character needs to be made and configured).
The player made a mistake and has to wait for a level or save game to load.
Player makes errors
The player gets killed repeatedly (e.g. fighting an impossible to beat end level boss) either because of inexperience or a disability.
Player forgets to make a save game and has to play from an earlier save game.
The player needs to successfully perform a series of actions in a short period of time and fails repeatedly (e.g. push button to open door, jump over pit, fight enemies, roll under door).
Game does not adapt to the player
A deaf player or a player using a handheld console in a noisy environment cannot understand the cut scene because of lack of subtitles.
Player is used to particular button configuration or a physically disabled player needs to use a specialized input device (one handed controller or a sip and puff device), which requires a different button configuration and players are unable to change this in the game.
Player finds it hard to do certain things in the game such as aiming in a first person shooter either because of lack of experience or because of a disability.
Game does not provide help
Player wants to try out new weapons/vehicles/game objects but is hesitant to do so because it might negatively affect its current character/environment.
Player needs instruction on how to use a certain game object but doesn’t want to look in the manual all the time.
In order to play the game, the player needs to know information (e.g. for example the location of an artifact, in order to solve a quest). This information is provided during the game but is not readily recallable at any moment. Player needs to go back to the part of the game where this information is given.
Game does not provide feedback
Player wants to know how much longer he has to play before finishing the game, but is unable to find out.
Player did something spectacular but has no time to enjoy it as the game goes on immediately.
Problems are contextual
One important observation is that these problems are typically contextual; a usability problem where the player has to watch a cut scene over and over again only occurs in games that have cut scenes. Forgetting to make a save game only occurs with games that allow storing game progress. Being overwhelmed with information is probably not a problem for games that give little feedback such as Tetris.
Accessibility problems are also highly contextual as they strongly depend on the type of disability the player suffers from e.g. lack of closed captions might not be a problem for a physical disabled player and most deaf players can use regular controllers instead of specialized controllers.
Solutions can be found in existing games
Fortunately, some game developers recognize these problems during development and as a result solutions to such usability and accessibility problems can be found in existing games. For example, when a player has to wait for a Flash game to load because the Flash file is large or the player suffers from a low bandwidth connection, the game can offer up a small mini game while the player waits. The player still has to wait but at least he can do something in the meantime.
The original Half Life was criticized for not offering subtitles, something Valve studios was not aware off during the development. Since then Valve has closely worked together with the deaf gamers community. Half Life 2 features subtitles that allow a deaf player to understand what is said in dialogues. An even better solution is to add closed captioning which allows a deaf player to hear ambient sounds such as gunfire or the footsteps of someone sneaking up from behind, which is exactly what is offered in Half Life 2 as an addition to subtitles.
Unfortunately not all games have these solutions; if applicable in their context, and as a result usability and --more commonly-- accessibility problems can be observed in games. A usability problem affects any player so most game developers make sure that their game has as few usability problems as possible, however the nature of game development often prevents thorough usability testing during the later stages to meet deadlines and ship products. Accessibility problems are more common.
There is little incentive for game developers to make games more accessible, the target population is small, developing games is very risky and costly and given the pressure of deadlines and shipping products, this leaves little room to experiment on what exactly would make a game accessible. There are no accessibility guidelines for games similar to the W3C web content guidelines that can guide developers into building accessible games.
Game designers need effective and usable tools based upon proven knowledge of design. If we can capture, what is considered the “art” of good game interaction design, and share this knowledge between designers, game interaction design can be made more accessible to inexperienced designers; minimizing the risk of building a game with usability or accessibility problems. If we look at particular usability/accessibility solutions in detail e.g. at the specific implementation, it will allow us to identify and describe the effort associated with implementing it.
This would help better inform design decisions with regard to making games more accessible or usable. If implementing closed captions is 3 weeks of programming effort for one programmer, does that outweigh being able to sell ~1.2 million more copies of your game (it is estimated that 3 million people in the US are unable to hear , and an estimated 40% of the people play games).
The problem is how can we describe such solutions so they become usable design tools for game developers?
3. Capturing design knowledge
Traditionally best practices concerning interface/interaction design have been captured by means of guidelines or heuristics such as Nielsen’s heuristics or the W3C web content accessibility guidelines. The purpose of guidelines is to capture design knowledge into concise small rules, which can be used to inform interface and interaction design.
Attempts to capture design knowledge have been made with regard to game interaction design. Houser & Deloach present seven principles for effective game design. Melissa Federoff has looked at how existing usability heuristics such as proposed by Nielsen apply to games and a set of 42 game heuristics is proposed. These guidelines specifically focus on usability issues and are different from attempts to describe game play such as Noah Falsteins 400 project.
Problems with heuristics
Guidelines are useful for requirements specification but if we look at their usability as a design tool some shortcomings have been identified by Welie with regard to selection, validity and applicability:
Guidelines often suggest a general absolute validity but in fact they can often only be applied in a specific context. For example Federoff specifies “The game should have an unexpected outcome” which makes sense and works for an adventure game but does not apply to arcade games such as pong.
It is often unclear what the problem is the guideline actually tries to solve and why. Federoff specifies “Players should be able to save games in different states” but it does not explain what usability problem it addresses and why the proposed solution would work and how it can be implemented.
Compacting design knowledge in small concise rules has the obvious problem that you end up with a lot of rules in order to describe everything. A large number of guidelines makes it hard for a game designer to select the right rules and worse the lack of context makes certain guidelines contradict with each other. For example, “The game should have an unexpected outcome” and “there should be a clear overriding goal of the game presented early” might possibly conflict.
Design tools should first and foremost be usable. We need to be able to tell the designer exactly when to apply the solution, how the solution works and why the solution works. A requirement specified as a feature such as “closed captions” is much easier understood and implemented by a developer than the abstract guideline “Provide a text equivalent for every non-text element” it embodies. The usability and accessibility problems that we have identified are contextual; I propose to use interaction design patterns for capturing design experience, as this offers a much richer description format and hence is more useful and usable as a design tool.
4. Interaction design Patterns
Patterns and pattern languages for describing patterns are ways to describe best practices, good designs, and capture experience in a way that it is possible for others to reuse this experience. Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. Usually a rationale is also provided. Patterns originated as an architectural concept by Christopher Alexander , but patterns in software became popular with the “Gang of four” design patterns book. Since then a pattern community has emerged that has specified patterns for all sorts of domains including interaction design.
Patterns have been used to describe knowledge about game design yet these have focused on describing game play and not on usability/accessibility solutions. In this article we propose to use interaction design patterns. An interaction design pattern describes a repeatable solution to a commonly occurring usability problem. The quintessential example used to illustrate an interaction design pattern is undo.
Name: undo Problem: User made a mistake and cannot revert this. Context: Any application where a user can manage information or create new artifacts such as word processors or graphical applications. Solution: Maintain a list of user actions and allow users to reverse selected actions. Why: users will explore more since they know mistakes can beundone, facilitating learning the application. |
Patterns and guidelines do not exclude each other; patterns describe one or more rules in a very specific situation (depth) making them more useful as design tools, whereas guidelines are more high level (breadth) and are useful as requirements.
Several pattern collections can be found online of which the Yahoo UI pattern collection is probably the most well known. Existing pattern collections focus on problems in web and user interfaces (UI) for general-purpose software, which makes them hard to use as tools for game design. Although certain patterns such as a wizard are applicable to games (e.g. an installation wizard), many others such as container navigation, calendar picker or form validation are typically not applicable to game design.
We identified that games exhibit some unique usability/accessibility problems, e.g. lack of closed captions or not being able to skip a cut scene is usually not a problem for web applications. As a result we decided to develop our own interaction design pattern collection that specifically addresses accessibility and usability problems in games. The next section gives three examples of patterns we identified in existing games.
5. Example patterns
Another benefit of using patterns to describe design knowledge is their consistent format. To increase the readability of our collection we use the following format:
Problem: problems are related to playing the game, which is either a usability and/or an accessibility problem.
Context: the context extends the plain problem-solutions dichotomy by describing specific situations or types of games in which the problems may occur.
Forces: within the context, a number of forces act, which need to be resolved.
Solution: a proven solution to the problem, which resolves the forces.
Why: the rationale provides a reasonable argumentation for the specified impact on aspects of usability when the pattern is applied.
Examples: Examples of how this pattern has successfully been implemented in a game.
We have currently identified 23 interaction design patterns, all of them may improve the usability of a game and 8 may improve accessibility. We give three example patterns: adaptive difficulty level, seamless gameworld and slow. Only three patterns are included but the reader of his paper is encouraged to visit the rest of our pattern collection on our website http://www.helpyouplay.com.
Adaptive difficulty level
Figure 1: adaptive difficulty level in God of War | |
Problem | Problem - Player gets killed/injured repeatedly because – Accessibility- the game is too hard to play on the current difficulty setting for someone with a disability e.g. cannot respond quickly or precisely position a pointer/crosshair (physical) or unable to deal with many events at the same time (physical /cognitive) Usability - the game is too hard to play for the player on the current difficulty setting. |
Use when | Games that offer different difficulty levels to cater for different types of players. The most common terms for levels of difficulty are easy, normal and hard. Depending on the difficulty level:
The player has to choose a difficulty level when starting the game, and usually it is not possible to switch to a different difficulty level halfway without starting over. |
Forces |
|
Solution | Adjust the difficulty level to the player. The game should adapt to different players during different parts of the game. There are two options for implementing this pattern:
|
Why | Accessibility - Adjusting the difficulty level to the disabled player may make it easier to play the game and the player may make less errors. The game will automatically determine the difficulty level the disabled player is comfortable with. Usability - Adjusting the difficulty level to the player may increase satisfaction and efficiency. Players will not become frustrated. |
Examples | God of War - This 3rd person action game suggests adjusting the difficulty level, if the player dies frequently in a short period of time e.g. 7 times in a row, a screen is presented which offers the option to switch to an easier difficulty level. Resident Evil 4 - This 3rd person shooter has 5 levels of difficulty. It automatically adjusts the difficulty level based on the player's performance. Sin Episodes - This first person shooter offers a very advanced dynamic difficulty system. It continuously monitors performance and will tailor enemies’ health ammo, armor and damage to a specific playing style. |
Seamless Game world
Figure 2: seamless game world in Dungeon Siege | |
Problem | Usability - Players need to wait before entering a (new) part of the game. |
Context | Typical to "free roaming" games e.g. 3rd person shooters, role-playing, action or simulation games with the ability to move around freely in a large world. These games usually have a nonlinear game plot (if any). Usually such a world is partitioned into zones as such a world cannot be loaded in whole in the memory. When a player moves from one zone to another (e.g. goes into a house) the player usually has to wait for the new zone to be loaded into the memory. |
Forces | • Players are impatient and do not want to wait. • Players do not want their game to be interrupted. |
Solution | Provide a seamless game world. Instead of letting the player wait before entering a new zone, pre-load the level before the player enters the zone. Rendering a huge seamless world may have a significant effect on the game engine design; an example implementation could be as follows: • The entire world is broken up into chunks (chunk size depending on available memory). • Only 9 chunks are loaded into memory at any given time, the chunk the player is currently in and the 8 surrounding chunks. • As the player moves out of the central chunk into one of the bordering chunks, the 3 chunks farthest from the player are discarded and the chunk the player just entered then becomes the center chunk. Then the 3 new chunks make the 3x3 grid are loaded. Some more detailed implementation issues (such as loading parts of chunks and dealing with hardware constraints) can be found in Bilas |
Why | Having a large, persistent world adds a level of constant immersion for the player, as the game never stops and never loads. This solution increases efficiency and satisfaction. |
Example | Dungeon Siege - This role playing game provides "content streaming" which eliminates the need for "level loading". World of Warcraft - This massive multiplayer online game provides a seamless world it connects a number of different places and makes them appear as if they all belong as parts of a whole. Loading times are as rare as they are brief. They only crop up when traveling across the game's enormous continents or entering some specific higher-level zones that are instanced for each player group. |
Slow
Figure 3: Slow in Max Payne | |
Problem | The player needs to successfully perform a series of actions in a short period of time, which is difficult. Accessibility problem - if the player suffers from a physical, cognitive or visual disability since they need more time to respond to multiple events at the same time. Usability problem- if the player is not experienced. |
Context | This is common to action games such as first person shooters or platform games. Achieving a certain goal (such as finishing a level) depends on successfully performing a series of actions. Sometimes this has to be done within a constrained period of time. For example, the player may push a button to open a door. The door closes in a certain amount of time. In order to go trough the door, the player may need to jump over a pit, defeat an enemy etc. Game designers put such 'challenges' in the game to pace the game and make it more exciting. For advanced players such a challenge may not be an obstacle but (novice) players may find it very hard to accomplish and the player often has to try several times before the player succeeds (if the player succeeds at all). |
Forces |
|
Solution | Solution - Allow the player to slow down the time. Throwing the world into slow motion while moving around in real-time gives several advantages.
Care must be taken that the world can only be slowed for a brief period of time as slowing it all the time can make the game too easy. In order to achieve this one can consider letting the player sacrifice something in order to activate slow. In the action game Prince of Persia slow is activated by means of tokens that can be collected during the game. At any given time there is only a limited amount of activation tokens available. This makes sure the player only uses slow sparsely. For disabled gamers this might not be an issue and they should be able to use slow whenever they feel the need to, it can also be automatically triggered when multiple enemies attack. The player however needs to be notified when slow is about to be enabled to minimize confusion. This mechanism is also known as bullet-time in first person shooters. |
Why | Accessibility - Throwing the world in slow motion will allow disabled players to make less errors because:
Usability - Slowing down the game makes will improve reliability and satisfaction as the player has more time to respond and will make less errors. |
Examples | Max Payne - One of the first game to introduce matrix style bullet-time (slow) in a first person shooter. The gameplay of Max Payne revolves heavily around bullet-time. When triggered, bullet-time slows down the passage of time to such an extent that the movements of bullets can be seen by the naked eye. The player, although his movement is also slowed, is still able to aim and react in real time, providing a unique advantage over enemies. Prince of Persia: Warrior Within - This platform/action/puzzle game allows the main character to slow time through the use of a dagger. The dagger contains "charges" of the Sands of Time from the hourglass that allow the Prince to "slow" time for a while. The usages of the dagger are limited. However, defeated enemies leave behind piles of the Sands of Time, which can be absorbed by the dagger to replenish its stock. This encourages the player to confront and vanquish enemies (as opposed to avoiding them) in order to replenish the power to manipulate time during the more tricky acrobatic sections of the game. Blinx: The Time Sweeper - This third person platform game offers time control which allows one to control the flow of time e.g. slowing, speeding up, reversing or stopping its flow entirely. |
6. Designing with patterns
There are several ways to use our collection of patterns. For now we have organized our patterns into two collections, one focusing on usability and the other on accessibility, but as future work we also intend to also organize them by game genre and by the amount of implementation effort required for implementing them.
Designing for usability
We have organized our patterns to the player problem categories when identifying usability problems in games discussed in section 2. Some of these categories match with some of Nielsen’s heuristics. Certain patterns such as slow fit in two categories.
Game designers can take our 5 categories as requirements and then heuristically evaluate each pattern in the category and decide whether it should be implemented or not. This can be during the early stages of design or during the later stages of development.
|
|
However, during the later stages it may become to expensive to implement a particular pattern. Though a game designer is probably in a good position to estimate the implementation effort associated with each pattern, we do think it is valuable, to provide inexperienced game designers with some global outline of an effort estimation.
For example, skippable cutscenes is probably easy to implement. A seamless gameworld poses some severe constraints on the underlying architecture, preventing it from being implemented cost effectively during later stages. By discussing, during requirements analysis, how a pattern could improve usability and what is required from the system, the mutual awareness of the restrictions that exist between software engineering and usability can be raised.
Designing for accessibility
For accessibility we have organized the patterns to each different disability. In general 4 different disabilities have been recognized:
Visually disabled – blindness, low vision, and color blindness.
Auditory disabled – deaf or hard hearing.
Physically disabled - paralysis, neurological disorders, Repetitive Strain Injury (RSI) and age related issues.
Cognitive disabled – learning disabilities such as dyslexia, dyspraxia, autism and attention deficit disorder.
|
|
Making your game accessible to players with auditory disabilities is probably the easiest since closed captions can be implemented with little implementation effort. Making your game accessible to blind people is probably the most challenging, yet people with low vision could already benefit from simple mechanisms such automatically facing an enemy in a first person shooter (interaction aids). Again the game designer can iterate over the patterns and analyze whether some of these should be considered.
7. Discussion
The question remains how detailed or elaborated ID patterns for games need to be. Experienced game designers may find most patterns trivial and dismiss them. For beginners they might prove useful. The issue of detailedness of a pattern is a general ‘problem’ in design pattern research. Nonetheless, we feel that the level of detailedness we show in our patterns allows the patterns to be useful for both UI designer and software engineers while not being too detailed.
Sometimes it’s hard to describe a pattern without having to make some basic assumptions about an underlying mechanism. When describing our auto save pattern we found it very difficult to describe it without actually specifying something about “saving” in general. In our pattern description we assume players can save games but why is this? Is saving a usability feature or is this pure functionality? In the case of word processors one cannot imagine a system without the ability to save but for certain games this very well possible (such as beat'em up games).
When we started this collection we initially focused on identifying patterns that are “unique” to the games domain. This is very hard as certain patterns that we identified such as autosave, and visual saves are also found in desktop software. The preview pattern is related to our visual saves pattern.
It can be argued that visual saves is a domain specific implementation of this generic pattern. For the completeness of our collection we decided to include this pattern even if it is a child of a more generic pattern. It is not our purpose to translate generic patterns to game specific patterns as patterns should be defined as domain independent as possible.
8. Conclusions
Interaction design for games is difficult and often relies upon years of experience. Interaction design patterns can capture the best practices of game interaction design in a much richer format than game heuristics and are hence more usable as tools for designers. Existing interaction design pattern collections focus on web and user interfaces for general purpose software, which makes them hard to apply to game design. We have developed a collection of interaction design patterns that describe solutions to typical usability and accessibility problems in games. Our patterns have been harvested from existing games.
The format and scope of our patterns can contribute to the development of a larger number of patterns than that we have now.
Such a body of knowledge may then effectively be used to inform interaction design for games; it may aid communication during early design, leading to games with fewer usability and accessibility problems, and potentially leading to increasing sales.
Read more about:
FeaturesAbout the Author(s)
You May Also Like
