Unity Accessibility Plugin – Update 9 – Is It Worth Doing?

After having spent months working on an accessibility plugin for Unity, it might be time to discuss the most basic question:

Is it even worth doing?

Are there Unity developers out there interested in using this plugin? Is it attractive for devs to make games accessible? Are there enough blind gamers out there? Is there money in this? And are there other reasons to do it?

Arnold Schwarzenegger looking at a skull like Hamlet, pondering a big question.

To Be Or Not To Be?

The Big Question: Is it financially viable?

The logic is simple: If it isn’t financially viable for developers to make games for the blind community, then it wouldn’t be financially viable to make an accessibility plugin.

Generally speaking, if enough people need or demand a specific Unity plugin, then someone will already have created one. Considering there currently is no accessibility plugin already available on the asset store, I have a feeling I already know the answer to this one.

Woman standing excitedly in front of the Unity Asset Store.

You want it? The asset store has it. Usually.

Let me say right away that I didn’t start working on this plugin to make money. But I want to look at this from all angles, including the financial side. So let’s look at it in detail.

Is there a Market for Blind Gamers?

The World Health Organization estimates just below 300 million people worldwide to be visually impaired (Source). To give you something to compare, that is a little less than the current total population of the US. The American Foundation for the Blind estimates that 22 million adult Americans have some form of visual impairment, and in total roughly 10% of the population suffer some kind of vision loss. (Source)

Those numbers are high enough to present a very viable market share, but being visually impaired and being blind is not the same thing. Out of those 300 million people, only 40 million are estimated to be legally blind, with the remainder having some vision left.

A woman wearing a blindfold is trying to use an iPad

Surprisingly, I couldn’t find any statistics on how many sighted people play on their phones while wearing a blindfold.

There is no way to tell how many people in this group would benefit from a screen reader plugin, or are able to play games just fine. For the purpose of my calculations, I will go with the most pessimistic approach and assume that currently the market is capped at 40 million people worldwide.

40 Million Blind Gamers? Really?

While 40 million still sounds like a decent market, that number is misleading. Are those 40 million actually interested in games, and would there be a way to monetize games targeted at them?

About 20% of the general population play video games (Source). Assuming that the blind population shares this percentage, that would bring the number down to 8 million potential blind gamers. Those stand opposite a staggering 1.2 billion sighted gamers. That means the blind gaming market is only 0.7% the size of the one for the sighted.

Considering the size and that this number is worldwide, including many non-English speaking countries, the market just became a lot less attractive. Now we’re talking about not just adding accessibility, but localization as well, if a developer wants a chance to reach that market.

Blind man with a white cane

What’s more, according to the WHO, more than 80% of the visually impaired are 50+ years old. I was going to discount this age group at first, but according to a representative survey, this age group actually represents a fourth of all gamers. You can find that survey here.

Marketing to Blind Gamers

While age might not impact the market size, discoverability of games made for the blind does. What good is a game made for blind people, if they can’t find it? This is a real problem. I recently heard from a colleague visiting a convention for blind people that many aren’t even aware that games for the blind exist at all.

Currently, there is no way for a developer to reach the blind target audience on a broad spectrum. AdMob doesn’t offer a check box to show a game ad only to people with visual impairment. Neither Apple’s App Store nor the Google Play Store offer a way to find apps that are accessible. There are no categories or tags to sort or filter them. Blind users rely on word of mouth recommendations, podcast Let’s Plays and a number of websites that try their best to maintain lists and recommendations of accessible apps.

Logo of the Steam Game Store

Steam has great discoverability compared to Google and Apple.

Oddly enough, a simple user tag system like Steam has successfully implemented would instantly fix this problem. I mentioned this to a friend and he noted that the app stores might actually not want to make discoverability too easy. Google and until recently Apple are also selling advertisements via their ad networks, so it would directly cut down on their income.

Do They Have Smartphones? Tablets? …or Internet?

This one is a tricky question – though it seems that with the exception of Cuba and North Korea, this doesn’t seem to be a problem. The statistics indicate that we are well on the way to everybody on the planet having a cellphone: Countries Population and Number of Mobile Phones. When looking at those numbers, keep in mind that they can be misleading. Even though statistically every man, woman and child in Hong Kong owns 2.4 mobile phones – it is safe to assume that there are plenty of people there that don’t have even a single one.

In a nutshell, don’t be fooled into assuming that all blind people in all countries have phones, internet or computers. I couldn’t find any good numbers for this, the closest I found was some statistics on how many people use a screen reader. But the survey was small and possibly not representative. I don’t know if the numbers outside of the US are even statistically relevant, due to the small number of participants. But you can find the survey here: Screen Reader Survey

At least for the US, the numbers are looking good. The majority of blind people seem to use or have access to a phone or computer and internet.

Monetization – Do They Have Money?

The question might sound cruel, but I said I was going to look at this from all angles.

Scrooge McDuck carrying a briefcase with money falling out.

The WHO states the 90% of people with visual impairments live in low-income settings. This can mean a number of things, like living in an underdeveloped country with inadequate access to health care. It could also simply mean being unemployed, possibly because of the visually impairment. The numbers on the National Federation of the Blind website point to an unemployment rate of near 20% for visually impaired adults in the US alone. (Source)

Monetization – Whale Fishing

Low income might not mean poor, but it means that this group will likely not spend huge amounts of money on games. In-app purchases in mobile games usually start at 99 cents a pop. This alone will hardly ruin anyone, but those 99 cents are not where a developer’s money comes from. The money is made through whales. And with 90% of a group being classified as low-income, it’s reasonable to expect there to be less whales in this group than in the general population.

Picture of a whale smiling lazily.

If you are unfamiliar with the term whale, here is an article that explains it: 0.15% Of Gamers Bring In 50% Of The Revenue

There are other means of monetization, such as simply charging a premium for a game, and showing advertisements. The premium game approach might work well with this group, but it doesn’t fly well with the rest of the gaming world, where everything has to be free. Advertisements are even trickier. Ad providers that pay-per-click will be useless since the chances of a blind user clicking on an ad are relatively slim. Rewarded video ads however could well work, as they usually pay for watched videos and not clicks.

If there was a way to include radio ads in mobile games, it would be a great way to gain some of that earning potential back.

An Unattractive Target Audience?

Let’s conclude that the majority of blind people worldwide has or could get access to a cellphone, but can’t spend a huge amount of money on games.

The market is small, and there are few marketing options. The app discoverability is poor and the monetization options aren’t as plentiful.

UPDATE: Before you read on, you might want to check out Ian Hamilton’s comment to this blog post. He raises some excellent points as to why and how blind gamers can actually be quite an attractive audience, even financially speaking. I won’t steal his words, so this link will take you directly to the comments: Comments

Big Publishers vs. Small Developers

That makes blind gamers into an unattractive target audience for the big players – if you look at it from purely a financial standpoint. Large user bases and whale fishing are important to big developers and publishers. Our own studio has been turned down by publishers because our games didn’t offer the ability to spend endless amounts of money.

Having said that – it’s possible that publishers and big development studios are interested in accessibility for other reasons. Such reasons could be maintaining a good image. It could be due to public pressure. Or because it is the right thing to do in an inclusive, civilized, western society. Or simply because the CEO has a relative who’s blind.

Smaller developers and indies on the other hand might be drawn to this group a lot more. The market might be smaller, but there is potential for growth, and it isn’t yet overcrowded with games. In other words: There is a LOT less competition. And smaller devs need a LOT less money to be financially viable.

A homeless man sitting on the street begging - next to a sign that reads: "will code for food".

Indie developers need less than big developers to be profitable.

The design challenge of making games for a blind audience could also be attractive to indies. If the blind are targeted exclusively, games can be made without any graphics at all, which could further entice small developers, as audio can be cheaper than graphics. In fact, I’m surprised not more indies have flooded into this niche yet. Maybe my plugin could give them the push they need. (Well – one can dream, right?)

The problem of discoverability for accessible apps and games remains. It is potentially the most important issue that’s blocking developers from entering this market niche. Incidentally, it is also the easiest to fix, if Google or Apple were willing to make a minor addition to their stores, in the form of a tagging system for example.

Conclusion

Summing this up is not an easy task.
It seems that estimating the earnings potential of this market is simply impossible. Which means it’s impossible to judge whether anyone would actually buy my plugin on the asset store.

So… the prospect of earning lots of money obviously won’t be the force driving me.

So? Is It Worth Doing?

Spoilers: Yeah, I think it is.
There are other things to consider aside from financial feasibility. Here are some of them:

Self-interest.
I have often wondered what would happen if I lost my eyesight. Maybe every programmer has wondered this at some point. I need my eyes for work. Sure, it wouldn’t be the end of the world, but personally, I would rather lose an arm or a leg than my eyes. If I go blind one day, I want to still be able to play games. Heck, I want to still make games. But one thing at a time. Self-interest is definitely at play here.

It might make people happy.
Who doesn’t love that? The feedback I have gotten so far is great and has motivated me like nothing else. Every time I read a positive comment on my thread at AppleVis or talk to someone on Twitter about this project, I feel the urge to drop everything else and work on the plugin some more. This is the kind of motivation that will keep you coding away the entire weekend without it ever feeling like work.

I want to see if I can do it.
That to me is a perfectly valid reason to do a lot of things, and maybe you can relate. Also, this is a missing feature, a hole that needs closing, and that keeps bugging me,

I really don’t expect to make heaps of money with it, and the numbers back me up on this. I’d be happy if the time I will have to spend on support is covered. Because that would mean I get to spend time on fixing bugs and improving the plugin

Final Thoughts – and numbers aren’t everything

Remember the Ice Bucket Challenge?

Actor Benedict Cumberbatch sits on a bench shivering, while being doused with ice water from above.

Only 0.01% of Americans have ALS, an estimated 30,000 people (Source). That number obviously is far FAR smaller than the 22 million adults with visual impairments (more than 700 times, to be exact). Yet, the ALS Ice Bucket challenge raised over 100 million dollars. And what’s even more, it raised public awareness. I bet if I talked to ten random people on the street, four of them will have heard of ALS. Or at least that crazy time when everybody filmed themselves pouring ice-cold water over their heads for some charity thing. But all of them will stare at me with wide eyes when told that blind people can actually use smartphones.

Numbers and financial feasibility aren’t everything. Developers, especially the big ones, have other good reasons to consider accessibility, and public image is important to them. Did you know there is actually a petition underway to entice the Pokemon GO developers to make the game accessible? It’s worth a try, since public awareness can move mountains.

My final take on the topic is this:
If it was easy, comfortable and convenient, more people would consider making their games accessible.
And that is one more reason to make this plugin.

 

Afterthoughts

Public Exposure

Unity currently has close to 6 million registered users (Source). Of course, not all of those actually will ever develop or release anything with the engine, but many will create multiple games, again and again.

34% of the Top 1000 Free Mobile Apps in 2016 Q1 were made with Unity.
This is relevant, because it says that if there is a popular game out there that everybody is playing, there is a 1 in 3 chance that it was made with Unity. But if it was made with Unity, then it will automatically be not accessible with screen readers. Case and Point: Pokemon GO!

Imagine the public exposure the whole accessibility issue could be getting if those popular and visible apps start caring about accessibility? Even if they only care about it because I offered them a convenient and inexpensive way to do so.

Non-Gaming Developers

I also want to mention use cases of the plugin outside of gaming.

There is probably a number of users currently not using Unity, because their software has to be Section 508 compliant. I imagine this includes a lot of public institutions as well as government subcontractors, the military and serious games developers. The plugin could introduce Unity to a whole new range of users. I am not sure that the plugin is enough to make apps actually 508 compliant, but it is a start.

Unity Accessibility Plugin – Update 7 – Explore By Touch

As of today, the Unity Accessibility Plugin has a new feature: Explore By Touch!

Explore By What Now?

Explore By Touch is an accessibility feature on smartphones that let’s blind users run their finger over the screen – and the screen reader will read out what’s under their fingertip. The screen reader also makes sure that no buttons are accidentally pressed or an app is started unintentionally. This works on both Google TalkBack and iOS VoiceOver.

A blindfolded man is swinging a stick at a pinata. He misses and hits his girlfriend instead.

This was my original impression of Explore By Touch. Typical rookie mistake of a sighted person.

I originally thought that this is one feature that I wouldn’t need to re-create for the accessibility plugin, because I figured that no one would be using it much. I assumed no one wanted to blindly poke around on the screen to discover buttons. Why would anyone do that when swiping left and right navigates safely through the user interface?

Think again, you sighted fool!

As we all know, making blind assumptions is a bad thing. Pun intended.

Why would anyone use Explore By Touch?
The answer is simple. Because it is faster!

Navigating menus is a necessity, not fun. Doing it slowly by stepping through all elements on the screen one by one doesn’t make it any better.
If you already roughly know where a button is located, then using Explore By Touch is the next best thing to actually seeing where it is and clicking it directly.

Sure, the first time you get hit with a new menu, you might just trigger the Read From Top function and have the entire screen read out to you. But after that, you can poke around and find out where things are. And being blind doesn’t mean you cannot remember roughly where a button is located on the screen.

Thanks for the Feedback

I wouldn’t have come to this conclusion if I hadn’t received some very clear feedback from an actually blind person, who straight up told me the plugin would be pretty much useless without Explore By Touch. His opinion matched what I read in an article by Matt Gemmel in which he covers Myths about visually impaired users. After that I put my phone back in accessibility mode for a while and ultimately had to agree. It made me want that feature, too.

I am happy to announce that my plugin’s Explore By Touch is now fully functional.
Also: Thank you for your honest feedback, Scott!

3D Audio with Stereo Headphones

Today I want to write about an audio experiment I did for a game that I’m developing using my Unity Accessibility Plugin. It’s an accessible cooking game in which you prepare food for customers.

Problem 

The game pans the voices of customers to the left or right, depending on where they are standing. But when playing the game blind, I find it hard to quickly tell where a customer is. It always takes me a second and it requires a little concentration. This might not be a show-stopper, but it keeps bugging me.

Spatial Audio could be the solution.

Woman with headphones on has her eyes closed and focuses on the whether the sounds are left, right or center.

One burger to the left, two hot dogs to the right…

3D Vision and 3D Hearing

Never heard of spatial audio? Don’t worry, I won’t delve into the details. In a nutshell, it is a clever way of playing back audio so that the listener has a 3D audio effect using only stereo headphones. It’s not even that complicated. Humans only have two ears, so stereo is technically all we need.

Just like your brain uses the differences in the images from your two eyes and gives you 3D vision, it uses the differences in sound between your two ears and gives you 3D hearing.

The picture shows sound sources that are placed at different locations around a head.

Even with only two ears, you can always tell where a sound is coming from. Image Source

Here Is The General Idea

Because sound waves travel through the air (at the speed of sound), a sound coming from your left would reach your left ear first, and then your right ear. Furthermore, your head is in the way of the sound and will block part of it. This is called the head shadow, which dampens some frequencies from the sound before it reaches your other ear. While the differences are very small, your brain picks up on them and uses this very subtle information to place the sound in the world around you. There’s more playing into it, like sound reflected off walls close to you etc, but I said I wouldn’t delve into the science too far.

If you haven’t yet, listen to the famous barber shop example (skip to 2:54 to get the idea):

 

Famous Games using Spatial Audio

A game can reproduce this 3D effect artificially, by delaying the playback on the far ear and filtering frequencies. The only requirement for it to work is that the player wears headphones.

Games for visually impaired or blind players sometimes use spatial audio to allow players to find their way in the dark. Famous examples are the Papa Sangre games and The Nightjar. If you want to check them out, get The Nightjar if you like Benedict Cumberbatch, or Papa Sangre II if you are a fan of Sean Bean (no need to play Papa Sange I first).

Actors Benedict Cumberbatch and Sean Bean inside a voice recording studio. They look cute.

The Nightjar and Papa Sangre II have pretty darn good voice acting in my totally biased opinion.

Unity and Spatial Audio

Somethin’ Else, the developers of Papa Sange and Nightjar, have written their own audio engine and their results are impressive. I wanted to give spatial audio a try in my Sandbox dev environment, before bringing it into my game. But I am fan of not reinventing the wheel. I didn’t want to implement my own spatial audio system when there are some out there already.

There are plugins for spatial audio available for Unity. Here are the three that I found in the Asset Store: Spatial Audio, AstoundSound and dearVR. The last one looked the best, but the first one was the cheapest. For just a quick test that would do. But dearVR is now on my WishList and I will be hoping for a sale in the future.

Direct Comparison

Which one works better?
The majority of people should be able to tell the direction of the voice much faster when listening to the spatial audio example.
But have a listen for yourself.

Put on your headphones and try to determine whether the voice is coming from the left, the right or from the front. How fast are you able to tell the direction? Do you need to focus on it?

Tip: After you’ve listened to the spatial audio example, listen to the stereo one for a second time. It seems a lot worse now, doesn’t it?

I know the spatial audio sounds like it is panned more to the side than the stereo one, but that is not the case – it’s just the effect that the brain creates from the sounds.

EDIT: I just learned that the SoundCloud player above doesn’t work with all screen readers. Here are alternative links to the audio files:
Stereo Results
Spatial Results

Conclusion

While the stereo panning works “good enough” for the simplistic setting of my cooking game, it seems to me that the spatial audio requires less effort to determine where the sound is coming from. For that reason, I will put in the work and switch over to the spatial audio library. The difference might not be huge, but I am hoping it will make the gameplay feel more intuitive, because blind players need to pay less attention to locating the customer. After all, the gameplay is supposed to be about cooking, not about telling direction.

Notes for those interested in the topic:

  • If you want to play around with spatial audio in Unity but are unable to spend money on plugins, good news: Unity has just released a demo Spatialization SDK. You can find it here. I gave it a quick test and it seems to be working fine. Hint: If you check out the demos, you need to select the HRTF demo.
  • If you want to read more about the topic of spatial audio, but are bummed out by all the “binaural beats for better sleep” nonsense search results, try searching for ‘HRTF’ instead.
  • The developer Somethin’ Else used to license their audio engine (Papa Engine) to other developers. While this is no longer the case, their website hints that there might be a Unity compatible version in the future (see here). There is also a forum thread that claims the engine might become open source entirely. You can read about it here.

 

Dev Update #14 – Concept Graphics and Aspect Ratios

Have your base (classes) covered!

In spite of what I wrote in my previous blog post, I realized I need to create one more department before I can finally tackle the Build Menu: The Management department. Like the Design department, this one works differently from the production floors. This makes a difference from the coding point of view – as I want a base class to take care of all floors, and then handle only specialized stuff in derived classes. And like I said, I want all my bases covered.

Here is the mockup graphic for the Management floor:
Management

The idea was that a Management floor can employ up to four development directors. Each director would allow for one game to be in production. This way the player can work on multiple games at the same time. But I made a pretty noobish mistake when creating the above mockup – I hadn’t given any thought to the aspect ratio of my floors.

Aspect Ratio, anyone?

When creating the actual game graphics for this floor based on this mockup, I ran into some trouble. I hadn’t really thought about aspect ratios and screen width when I created those images. That was a big mistake, as it turns out. The mockup screens were too wide. There was simply no room left on the right side of the screen for the two big purple buttons, not unless I scaled the height down.  But then everything else in the floor would become tiny. To counteract, I would have to scale up the characters. But then I didn’t have enough room above the head of the managers to put the actual game icons. My characters were simply too big.

So I redesigned that department completely. Here’s the result (middle floor):

BlogPost15

Instead of placing the icons above the characters’ heads, they were placed next to them, sorta like a PowerPoint screen in the background. It actually gives it a nice manager look and feel. And as a bonus, this will free up some screen space at the top of each floor where I have been wanting to put a floor number. In another change, the Release and Trash buttons on the right are done away with. Instead, scripts can be released or trashed by clicking on them and opening up their details dialog.

I definitely learned my lesson and will create future mockups in a sensible aspect ratio.

Now, this time for real – next up is going to be the build menu.

Dev Update #13 – Code and Design Departments

It should have come as no surprise to me that spending my free time working on a game directly clashes with writing blog posts in that same free time. And one of these things simply comes more natural to me than the other. So it’s been five months… Time for an update.

I really want to start working on the build menu, but before I can do that, I need a few floors that I can actually build. So I created basic prefabs for the Code and Design departments.

Here are the results.
BlogPost12The Code department layout (top) represents the basic layout for all the basic production floors. 3D Art, Animation, Sound etc… they all will share the same basic setup with three queue slots. The Design department (bottom) works differently and needed a special setup. So it made sense to create these first and cover all my bases.

In my original game design document, the workers would all sit with their backs towards the player. This was mainly due to my poor drawing skills. But for the actual game I found this to be too boring. So instead, I turned them all around, so that they would be facing the camera.

The floors all use the same background graphic for the floor, which is actually grayscale. The graphic is tinted in realtime with the color of the floor.

Please keep in mind that the floors are not really finished yet. The coder for example doesn’t even yet have a computer in front of her. But it’s good enough to work with. Now I can start creating the menu that let’s me build floors into my game studio tower.

Dev Update #12 – Game Name Generator

I like to get all unpleasant work out of the way first – but I allowed myself a little fun task this week: A Game Name Generator!

blog_gamenamesFor my game Game Tower I need a bit of code that randomly generates game names for the virtual games the player creates.

This was probably the most fun task of all the work so far!

Pattern Matching

I went for a simple pattern matching system. The generator picks a pattern at random from a long list and then replaces the placeholder wildcards with random words from others lists.
Here are a few examples of such patterns:

<name> and the <noun>
<noun> Tycoon

The generator would take such a pattern and replace the wildcards with words from a list of pre-approved words. The wildcard determines which words match – there a nouns, verbs, names and plural forms of nouns. When all wildcards are replaced it spits out the finished game name, for example:

Jesse and the Unicorn
Waldo and the Zombie
My Mom and the Warlock
Zombie Tycoon

It’s soo much fun!

I added the name generator to my debug menu (see Dev Update #9) so I can test it out and generate new game names when I feel like it. It works great and I find myself adding new words or patterns to my database every few days, because it is simply that much fun.

GameNameGenerator

Good ideas come … while in bed.

All patterns and words are kept inside my trusted Google Spreadsheet. I have a macro that can convert them into a string list quickly, so I can get it into my code fast. I can access the spreadsheet from anywhere – and this has already paid off.

Like all coders (I assume) I have a lot of good ideas in bed. When I have a fun idea for a new pattern or a noun to add to the list. I can just reach for my phone and punch it in.

More updates and screenshots from the game in progress coming up soon!

Dev Update #11 – Tip of the Day instead of a Tutorial

I would like to see if it’s possible to make Game Tower a game that can be played without a needing tutorial.

It’s not that I would shy away from implementing one. But when I pick up a game, I would like to start actually playing it right away. So this is an experiment I will try. There’s two plans of attack I have for this: Giving the player more features only over time and a Tip Of The Day.

Tip of the Day

I like loading screen-tips in games, because I can easily ignore them when I don’t want them. A tutorial forces me to click at a sequence of buttons in a specific order and is much more restrictive. That is fine for other games, but feels like overkill for such a simple game like Game Tower.

BlogPost11More coder art for your enjoyment! Ok, I know that this is bad, even by my standards. But my plan is to get the entire game done and working. Then I can see to it that the graphics are replaced by someone with actual talent.

So I created this quick’n’dirty Splash Screen and a Tip of the Day database. A random tip is displayed every time the game is started. The game will load the player’s tower in the background while the screen is displayed. There is a minimum display time of 4 seconds, to give the user a chance to read it even if the loading is done faster.

Easy to Learn, Difficult to Master

Probably everybody has heard of Bushnell’s law, that good games are easy to learn and difficult to master. The actual quote is a bit longer and also mentions rewarding the player (here is an interesting blog post about it). But I’ll stick with the short-hand version for now.

Applying that to my no-tutorial experiment, it should be possible to make the game easy enough in the beginning that there is no need for a tutorial before the player can start actually playing. I will have to do some more trial-and-error testing, but my current plan is to provide the player with three basic floors instead of an empty tower at game start. That way he can immediately jump in and start producing games, rather than worrying about building the correct floors, hiring people etc. Essentially I want the player to learn the core gameplay first – and then get into the finer details as he levels up.

The level-up design should come in really supportive here as well. Since the player unlocks more departments and larger game designs by leveling up, the complexity of the game already starts out small and grows larger over time.

If at first you don’t succeed…

…make sure you don’t blindly ignore if something is just not working.

Making Game Tower playable without a tutorial is something I want to try. But I won’t stick to it like it’s set in stone. If in the end I discover that the absence of a tutorial makes the game to confusing, I will mark the experiment as failed and provide a tutorial. After all, the game is meant to be played.

P.S.: I am also playing around with different names. That’s why that screenshot reads “Game Studio Manager” instead of “Game Tower”.