Galactic Colonies – Accessibility Sneak Preview

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.

Screenshot showing a colony on a jungle planet, more than two dozen buildings, many lakes and part of the ocean

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.

Colony on an ice planet showing a warehouse receiving food from a farm and distributing it two connected houses

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?)

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.

Dark haired woman holding up two bags full of money with a satisfied smile

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


					

Unity Accessibility Plugin – Update 12 – Release Date and Anniversary

Roughly a year ago I started work on the Unity Accessibility Plugin. That doesn’t mean I have been working on it for one year – far from it. I honestly have no way of telling how many weekend and evening hours went into it. (It was a lot, though.)

Which is why I am a little excited to see that the plugin is finally so close to release!

What’s the holdup?

If you’ve followed this blog a little, you might remember that I already released a game with the plugin.

It might seem counter-intuitive, but having released a game with it doesn’t mean the plugin itself is ready for release. It’s one thing for me to use my own plugin, and another to have the plugin usable by others. It needs rigorous testing, documentation, a nice UI, demo projects and a support forum. And then everything needs to be bubble wrapped and uploaded to the Unity Asset Store.

When?

I hate disappointing people. So I won’t give an official release date. I couldn’t anyway, even if I tried.

Remember the old saying that the last 5% of a software project take 95% of the time? And I still need to do actual (I mean paid) work, too. It is impossible to predict anything with any reasonable certainty.

WHEN???

Ok, so here’s the jist.

The documentation just isn’t done. There’s not actually all that much left to do on the code before the initial release. Oh, yes, I have a long list of things on my wish list (from localization to Braille support) – but all of those are merely nice-to-have features that can wait until after release. The documentation can not.

Documentation, including at least one tutorial video, needs to be there from the start and it needs to be good.

I’m also in the process of finding a few developers that will beta test the plugin (and documentation) with their own projects. I don’t know how long that will take, either.

Sooon…ish?

So that’s where things are at and that’s why I can’t give a release date prediction. If you’re a developer, you probably understand this anyway, buy I just felt like I should explain why I am so evasive when asked for a date.

Unity Accessibility Plugin – Update 11 – Editor Accessibility vs App Accessibility

About once every month I receive an email or Twitter message asking – usually outstandingly nicely – whether my Unity Accessibility Plugin will make it possible for blind developers to create games with Unity. It’s happened often enough that I think it warrants a short post to clarify what my plugin does, and what it does not do.

On the left side is the logo of the Unity Editor, on the opposite side is the Made-With-Unity splash screen that is displayed when starting games created with Unity. They look almost identical.

So similar and yet so different.

It’s a screen reader

In a nutshell, the plugin is a screen reader, specifically tailored to work with apps and games created with Unity. Neither VoiceOver nor TalkBack can recognize the UI elements that Unity renders, so all apps created with Unity are automatically inaccessible otherwise. The important part is that the plugin makes the apps created with Unity accessible, not Unity itself.

It does not make Unity itself accessible

The Unity Editor – at least on Windows – is not very accessible to screen reader software. NVDA will read the menus and the names of the individual panels, but nothing else. JAWS apparently fares not much better. For development, this is useless. This particular plugin doesn’t change that, unfortunately.

However…

Experimental accessibility for the Editor

A few weeks ago, over Christmas, I was playing around with making the Editor itself accessible. Inspired by a blind developer who wanted to use Unity to make a Go-Fish game I started to create a plugin that adds accessibility functionality to Unity. But this project is so early in its infancy that I feel almost uncomfortable writing about it at all.

Currently, this plugin adds keyboard shortcuts to read out the errors in the console, it plays sound effects when entering or leaving game mode, and notifies the developer if the compilation fails. It let’s the developer tab through the game objects in the scene hierarchy, reading out their names, how many children they have and reads out hints on how to add new children. It also makes the project view a little more accessible, reading out the names of files and folders.

But I haven’t found any solution for managing the components on a game object. Unity’s Inspector window supports keyboard navigation, but I can’t find a way to query what is currently highlighted and focused, so that I could tell NVDA (or any other screen reader) to read it out. Managing components and their values, usually in the form of prefabs, is probably the most important core feature of Unity. That makes this a major road block at the moment

Interested in joining the project?

In a finished version I would love this plugin to allow blind developers to do as much as possible with the Editor, including the creation and management of prefabs. It should also be possible to create builds for the various target platforms. And it should include all kinds shortcuts to make the most common tasks quick to do. And I would also want it to include a stack of documentation and tutorials on how to use Unity and create games with it without sight. Then throw in a demo project or two. All neatly wrapped in a free, easy-to-download-and-install package.

I would love to see this work. But I am enough of a realist to know that I don’t have a lot of time left over to put into this – at least not while I’m still working on the other accessibility plugin. If I tried to split my time between the two, neither one would ever get finished.

For that reason, this is an open invitation to other developers willing to help with this. I’d be happy to put what I have up on Git Hub if anyone was interested in joining in.
Just contact me: michelle@metalpopgames.com