An Interview With Azura Sun About Accessible Video Game Design

Sol is an open source video game for Windows and Linux developed by Azura Sun. According to the website, it will be released without DRM, allowing for custom modding and expansions. Sol places a huge emphasis on accessibility, allowing the player to zoom in, remap buttons, and have the menus and dialog read aloud via a text to speech engine with SAPI 5.

Sol is the only video game on the market, at the time of this writing, that has text to speech, aka TTS, within the core options to aid a visually impaired player navigating the menus and the cut-scenes.

TechRaptor: Why did you want to make a video game that’s accessible? What made you decide to work on accessibility from the beginning?

Azura Sun: There’s no reason to needlessly exclude people, so I considered accessibility a priority for Sol. Mind you, originally it was just the easy stuff (key remapping, difficulty levels, volume sliders, etc.), which makes it impressive how the more complex features actually manage to fit in (one-switch and mouse mode were afterthoughts and in fact just simulate inputs, and screen reader support was added in the last month of development).

TechRaptor: Why choose to make a PC game with text to speech instead of a console game with text to speech?

Azura Sun: Consoles are a walled garden, and as you may know, Sol is libre software (more specifically under the GPL 3), so consoles were out of the question. Computers are open platforms though where you can easily run any software you want, so that’s where we went.

TechRaptor: For those who may not know, can you tell the readers how the game interfaces with SAPI 5?

Azura Sun: SAPI is the speech software that comes with Windows. The game simply communicates with SAPI by passing the text it wants to be spoken, and SAPI takes care of the rest. On Linux, the equivalent would be Speech-dispatcher.

TechRaptor: Can you describe the challenges of getting a SAPI 5 voice to read the menus and dialog?

Azura Sun: SAPI is easy to use, at least if you just do the basic stuff (speak and shut up), which should be enough for most games. Speech-dispatcher on Linux is just as easy to use, certain quirk aside.

The only big catch is that symbols aren’t spoken. You can tell the speech engine to speak punctuation, but that still won’t help you with symbols like arrows, and definitely won’t work for custom codepoints (Sol needs them for the mouse symbols in the level editor’s help screen). In this case you need to replace the symbols with the text you want them to represent before passing them to the speech engine.

TechRaptor: How could this be done on consoles, in your opinion?

Azura Sun: Just provide a similar interface like SAPI or speech-dispatcher, really. And maybe a setting so games can know ahead of time whether self-speaking is needed or not (since games on consoles can’t show a launcher like Sol does on PC). I know there were some accessibility updates lately, I don’t know how far they go however.

TechRaptor: There’s a lot of talk from developers that say making a video game accessible is a lot of hard work. Where does all the hard work come from? Is it just the extra code, or testing the game, or something else?

Azura Sun: It really depends on the situation. Some stuff is easy (e.g. key remapping is just a matter of not hardcoding the keys), some stuff is tricky (e.g. a one-switch mode like in Sol requires coming up with a whole new and heavily limited control scheme without messing too much with the gameplay).

In the case of screen readers though it’s a mess. The interfaces available are oriented towards “normal” applications (buttons, text fields, checkboxes, etc.) which can make it harder for games to use. On top of that, whatever creates the window has to provide the relevant information - and this is usually the middleware, which means the only reasonable way to do it is by having the middleware itself support screen readers (and currently they don’t, sadly). This makes screen reader support a pain to implement due to poor design decisions, this is why games usually resort to speech engines or to hacks like copying the text to the clipboard for some other program to grab.

So yes, for some things accessibility is indeed hard. If middleware vendors decide to implement screen reader support, and operating systems start providing easier ways to talk to screen readers directly, it would be much easier to do for game developers.

TechRaptor: Can you tell me why you chose to have TTS reading dialogs AND menus rather than just reading dialogs OR menus?

Azura Sun: If you enable TTS it usually means you need it to be able to read text in general, so it only makes sense that all text is exposed this way. I honestly never thought that somebody could even consider otherwise. In fact the level editor kind of lags behind (TTS support was added at last minute) so if something critical was missed that really needs to be addressed in an update.

It probably matters that cutscenes in Sol are text-only (no voice acting). At some point I considered altering the voice of the speech engine to match the characters speaking in the cutscenes, but people didn’t like that idea.

TechRaptor: Why is the game open source?

Azura Sun: Because we want to encourage libre software (and discourage walled platforms), and one of the most common arguments against it is that it’s hard to do it commercially, so in Azura Sun we have set ourselves to prove this wrong, even if we’ll have to experiment if things don’t go as planned.

Also looking at it from a different viewpoint: it’s already known that you can be successful with DRM free games. Since DRM free effectively removes all barriers to mass sharing, why not just release the source code as well? It’s not like you’re risking much more by this point. On top of that, it provides with the way to do the most complex mods possible, so it has obvious benefits besides any moral ones.

TechRaptor: What tips would you give other developers who want to make a video game accessible?

Azura Sun: Definitely consider the easy and obvious stuff, they can be easily done on just about every game and will help a lot of people, disabled or not. For the more tricky stuff like one switch mode you’ll probably want to consider carefully how you would design it without altering the core gameplay.

Also please consider making an accessible game, not a game for the disabled. Imagine you make a game for the blind, what happens if a blind player wants to play with a deaf friend? Also most of the time designing for a given disability tends to result in dull unimaginative ideas, better to figure out how to adapt your existing ideas to make them accessible, your players will be glad for it. This is what we did with Sol, we refused to water down the gameplay at all costs.

We would like to thank Azura Sun for their time with this interview.