Difference between revisions of "Important Neuroscientific Considerations in Game Design for Autism"

From TACWiki
Jump to: navigation, search
(appended a link to Eitan Glinert's paper on accessibility)
(added a corollary on avoiding sequential logic in the UI)
Line 6: Line 6:
 
'''Do not depend on a player's memory for instructions; prompt the player every time.'''
 
'''Do not depend on a player's memory for instructions; prompt the player every time.'''
 
A corrollary of the executive planning problem is that the player may have trouble remembering a sequence of steps.  Even if (s)he has learnt in a tutorial that key A triggers action X and key B triggers action Y, these arbitrary associations might not be remembered, unless the player has had a chance to practise these actions actively, many times over.
 
A corrollary of the executive planning problem is that the player may have trouble remembering a sequence of steps.  Even if (s)he has learnt in a tutorial that key A triggers action X and key B triggers action Y, these arbitrary associations might not be remembered, unless the player has had a chance to practise these actions actively, many times over.
 +
 +
Another corollary of this memory problem: '''Do not make input-output mappings depend on the game state.'''  You might be tempted to hide functions inside submenus, access to which depends on the player's clicking on the right primary menu, or to make a drag of the mouse do something different after a click than after no click (or even worse, something different after a left-click than after a right-click).  Avoid such sequential logic in the user interface.  Wherever possible, use purely combinational logic.  Some sequential logic is of course unavoidable -- otherwise we wouldn't be able to have separate mini-games! -- but it ought to be used sparingly and only when absolutely required.
  
 
'''Instead of a sequence of actions, ask for one action at a time.'''
 
'''Instead of a sequence of actions, ask for one action at a time.'''

Revision as of 18:34, 4 August 2009

Neuroscientific Considerations in Game Design for Autism

Avoid timed events; give the player control of when things happen; whenever possible, prompt the player. People with autism have difficulty with executive function, that is, in rapidly planning and executing actions in response to sensory inputs. They have a great deal of skill and often exceed the performance of people without autism -- but it's a intensely studied and considered, deliberate style of skill, often not expressed under time pressure. So it's important to make certain that the timing of events is controlled not by the computer (except in cases where the experiment requires it) but by the player. Small additions such as a "next" button or a "ready" button can make all the difference. (An example of the event-driven rather than time-driven structure is the use of the up-arrow key to connect with the wormhole in the Maritime Defender mini-game.)

Do not depend on a player's memory for instructions; prompt the player every time. A corrollary of the executive planning problem is that the player may have trouble remembering a sequence of steps. Even if (s)he has learnt in a tutorial that key A triggers action X and key B triggers action Y, these arbitrary associations might not be remembered, unless the player has had a chance to practise these actions actively, many times over.

Another corollary of this memory problem: Do not make input-output mappings depend on the game state. You might be tempted to hide functions inside submenus, access to which depends on the player's clicking on the right primary menu, or to make a drag of the mouse do something different after a click than after no click (or even worse, something different after a left-click than after a right-click). Avoid such sequential logic in the user interface. Wherever possible, use purely combinational logic. Some sequential logic is of course unavoidable -- otherwise we wouldn't be able to have separate mini-games! -- but it ought to be used sparingly and only when absolutely required.

Instead of a sequence of actions, ask for one action at a time. Rapid actions can be difficult enough by themselves, but when people with autism face the additional demand of performing several of these actions rapidly and in the proper sequence thay can feel very much overwhelmed. (See the previous entries on executive function and memory.) Instead of requiring sequences of inputs in response to a single prompt, try to prompt separately for each input.

Use pictures, not words. Most people with autism tend to think in pictures rather than words. Instructions presented as text might not be comprehended -- not because the player is incapable of comprehending but because (s)he's concentrating so much on decoding the individual words that (s)he can't spare much effort to put those words together into the meanings of complete sentences and narratives. Sometimes text is unavoidable; if text is used, avoid verbosity and don't clutter the display with words. Reading can be slow; see the entry on timed events above about waiting and prompting the player to continue.

Players should learn by doing, not just by observing or reading or listening. In this regard, people with autism are no different from people without autism: we all learn best when we can be active rather than passive learners. The challenges faced by people with autism make it even more crucial that game activities involve learning-by-doing, rather than depending on learning-by-reading or learning-by-listening. This is particularly true of the game tutorials.

Avoid depending on simultaneous or near-simultaneous events in different perceptual channels (e.g. different places on the screen, or different senses such as video with audio). People with autism focus intensely and exclusively on one perceptual channel at a time. When focusing on one point or area of the display, events away from this spatial focus of attention may not register. Anathema for a person with autism would be a cockpit display with many gauges indicating different quantities which all need to be observed simultaneously -- or a visual display that needs to be observed at the same time as a spoken or other auditory signal. (Background music is okay because it doesn't need to be attended; players can just let it go on whilst they focus on the visual display.) Instead, either information should be displayed in one region of the display or one sensory channel, or ample time should be allowed to shift attention between points in visual space or between sensory channels. Shifts of attention can take 2 to 3 seconds for people with autism, whereas people without autism take 0.2 to 0.3 seconds. Think about what it would be like to be looking at the display through a long telescope that magnifies a small area but shuts out the periphery.

Avoid evoking unnecessary anxiety. People with autism are much more prone to anxiety than people without autism -- especially when faced with a new and unpractised task, or with a timed task, or with an interactive situation that's out of their control. (See entries above on avoiding timed events and giving prompting, pictures, and practice.) Do everything possible to make certain that the player, not the computer, is the one controlling what happens next, and that the player has every opportunity to practise and to become comfortable with the demands of the game.

For repeating events, vary the timing slightly so that the time between two successive instances of the event is not constant. This consideration actually isn't about accommodating people with autism; rather, it's about accommodating EEG analysis. Those of you who know something about signal processing will be familiar with the phenomenon of aliasing in which a discrete sampling of a high-frequency signal at too low a sampling rate produces an artefactual low-frequency oscillation. The problem here has a lot in common with aliasing. Consider as an example the situation that exists when the firing button is pressed and held: the weapons will fire at a certain rate, say, once every 500 ms. Suppose that we're interested in the brain response to the combined auditory and visual effects associated with weapons firing. Suppose also, though, that there is an ongoing, endogenous (that is, internally driven) 10 hz oscillation in the player's brain that has nothing to do with these exogenous stimuli. Since 500 ms is an integral multiple of the 100 ms period of this oscillation, when we sample the exogenous brain response to each weapons firing we're going to end up also sampling the endogenous oscillation at the same point in its phase every time, and we will thus misattribute the endogenous signal as an exogenous response to the weapons firing. To forestall this ambiguity in EEG analysis, we can add a small amount of temporal jitter to the intervals between firings - not so much as to make them seem unnaturally jittery to the player, but enough to get rid of this phase artefact. The exact amount depends on what seems natural given the event separation; in this example of a 500 ms event we might deem that any variation more than 10% of the interval in either direction would seem unnatural, so we might then choose to vary the intervals over a uniform distribution from 450 ms to 550 ms. Given the frequencies of the signals in which we're interested, it isn't ever necessary to add more than 150 ms (that is, 75 ms in either direction) of temporal jitter. Add as much temporal jitter as you can, up to this 150 ms limit - but don't sacrifice playability.

Log event codes for everything - absolutely everything. This is another consideration for EEG analysis. Did the weapons just fire (even though the firing key is being held down constantly)? That's an event. Did some sort of motion start or stop or change speed? That's an event. Absolutely everything that happens in the game should be reported with an event code. (See "Game/Engine/Logger.cs".) We can always ignore event codes if we decide that they aren't of interest in our analysis. What we can't do is go back and insert event codes after the data have been recorded. So put everything in.

SEE ALSO

http://www.gamasutra.com/view/feature/3538/designing_games_that_are_.php

"Designing Games that are Accessible to Everyone" by Eitan Glinert