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.