Important Neuroscientific Considerations in Game Design for Autism

Neuroscientific Considerations in Game Design for Autism

If there's a way to use a game feature as an object of repetitive behaviour, a player with autism will find it.. Players with autism often find predictable sensory contingencies more rewarding than unpredictable, surprising events. So whereas non-autistic players could be expected to self-motivate to 'level up' or in general to proceed through the game narrative, autistic players often are more content to keep on repeating the same feature, or causing the game to produce the same sound or visual effect. These purely sensory effects can be much more salient and motivating to a person with autism than the less tangible and immediate, more abstract and future-oriented effect of, say, a game score or a power-up. So, for instance, an autistic player might become fascinated with the sound effect that takes place when their avatar is destroyed, and therefore keep 'dying' on purpose, just to hear the sound effect - clearly a strategy that thwarts the intended game mechanic! When designing and implementing a game, put yourself in the place of the player with autism, asking yourself, "What sensory aspects of this game could a person become fixated on?" Try to move the player through the game, nudging them away from such repetitive behaviours and into new experiences. At the same time, though, you can use limited, rationed opportunities for repetitive behaviour as a reward and a motivation for moving through the game - e.g. a game structure that allows a player ten (and only ten) repetitions of their favourite sound effect once they've done the hard work of reaching the next level.
In his memoir There's a Boy in Here, Sean Barron describes his own autistic fascination with repetition and predictability:
‘I loved repetition. Every time I turned on a light I knew what would happen. When I flipped the switch, the light went on. It gave me a wonderful feeling of security because it was the same each time…. Even when I knew, it was thrilling to do it over and over. It was always the same.'
‘People bothered me. I didn’t know what they were for or what they would do to me. They were not always the same and I had no security with them at all….'

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 corollary 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