Considering The One Who Needs More Time

Part One – Cycling Menu Choices For Single Button Players

This week, Jack wrote a blog for the Playability Initiative telling everyone why he hates timers in games. Players like Jack can find themselves artificially barred from the fun when a timer interferes with their play experience.

In a world where physical environments often exclude people who have limited mobility, video games have the potential to open up the fun to everyone. Design choices that do not consider the abilities of the user may needlessly create an impassable barrier. Design is all about who you consider. It is important for designers to ask questions like, “Who am I making this for? How do they interact with the world, and how can we make them comfortable?” As we design Painted Waters, we are asking ourselves these questions.

We have established a few key design constraints to ensure as many children with spinal muscular atrophy can play our game as possible. Our design constraints may change, but these are our current priorities.

A single button press or control switch controls gameplay
We never require the player to “press and hold” a button or control switch
We never require quick-response, repetitive button pressing (button smashing)
We never penalize the player for slow reaction times

Many games require the player to react quickly to the events on screen, and if instead the player reacts slowly, their reaction is flagged as a mistake. We aspire to create a game that is just as much fun for players with slower reaction times as it is for those who are able to respond quickly.

For Part One in this blog series, we will show you one style of cycling options for players that we are considering. We’ll be illustrating these principles using napkin sketch animations. In Part Two we’ll share how we’re adapting these principles to the design of levels and features in Painted Waters.

The One-Switch Player:

Some players are physically unable to use traditional gamepad or keyboard controls. These players may rely on buttons or levers that they control with their hand, mouth, or eyes. These controls are known as Switch Access.

An animated image portraying a cycling keyboard. The user waits for the orange outline to select the desired letter, and uses the switch to type out a message.

To accommodate this style of input, the game can present the player with a set of choices. The player can cycle through the choices, and activate their switch to select their desired choice. This process can take a long time, especially with a large number of choices. In the following examples, we’ll share some different cycling patterns we are considering when designing our game.

Example One: The Automatic Cycle

Visual example of automatic cycling. A frog is rotating between 3 plates of food, a bad banana, an apple, and a piece of cake. The frog rotates to face each plate of food at a rate of 2 seconds per plate. A timer displays for the user to know when they can tap. An orange button shows the user selecting the cake plate.

Automatic cycling means that between the three choices presented here, the banana, the apple, and the cake, the game will automatically rotate the frog to point at each choice after a given amount of time. When the frog points at the choice the player wants, they hit their switch to select the cake!

Pros to The Automatic Cycle:

This works very well for a limited set of choices.
The time between choices can be adjusted to suit each player’s needs.
It only requires one tap of a switch to select the desired choice.

Cons to The Automatic Cycle:

If a player misses their selection, they have to wait for their desired choice while the game cycles all the choices again.
More choices take much more time to cycle through.
If a player selects the wrong choice, there is no way to undo their selection.
Multiplayer games often put players with slower reaction time at a disadvantage against those who are able to react quickly using a different input method, or players whose physical response is more reliable.

Example Two: The Automatic Cycle with Increasing Time Between Choices

Visual example of automatic cycling with increasing time between choices. The same frog is rotating between the same set of plates. This time the visual timer waits longer, the longer the player waits. The first three cycles of plates are 1 second apart, the next cycle 2 seconds, the third 3 seconds, until the orange button is pressed, selecting the cake.

This Automatic cycling with increasing time between choices is almost identical to the previous method, with one variation. The longer the player waits, the slower the choices cycle.

Pros to The Automatic Cycle with Increasing Time Between Choices

This method provides a good balance between increasing efficiency, and lowering the risk of the player selecting a choice they don’t want. If a player wants to play fast, they can, or they can take their time to make sure they select the choice they want.

Cons to The Automatic Cycle with Increasing Time Between Choices

For players who want to play fast, they could grow frustrated by having to wait for a longer period of time whenever they miss their desired choice.

Example Three: The Manual Cycle with 2 switches

Visual example of manual cycle with 2 switches. Same frog, same plates. This time the orange button cycles which plate the frog is looking at, the yellow button selects the cake.

Manual cycling with 2 switches means that the player uses one switch to cycle between choices, and another switch to select their desired choice.

Pros to The Manual Cycle with 2 Switches:

The game can eliminate any time pressure placed on the player.
Selecting the wrong choice is unlikely, because the player selects the choice controls when the choices switch themselves.

Cons to The Manual Cycle with 2 Switches:

This method requires a player to press a switch once for every choice they cycle through and again for the selection. In a set of 5 choices, this can mean 6 or more switch activations. For players with decreased motor function this increased pressing can cause fatigue and discomfort.
This method requires 2 switches, which increases the need for players to both pay attention to the game, but also focus on moving their hand or finger to another switch. For players who experience difficulty moving their limbs, or with impairment in depth perception, this task can take longer to complete as well as cause increased fatigue.
The player’s game setup may only have one switch, or the player may only be able to use a single switch reliably. This method would exclude all players who do not have access to two unique switches or who are unable to control two switches reliably.

Example Four: The Manual Cycle with 1 Switch

Visual example of manual cycle with timeout. Same frog, same plates. This time the user presses the orange button to select which plate the frog looks at, however to select the cake, the player stops pressing the orange button long enough for the timer to run out and select the cake automatically.

Manual cycling with one switch allows a one-switch player to select their desired choice reliably, by only switching choices when they activate their switch, however it can reintroduce time pressure on the player because if the player does not choose to cycle to the next choice by pressing their switch before the timer runs out, the system assumes they are making an intentional selection of the current choice.

Pros to The Manual Cycle with 1 Switch:

Accessible to the one-switch player.
Selecting the wrong choice may be less likely, because the player advances the cycling themselves.
The player can focus on the screen, and not the physical switch, since they don’t have to alternate between 2 switches.

Cons to The Manual Cycle with 1 Switch:

This method can cause increased fatigue in players, since they have to activate the switch more times to complete simple tasks.

Younger players may find it difficult to wait, as they tend to enjoy pressing buttons rather than waiting for the timer to “fill up” and confirm their choice selection.
A player may “run out of time” and accidentally select an unintended choice.

Example Five: The Undo

Visual Undo example. Same Frog, but only 2 plates, the apple, and the cake. The frog is automatically cycling between each option at a rate of every 2 seconds. This time the player presses the button to select the apple. A message is displayed asking if the user wants to undo? The player selects undo by pressing the orange button before the timer runs out.

The undo is an option you can add to any of the above methods to make sure the player is able to correct their choice, if a mistake has been made. A built in undo within the game gives the player the opportunity to go back and select the choice they desire. In this animation, there is still time pressure to click at the correct time, however if the player activates the switch at the wrong time, they can activate the switch again to select the other option before the Undo timer expires. To finalize their choice, they have to push the switch to select their choice and then wait for the undo time to expire.

Pros to the Undo:

It is unlikely the player will be stuck with an undesired choice.

Cons to the Undo:

Undo can slow down gameplay. If every selection must be “confirmed” by the player a second time, it doubles the selection time. Every choice requires the player to wait for the undo timer to expire.

The Eye Gaze Player

Eye Gaze players have the benefit of quick reflexes. Our eyes can move fast! However, players typically can’t play as fast as they move their eyes. Just looking at something on the screen doesn’t mean they want to move their avatar, or attack an enemy on the screen. The game needs to know what the player intends to do with their eyes.

Eye Gaze systems often use onscreen dashboards to control the player’s intent.

Visual representation of an eye tracking dashboard. The image displays 6 buttons, one for left click of a mouse, one for double click, and 4 arrow keys to move the mouse cursor incrementally across the screen.

When the player wants to move their mouse cursor, they may select a “move mouse” option, or when they want to “double click” they may select the “double click” option, and then look where they want to double click.

When designers don’t think about the time it takes for a player to comfortably input what they want to do, then game design can penalize these players or leave them out.

In Jack’s case, he had to move a cursor a little bit at a time across the screen using buttons like the ones represented in the image above. Then, he had to look at a different screen to determine if his mouse was in the correct location for what he wanted to do. For a timed mini-game, it didn’t matter that Jack knew how to play and knew how to solve the puzzle, the time limit didn’t wait for Jack’s eyes.

In Part 2, we’ll share with you some of our design considerations for reducing timer dependency in the action and movement of the game. We’ll also discuss how our level design and game play consider those who need additional time. We want to make sure that Painted Waters is fun for everyone to play together.