To print these notes, use the PDF version.

Games are one of the more interesting and difficult software design/implementation problems, and their development frequently pushes the limits of hardware and software creation capabilities. This may have been especially obvious towards the latter half of 6.170, when you made Gizmoball or Antichess

But how can you make sure everyone can play your games? There are many disabled groups that can't play many games:

Visual impairments - not just blind, but color blind, extreme myopia, tunnel vision, night blindness

Motor impairments - arthritis, missing fingers/hands, neural-motor diseases like Multiple Sclerosis or Cerebral Palsy

Hearing impairments - deaf, hard of hearing

Mental impairments

Technological impairments

All of these impairments can prevent users from playing games.

To give you an idea of roughly how many people disabilities affect here are the statistics from the 2000 US Census. 18.5% of the population 5 and up is an enormous number! Now granted, a lot of the distribution is top heavy and affects the older part of the population, and some disabilities might not seriously affect one's ability to play all games, but you still get an idea for the size of the group we're talking about. And keep in mind that gaming demographics in general are shifting to the older populations as games get more ubiquitous.

There's a lot of motivation for making games (and software) accessible to these groups. One of the main reasons is due to functional impairments. This is when a user becomes functionally disabled due to the environment. For example, if I am playing a game outside in bright sunlight, or on a tiny cell phone screen in an environment where I can't hold it stead (like a bus), I am functionally blind and cannot rely on the screen alone for feedback.

Accessibility focuses on output and input, so let's take a look at each one and how they can be adapted to make games accessible.

On the input side, controls should be designed like any good UI - as simple as possible, without over simplifying. An example of this distinction can be seen by comparing Super Mario Bros and Sonic the Hedgehog. In Mario the user needs to hold two buttons to run and a third to jump while running, which many players find difficult since they only have two thumbs. Sonic, on the other hand, only requires one button to run and a second to jump, making it much more accessible. Sonic actually goes a step further in allowing the user to push any button to jump.

Another approach is to allow for multiple input schemes. One way to do this is with partial AI control of certain non-critical features. EA is pioneering a lot of this work with a setting they call "Family Play", and can be seen in games like the new iterations of Madden football. Normally players need to use both hands to control two devices to play the game, giving them a fine level of control. In Family Play, users only need to use one device to play the game and partial AI fills in the parts they don't control. This scheme sacrifices some of the user's control, but it opens the game up to new groups

Sometimes it isn’t realistic to have computer controlled assistance in a game due to programming time and resource constraints. Another good solution is to decouple the input controls from the game entirely. Doing so allows you to have multiple control schemes which allow different people to play in different ways — here, Marble Madness (left) has mouse and joystick controls, and AudiOdyssey (right) has keyboard and Wiimote controls. An added benefit of decoupled inputs is that individuals who use special accessible hardware devices can map their own control schemes.

On the output side it is critical to have redundant feedback. Normally humans are used to this - it's rare and jarring to only see something without hearing it, and vice versa (for example, think how strange it feels when at a baseball game you see the player hit the ball, but only hear the "crack" a split second later). The best games try to use all the channels available and strive to have matching audio and visual cues for most, if not all of the feedback events. Haptic feedback like vibrating controllers can add a third layer of output feedback. Half Life 2 does a good example of using redundant channels - rather than just listening to what the characters in the game say, users have the option to close caption the game. In addition to making the game more accessible to visually impaired this feature increases usability across the table by increasing memorability.

A great example of a game that wraps all these lessons together is UA (Universally Accessible) Chess by Dimitris Grammenos. The game uses the MVC model we studied in class, and has several interchangeable views and controllers which work well for the visually impaired, motor imparied, and technologically impaired. Obviously not all games can be handled this way, but it shows how a thoughtful design process can lead to a highly usable game.

So the takeaway lesson here is that accessibility is an important part of game design, since in doing so usability is increased for all groups. Simple and adjustable control schemes and redundant feedback help achieve this goal.

Here are some additional resources if you are interested in more on the topic

Dr. Grammenos’ work: http://www.ics.forth.gr/hci/ua-games/games.html

Game Accessibility Source: http://www.game-accessibility.com/

Dr. Eelke Folmer, Game Accessibility: http://www.eelke.com/

Education Arcade (here at MIT) http://www.educationarcade.org