Galactic Colonies – Accessibility Update
October 8, 2019 mikrima	Leave a comment
Since I announced that it will still be a little longer to get the accessible version of Galactic Colonies out, I thought I could at least keep everyone updated on the progress.
First things first – no, I don't have a release date for the accessibility yet. But the game is coming along great, and a lot of things have been done in the last two weeks. I wanted to give you a little update on what I've been working on, and share a short video.
Same UI, but different
I'm trying hard to make the accessible version of the game use the exact same UI as the game has when accessibility is turned off. That is not only consistent, but it makes it a lot easier to maintain the game, too.
But this doesn't always provide the same game experience to sighted and non-sighted players. Sometimes a small change in how the UI works can make the game more enjoyable for players that rely on a screen reader.
To construct a building on a planet, a sighted player first selects the building from a list in the build menu. Then he can see the price and time it costs at the top of the menu. If he has enough money, he'll hit the button labeled "Build" at the bottom of the menu to start construction.
Sounds simple? Now do it blind!
Image doing the same task when you are navigating the construction menu with a screen reader, and traverse all buttons one by one.
Selecting a building is easy enough. But then you'd have to navigate back to the beginning of the page to read the price and the construction time. And this is assuming that you even know that you have to do that in the first place. Then, if you want to build it, you have to get to the very bottom of the page where the build button is, traversing through each and every building button on the way. The information and functionality that is instantly available for a sighted player is hard to get to for non-sighted players.
So instead, when accessibility mode is on, the price and construction time of a building is read out immediately along with the building name. And if the player wants to start construction, he can double tap while the building is selected, and that will automatically start the build process. No need to navigate to the build button at all. In fact, the button won't even be shown if accessibility mode is turned on.
Left shows sighted mode menu, right shows the accessibility version
The code of the user interface had to be partially rewritten to support this change, but I think in return the construction menu is now really usable. You can see and hear this in action in the video at the end of this post as well.
Selling Stuff
To sell product from a warehouse, sighted player can use sliders. While they drag the sliders to the right to sell more and more of the product, other part of the UI will change to display how much product will remain and how much money will be earned if the player lets go of the slider at that point.
This is not practical for screen readers at all.
We took a lesson we learned from Crafting Kingdom and replaced the sliders with buttons. One button to sell all, one button to sell half, and one button to sell a single unit of the product in the warehouse.
Here's screenshot of the warehouse menu for sighted and for accessibility mode next to each other.
Left side shows the slider based sighted version, and the right side the accessible version which uses buttons instead
In this instance, the UI had to be replaced by completely different UI which is only active when accessibility more is on. This change required both new code and a new user interface setup, so it took a little longer.
Got something to show?
After the last post only included an audio demo I'll include a short video in this one. Please keep in mind that this is still all extremely work in progress and by no means ready for release yet.
Thank you to everyone who's commented and thank you for all the patience.
a11yaccessibilityaudio gameblindblindnessGamingindiedevmadewithunitymobileUnity
Galactic Colonies – Accessibility Sneak Preview
September 5, 2019 mikrima	8 Comments
Galactic Colonies is on track to be fully accessible. Soon-ish.
Actually, it's coming along quite nicely. I made a recording of the first 4 minutes of gameplay. If you're interested in a sneak preview, here it is:
If your screen reader has issues with the sound cloud player, here's a direct download link: Galactic Colonies Accessibility Audio Demo
Sounds like it's almost done, when can I play?
In the demo, things sound a little further along than they actually are. In reality there is still a metric ton of work to be done.
I'm sorry to say, I have no release date for the accessibility patch yet. But it will more than likely be a few more weeks.
Different from all other games I've made accessible in the past, this game has a lot of 3D elements. Those are making things tricky, and there is need for many creative solutions.
Sounds a little… vague?
Fair enough. I'm going to describe an actual problem that I'm working on this week. That should demonstrate why it takes a lot of time to make this game accessible.
As part of the game, players have to build colonies on planets. This gameplay happens on the planet's surface. Players can explore new regions, construct houses, farms and other production buildings and set up a flow of products between buildings. Everything is in 3D of course, and the camera can be moved and zoomed.
Colonies can get large
The difficulties start with selecting a free region to place your next building on. In the beginning only a handful of regions are explored, but there are a total of 2500 regions on each planets surface. Obviously I don't expect players to swipe through them one by one, by one by one by one… I need to find a different method for players to navigate their colony.
The planet surface is flat, but it is a hex map, not squares. So a simple up, left, right, down navigation doesn't cut it either. Each tile has six neighbors around it, not just four.
It is important to know which tiles are next to one another. Farms built next to a lake will produce more food. Houses next to an industrial building will have reduced capacity. Because which colonist wants to live next to a polluting, stinking factory? So the game can't simply make the decision of where to build next for the player either.
The problems don't end there. Some buildings need to be connected, so that one building can deliver products to another. You can produce food all day long, but you need a warehouse to store it in. And then you want the food to be distributed to your various houses, so your colonists don't starve. Buildings that are too far apart cannot be connected. And one warehouse can only supply goods to a maximum of four other buildings.
Warehouses are among the most important buildings in this game
Planning out what is delivered where is a core part of the game, so again, the game cannot make these decisions for the player automatically. These connections are set up visually by tapping on the buildings you want to connect. Difficult to do if vision isn't an option.
But as you can hear in the audio demo, I haven't been idle these past few weeks, and some parts of the game are already playable.
That was just a glimpse
I'm spending my days trying out a lot of different solutions to all of these problems, and then throwing away anything that doesn't work.
This, obviously, takes time.
And keep in mind, everything I described above is just one of the mechanics in this game that I have to solve. It isn't the only one. I haven't even talked about space travel yet!
We made a good game with Galactic Colonies, and I'm determined to deliver a good experience on the accessibility part, too. I know as well as anyone how frustrating waiting can be, but I'm convinced it will be worth the wait.
Thank you for being so patient!
Unity Accessibility Plugin – Update 16 – Asset Store Sales (Am I Rich Yet?)
March 5, 2018 mikrima	2 Comments
The Unity Accessibility Plugin has been on the Asset Store for 10 months now – time to take a look at the numbers.
Sales and Updates
The plugin is performing well for what it is: A small niche product.
On average, about 4 people pick it up each month. Not all of these are paid, since I occasionally give out a free key, and the plugin was on sale at a reduced price for a while.
Do you really think this is what's happening?
If you do the math you'll see that no one is getting rich from it.
Of course that's not stopping the occasional side remark:
"Why isn't this free!?" (to which I quietly sigh and then move on)
I always had very realistic expectations about sales (remember my post: Is It Worth Doing?). In fact, I had only anticipated about 1 or 2 per month. So by my standards, the plugin is actually outperforming! And the sales I get allow me to spend some time each month on email support and on updating the plugin. Since release, I've updated the plugin three times and I'm about to release a fourth update.
This is exactly what I was hoping for and I'm really happy the plugin is doing this well!
Mac Support (and JAWS)
One of the biggest features I've added was support for voice out on a Mac. I am not a Mac user and feel uncomfortable using one, so I kept putting it off. It wasn't until a friend needed it that I finally took a deep breath and jumped in. The code for it turned out to be surprisingly trivial. My friend also helped me test it, which made it a lot easier.
I know that JAWS support is still sorely missing from the plugin, and it's in the works. But that is a whole other can of worms, for another day.
Here's the link to my Road Map on Trello if you're interested in what else is coming:
UAP Road Map
a11yaccessibilityasset storeaudio gameblindnessgamedevindiedevmadewithunityTalkBackUnityunity3dVoiceOver
Unity Accessibility Plugin – Update 13 – How fast can you make an existing app accessible?
March 17, 2017 mikrima	1 Comment
With my plugin now in beta testing stage, I was wondering how long it actually takes to make an existing app accessible using the plugin.
So I did a little experiment.
For this test, I used a game from our company that had just come out of beta testing and was about to be released. Aside from some final bug fixes, the game was done and just waiting for the localization to finish. Not a single thought had been given to accessibility during development.
It took me a little less than four days to make it totally accessible.
If you want to skip the rest of this blog and just check out the game, you can download it here:
Crafting Kingdom on the iOS App Store
Crafting Kingdom on the Google Play Store
Maybe you have a game in mind that you'd like to make accessible and wonder how much work it would be.
Allow me to give you some additional context, so that you can put my result into perspective and draw your own conclusions.
The game I used is neither small nor simple, and has a ton of UI. It has a scrolling world map, over a dozen different locations with custom UI screens and dialogs, and almost each of them has a custom help screen. There are tutorial windows and statistics screens. In comparison, the Match 3 game I made had only a main menu screen, the game screen and a pause menu.
This map can scroll in two directions
And while this game has a lot of text, it also makes heavy use of icons instead of text labels. It uses 32 different resource icons, a coin image to indicate a price, an X on cancel buttons, a check mark on confirm buttons, an image of a left arrow to indicate a back button… The list goes on.
Many games use icons in lieu of text. Using images is prettier, uses less screen space, it makes the app playable by people who can't read, and it saves money on localization. It is a win-win-win-win for the developer. Really the only drawback is that it makes accessibility a little harder.
A screen full of information, but barely any written text.
But not that much harder. Adding accessibility text to an image is easy enough, it just means it isn't a one-click deal to add an accessibility component to the UI element and be done. You have to type in a name into the appropriate field of the accessibility component. For the product icons I had to modify the code to write the correct text into the accessibility component dynamically.
However, this particular game is localized in 12 languages, and I didn't want to break with that. So I had to generate localization keys in our database as well which slowed me down a little.
The optional Extra Mile
I also didn't just slap on the accessibility components and call it a day. That would have worked, but I knew that with a little effort the playability could be much improved.
For example, when a help text was useless for a blind player in its original form – e.g. "Click on the white house" – I created an alternate version of the text and had that read out instead.
I added in additional sound effects for extra feedback which are played only when accessibility mode is active. When a treasure chest appears somewhere on the map, a jingle sound will play. When the player cannot afford to buy something, he will be informed verbally that he doesn't have enough money. Similarly, the game will speak up and tell the player when the warehouse has run full. Sighted players are notified of this with an animated, bright red colored text at the top of the screen.
When a product is finished, a sound effect will be played.
Because this game has so many buttons and labels on the screen all the time, I grouped the UI elements by context, to make navigation a little quicker. The plugin supports up and down swipes (instead of the normal left and right swipes) to skip directly between groups. This means blind players can get to where they want faster, instead of having to cycle through every single UI element on screen. In a few dialogs I also set up a custom manual traversal order for the individual elements, because the most important information wasn't always at the top. For example, the game always displays the name of the location that you are in at the bottom of the screen.
In one screen I actually decided to change the interface a little. I added a new layer of UI which offered buttons where there was a slider for sighted people. In that particular context it was the better choice. An accessible slider wouldn't have given the same fine control to blind players as it gave to sighted ones in that particular context.
With all that extra work it stands to reason whether I could have been done sooner, had I just done the bare minimum. On the other hand, I know my plugin better than anyone else. The speed advantage I gained from that probably more than made up for the difference.
You know your games best, so you can judge whether my results are applicable to you. In any case, they are a good indicator of the general scope. It doesn't take months or weeks to make an app accessible. The work is more in the realm of days.
Just to be on the safe side – I am definitely not promising that you can make your game completely accessible within four days using my plugin. So don't sue me.
(Write to me for help instead!)
How fast you will actually be will probably strongly depend on my ability to write good documentation. That's what I am currently working on.
Afterthought: Not everybody does accessibility from the start, and that's OK
As a general rule of thumb, I'd say if accessibility is added in early in development, it will be a smoother ride for everyone.
If you do it from the beginning, you quickly get into the habit of attaching an accessibility component to every UI right when you create it. And you implement any additional feedback for blind players at the same time that you actually implement the features. At no time during development will you be more familiar with the feature's code. Thus, you are less likely to forget any special cases and can make sure everything runs smoothly in accessibility mode as well.
But in reality accessibility is often added later – possibly only after the game is finished. I really want to avoid saying 'accessibility as an afterthought' here in this context, which I stumble on a lot when browsing. It just sounds so negative. That's unfair to any small game developer who wants to put in the work to make their app accessible. They are trying to do something good and don't deserve to be berated for not having thought about it sooner.
Also consider this – everybody who adds in accessibility late in their current game might add it in early in their next one.
#android#iosa11yaccessibilityaudio gameblindgamedevindiedevmobilepluginUnity