-
Accessibility Features
-
Testing and Iterating
<
>
Accessibility with no excuses
"Accessibility" means a lot of different things. In this case, I'll define it as features and design choices that enable more people to use a product. This includes people with audio, visual, touch, speech, cognitive, and/or age-related challenges. (You can read About Me to learn why it's important to me.)
In many projects, accessibility gets shoehorned in or you have to fight tooth and nail to include it. It can be viewed as trivial in the face of malfunctioning features, tight deadlines, and shiny widgets. I don't advocate that the best team is a team made entirely of you. But keeping this a personal project makes implementing accessibility easier. Plus, it can serve as a use case of the impact of accessibility for future teams.
In many projects, accessibility gets shoehorned in or you have to fight tooth and nail to include it. It can be viewed as trivial in the face of malfunctioning features, tight deadlines, and shiny widgets. I don't advocate that the best team is a team made entirely of you. But keeping this a personal project makes implementing accessibility easier. Plus, it can serve as a use case of the impact of accessibility for future teams.
Basic accessibility features
Qualdrin's gameplay is so simple, there's plenty of room for applicable accessibility features. But, the first feature I implemented is the number one accessibility request: the ability to change the controls. This is important for gamers with physical handicaps. It can also extend to physically demanding situations, such holding a child in one arm but still wanting to play (which actually happened at a convention).
For basic visual accessibility, no information is conveyed by color alone. I could have easily taken one enemy design and gave it different colors based on its abilities. Instead, there are multiple designs and silhouettes. This enables players with color-blindness or other visual challenges to still distinguish their foes easily.
Unintentionally, I also gave the game high contrast visuals. All colorful objects and white text stand out against the dark, simple background.
Advanced accessibility features
The previously mentioned features don't cause much debate (though high contrast visuals might not be a default choice depending on the artistic vision). These next ones tend to raise eyebrows.
Allowing players to play without getting a game over. A player with cognitive challenges may have to go through more failures than other players to understand a game's mechanics. Optionally removing game overs helps keep the learning momentum going, among other benefits. (I later changed this to give 10 times the normal amount of lives.)
Allowing players to play without getting a game over. A player with cognitive challenges may have to go through more failures than other players to understand a game's mechanics. Optionally removing game overs helps keep the learning momentum going, among other benefits. (I later changed this to give 10 times the normal amount of lives.)
Allowing players to change the game speed. Some may worry that allowing the game to go slower takes away the challenge or fun. But this, and other options, should be thought of as difficulty sliders. You can fine tune various aspects of the game to provide the right amount of challenge for you. Why would you purposefully set the difficulty of another game to "easy" when you can handle "intermediate"? Or set it to "hard" when it's too difficult?
The Boxer Boss
Qualdrin's second level was always meant to start encouraging players to use their blocks more thoughtfully. In the early versions of Qualdrin, the boss at the end of the second stage was "The Boxer". He had a narrow gap that would only allow small blocks to hit him. But players struggled, either rationalizing all blocks won't work or fitting it in the gap was too hard.
The Catcher Boss
When I redesigned the game, I created a new second level boss: "The Catcher". He would throw back small, light-weight blocks quickly, and larger, heavier ones more slowly. So defeating him requires you to use your large block to make him vulnerable long enough for another attack. This should be more fun and easier than The Boxer, right?
I only solved half the problem. Players didn't have to worry about accuracy, but they still would rationalize that all blocks wouldn't work. They stuck with firing their small blocks and didn't try using their large blocks.
Two Revelations for Boss 2 - Version 2
After discussing with other game designers, I discovered two problems with the new Catcher Boss.
- The levels leading up to the second boss didn't present challenges that could only be solved by using specific blocks. Why should I expect players to suddenly realize this boss could only be defeated a specific way then?
- I never introduced the concept of your blocks having weight. Why should I expect players to know they need to use "heavier" blocks on The Catcher?
Size is Everything
Until I introduce enemies or scenarios that give your blocks weight, I'm sticking with size as the "clue" for defeating the second boss (and overcoming other puzzles).
I was previously hoping random clusters of enemies in my stages would encourage using large blocks. Taking a more purposeful approach, I added Ship Clusters to each level. They are a side-by-side group of three ships that can only be optimally destroyed by using large blocks.
I was previously hoping random clusters of enemies in my stages would encourage using large blocks. Taking a more purposeful approach, I added Ship Clusters to each level. They are a side-by-side group of three ships that can only be optimally destroyed by using large blocks.
In the next version of the second stage boss, I am creating "The Gourmand", swapping the gloves again for a pair of forks. This boss will eat the blocks bit by bit before spitting them back at you. It's functionally the same as The Catcher, except it's size that should be the clue, as said before. The bigger the "food", the longer it takes to eat.
(An A/B test between The Catcher and Gourmand is currently underway.)
(An A/B test between The Catcher and Gourmand is currently underway.)