informa
14 min read
Features

Unified Design of Universally Accessible Games (Say What?)

In a follow-up to The Theory of Parallel Game Universes, Dimitris Grammenos and Anthony Savidis detail their twice-practiced design theories behind Universally Accessible Games - games that can be played simultaneously by all players, regardless of physical handicap.

Introduction

Until now, little attention has been paid to the development of computer games that can be potentially played by all gamers, independently of their individual characteristics, requirements, preferences and abilities. In particular, there are no computer games that can be concurrently played among able and disabled people, either remotely or sharing the same computer, with the minor exception of a few games that can be played both by visually impaired and sighted players, like All inPlay card games and the 3D shooter Terraformers.

From a technical point of view, two main approaches have been adopted to address the issue of computer game accessibility:

  • Inaccessible games become operationally accessible through the use of third-party assistive technologies, such as screen readers, mouse emulators, or special input devices. In practice there are serious barriers and bottlenecks inherent in the absence of compatibility efforts during the development of computer games and assistive technology systems. However, even when some sort of compatibility is achieved, this is typically the result of either customized low-level adaptations (hacking) or pure coincidence, rather than the outcome of appropriate design considerations.
  • Accessible games are developed from scratch, however, targeted merely to people with a particular disability, such as audio-based games for blind people, and single-switch games for people with severe motor impairments on the upper limbs.

Following the first approach we typically accomplish a very limited form of accessibility, as well as poor interaction quality and usability. Through the second approach, being the most promising, we have to cope with two key drawbacks: (a) there is a significant tradeoff between the cost of developing high quality accessible games and the expected return on investment, assuming the target user group reflects a limited market population; and (b) there is an apparent hazard due to the potential segregation between able and disabled gamers, essentially leading to social exclusion.

In order to overcome the limitations of existing approaches towards game accessibility, the Human–Computer Interaction Laboratory of ICS-FORTH has introduced the concept of Universally Accessible Games, - UA-Games (Grammenos, Savidis, Stephanidis, 2005) - as an effective technical approach to achieve game accessibility coupled with high interaction quality, also putting forward the objective of creating games that are concurrently accessible to people with diverse abilities.

UA-Games are interactive computer games that:

  • Follow the principles of Design for All, being proactively designed to optimally fit and dynamically adapt to different individual gamer characteristics without the need of further adjustments via additional developments.
  • Can be concurrently played among people with different abilities, ideally also while sharing the same computer.
  • May be played on various hardware and software platforms, and within alternative environments of use, utilizing the currently available devices, while appropriately interoperating with assistive technology add-ons.

UA-Games support the right of all people for equal opportunities in social interaction motivated by playing, putting forward inclusive entertainment as a key quality of an inclusive Information Society.

At present, in the context of the UA-Games research activity of the HCI Lab of ICS–FORTH, two games have been developed:

  • UA–Chess: a universally accessible web–based chess.
  • Access Invaders: a universally accessible multiplayer / multiplatform version of Space Invaders.

The Design Process

A key prerequisite to effectively accommodate the particularly broad spectrum of diverse interaction requirements imposed by UA-Games is to firstly design the interactive game space at an abstract level, in a representation-independent way, eliminating all references to the physical-level of interaction (e.g. input / output devices, rendering, low-level dialogue). Once this is accomplished, the next step is to appropriately capture the lower-level design details, incrementally specializing towards the physical level of interaction by addressing particular user characteristics.

To this end, a design approach capable to represent an open set of alternative physical designs under a common abstract design umbrella is the Unified Design method (Savidis & Stephanidis, 2004). This method reflects a process-oriented discipline emphasizing abstract task definition with incremental polymorphic physical specialization.

The basic steps in applying Unified Design to the development of UA-Games are summarised in Figure 1 (below). As shown, Unified Design is a highly participatory, user-centred, iterative process, since:

  • throughout the overall lifecycle, the direct involvement of several representative end-users (gamers) with diverse characteristics, as well as domain experts (usability, accessibility, gaming, etc.) is promoted for the continuous assessment of the design outcomes in each step;
  • it is possible to return to a previous design step, in case, for instance, more information is required, some design artifacts have to be revisited, or the design parameters must be further specialized.
01.gif
Figure 1 : The basic steps for applying Unified Design to the development of UA-Games

Quite often, in order to evaluate the decisions made at a specific step, or to weigh alternatives before committing to them, it is required to quickly create small-scale temporary prototypes, known as “throwaway” prototypes. These may range from rough hand-made sketches to simple programs. Prototyping is an essential part of the iterative design process since it provides a low cost, tangible means for gathering early and meaningful user feedback, and, at a later stage, can also serve as a common reference point, as well as a concrete, unambiguous, documentation medium for communicating design specifications to game programmers.

At this point, it should be noted that game programmers are also involved in the whole process with a two-fold role: (a) they provide input about technical requirements and restrictions, as well as about the feasibility and cost of alternative design solutions, and (b) they develop and “tweak” the required electronic prototypes.


Step One: Abstract Task-Based Game Design

The goal of this first step is to break down the high-level tasks performed by people when playing the particular game – irrespectively of the medium they use to play it – as well as the things they do, the things they act on and the things they need to know. In this context, it is essential to focus on the basic logical game activities and constituents identifying their semantic attributes and relevant regulations independently of the way these can be physically instantiated to be accessible or usable to particular user groups.

02.gif
Figure 2: Abstract task decomposition for the game of chess

As an indicative example, the result of the decomposition for the game of chess is illustrated in Figure 2, where tasks are divided in two broad categories:

  • game-play tasks, comprising user actions directly related to the game goal and content (i.e., the board and the pieces);
  • game-control tasks, which include “peripheral” user actions that affect the game state and the way that player-game interaction is performed.

Step Two: Polymorphic Specialization with Design Alternatives

In this step, the abstract tasks resulting from the previous step are mapped to multiple low-level, physical alternative interactive designs, meeting target user attributes. In this context, accessibility barriers that can possibly emerge in each task when performed by a particular user group are identified and suitable alternative interaction methods and modalities are selected. An example of how the abstract task entitled “Select piece” (from the example illustrated in Figure 2) can be mapped to alternative low-level, physical, alternative interactive designs is presented in Figure 3.

03.gif

Figure 3 : Example of mapping abstract tasks to alternative interactive designs

Step Three: Appropriateness Analysis for the Design Alternatives

A matrix is constructed correlating the perceived appropriateness of each selected design alternative for every user attribute. The rows of the matrix represent distinct user attributes while its columns show game design alternatives. Each cell, depending on the suitability of the particular design for the specific user attribute, is filled with one of the symbols depicted in Table 1.

The alternative interactive designs appropriateness matrix can be filled in by reviewing related literature, using previous know-how in the field, as well as by questioning domain experts and representatives of the target user groups.

Symbol

Meaning

ideal.gif (ideal)

Explicitly designed for this user attribute.

appropriate.gif (appropriate)

Suitable, but possibly not the best choice.

couldbeused.gif (could be used)

If nothing else is available, it can be used, though not recommended.

inappropriate.gif (inappropriate)

Totally inappropriate, will result in posing an accessibility barrier.

neutral.gif (neutral)

Does not have any effect on the particular user attribute.

Table 1 : Alternative interactive designs appropriateness symbols

A basic design goal of UA-Games is that for every abstract task, there is at least one “ideal” or “appropriate” input and output design alternative for each user attribute and target user profile. A user profile is a collection of user attributes (e.g., novice, sighted, hand-motor impaired gamer). The appropriateness of a design alternative for a specific user profile can be inferred by merging the corresponding rows of the matrix that contain attributes of this profile, as follows:

04.gif

Figure 4 : Example of appropriateness matrix for the design alternatives

If the design alternative is inappropriate ( inappropriate.gif )for any of the user attributes, then it is deemed as inappropriate for the entire profile.

If the design alternative is neutral ( neutral.gif ) for a specific user attribute, it means that it is not related to this attribute and thus it does not affect the design’s appropriateness for it.

In all the other cases (i.e., ideal, appropriate, could be used), the lowest appropriateness value supersedes all the others.

Thus, for example, Figure 5 illustrates the appropriateness matrix for the case of a low vision, novice player that can use just a single switch. As can be seen, this is a particularly difficult case, since the available solutions are very limited and not optimal. Nevertheless, it can still be ensured that the game is accessible in this case.

05.gif

Figure 5 : Appropriateness matrix for a low vision, novice player that can use just a single switch

Step Four: Compatibility Analysis Among Design Alternatives

When alternative interactive designs have been identified, it is essential that cases where two or more alternatives are mutually incompatible are pinpointed, so that they can be avoided. To this purpose several related compatibility matrices need to be devised. A compatibility matrix has as rows and columns all the alternative interactive designs that can potentially be concurrently active at a particular point in time. If two designs are compatible then the corresponding cell is filled with a green tick ( ideal.gif ), else with a red X ( inappropriate.gif ). Figure 6 presents a compatibility matrix created for the alternative input designs of the example presented in Figure 4.

06.gif
Figure 6 : Example of a compatibility matrix for the alternative input designs of Figure 3

Step Five: Prototyping, usability and accessibility evaluation

As soon as a “stable” version of the whole (or just a discrete part of) game design is available, indicative electronic prototypes of the game can be developed showcasing the alternative interactive properties of its user interface for the different target user groups. The usability and accessibility of these prototypes should definitely be evaluated with representative end-users. In this respect, a quick, handy and very effective informal evaluation method is thinking aloud (Nielsen, 1993).

According to this method, an evaluator (or sometimes even more) observes a gamer interacting with the system, asking for vocalisation of thoughts, opinions and feelings, in order to understand the gamer’ s mental model, the way she thinks and performs tasks and find out any mismatches between the user’s mental model and the system model. Conversations are usually recorded so that they can be analysed later on. Furthermore, to support the evaluation process, a list of indicative tasks is used, that prompts participants to explore the full game functionality available.

After playing the game, a small debriefing session can be held, where participants are asked about their overall impression of their interaction with game and personal preferences, likes or dislikes, as well as for suggestions regarding potential improvement and modifications.

The outcomes of this step can considerably aid in validating, correcting and updating design decisions, as well as in developing new ideas for improving the accessibility and playability of the final game.

When the design specification is considered as “mature,” it can then be propagated for further development. Of course, as parts of the game and its functionality are being developed, it is highly desirable to regularly perform usability and accessibility testing.

Abstract Task-Based Game Design and Action Games

A basic design differentiation between a turn-based board game, such as chess that was used as an example up to now, and action games is the “degrees of freedom” along which the game can be modified in order to become accessible (see Figure 7). More specifically, in the case of board games, only the user interface (i.e., the way the game is presented and controlled) can be adapted to better match a particular player’s characteristics.

The game’s rules (logic) and content are fixed and any deviations are not possible. Then again, action games are more flexible in this dimension, since they usually have a main goal, but they do not impose restrictions on how this can be achieved and do not have any globally established strict rules and specific content.

07.gif
Figure 7 : Game adaptation dimensions towards accessibility

To provide an illustrative example, when making a chess game accessible, the possible adaptations can only affect how the board and pieces are rendered and the way the player can select and move the pieces. The type or number of the pieces, the rules they follow for moving, or what a player has to do to win can not be changed (since this would be a different game).

On the contrary, when creating an accessible version of Space Invaders, beyond changing how the player’s spaceship is controlled and presented, it is possible to completely revamp the characteristics of the attacking alien ships (e.g., number, speed, firepower, size) and even the rules of the game (e.g., allow the player to destroy any alien, but only a specific alien to destroy the player, change the initial number of the player’s “lives”).

Thus, a key difference in relation to the aforementioned design example of the chess game is that, at the stage of identifying accessibility barriers related to the game’s interface, barriers that stem from the game’s content and rules should also be identified, as well as possible design strategies for overcoming them. In this respect, the abstract task decomposition of a Space Invaders type of game is illustrated in Figure 8. This time, tasks are divided in three – instead of two – categories:

  • game-play tasks, comprising user actions directly related to the game content;
  • game-control tasks, which include “peripheral” user actions that affect the game state and the way that player-game interaction is performed;
  • game-logic tasks, which are performed by the system in order to create and control the various active game elements.
08.gif
Figure 8 : Abstract task decomposition of a “Space Invaders” type of game

Conclusion

The design of UA-Games is an inherently demanding and challenging task, requiring the management of a very large design space which, even when the game design as such is mostly completed, may still grow dynamically as new diverse user groups or varying environments of use are accommodated in the design process. Additionally, it entails the mapping and transformation of design parameters to coherent, highly usable and accessible interaction designs.

So, it is quite probable that – if you managed to read all the way to this point – you may feel a little overwhelmed by the formality of both the design process presented above and the language used to describe it.

But, if you have the courage to briefly review one more time the overall process, conceptualising in your mind each step by using a specific game as a concrete example, then (hopefully!) you will realise that it is not as complex, or tough as it seems on the first sight. Take our word for it, we already did it twice!

References

Grammenos, D., Savidis, A., Stephanidis C. (2005). UA-Chess: A Universally Accessible Board Game. In Proceedings of the 3rd International Conference on Universal Access in Human-Computer Interaction. G. Salvendy (ed.). Las Vegas, Nevada, USA, July 2005. Lawrence Erlbaum

Nielsen, J. 1993. Usability Engineering. Academic Press Inc.

Savidis, A., & Stephanidis, C. 2004. Unified User Interface Design: Designing Universally Accessible Interactions. International Journal of Interacting with Computers, Elsevier, Issue 16, 243-270

Latest Jobs

Treyarch

Playa Vista, California
6.20.22
Audio Engineer

Digital Extremes

London, Ontario, Canada
6.20.22
Communications Director

High Moon Studios

Carlsbad, California
6.20.22
Senior Producer

Build a Rocket Boy Games

Edinburgh, Scotland
6.20.22
Lead UI Programmer
More Jobs   

CONNECT WITH US

Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter

@gamedevdotcom

Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Register
Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Subscribe
Follow us

@gamedevdotcom

Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more