Development trade offs in Cellular City's audio description system

Following on from last week's blog and GAconf (which had a bunch of excellent talks on all things game accessibility!) I've been looking at Cellular City's text to speech (TTS) and audio description design. This has resulted in a few bug fixes (like to the voice selection UI) and a new button “read” which a player can use to have the level described to them at any time.

Two ideas for further development which have come up are:

1. Recorded voice over rather than TTS
2. “Inspect” option to help build game feel

These are each aiming to improve different aspects of the game experience while playing with audio description. This post talks about potential conflicts between these two features and how those conflicts could be worked.

Recorded voice over:

Recorded voice over is being considered for three reasons:

• TTS systems aren't particularly clear when reading level coordinates like “A1”.
• Godot's TTS system hooks into the platform specific system (windows or HTML). These systems are often quite slow, with a few problems being encountered with differences in how different platforms parse multiple calls.
• Vocal performance could be added, to help build game feel through the speech.

There's not that much text present in the game, nor a large variation in the words needed for description of levels (at present ~20 clips needed for menu items, 26 needed to voice tiles and buildings), which seems reasonable to record. Additionally the computer generated TTS could exist as an additional option for if the voice-over wasn't sufficiently clear.

Inspect button:

A button players could press to prompt a description of the building the cursor currently has selected (both in level and in the Guide UI), with these descriptions being available in text form from the main menu (think a glossary of buildings) potentially including some of the history of the real world buildings which inspired them.

This feels like a good way to make the game world more accessible, rather than just the raw mechanics, something which is currently lacking.

The problem: incompatible constraints 

The development problem is that recorded voice over could potentially be made into too high workload to implement by the need for descriptions. The longer text segments are the primary concern as I'm not a voice actor nor am I experienced with recording audio, so there's a significant potential for unclear speech, particularly if descriptions need to be redrafted. 

Potential workarounds:

1: Use TTS to voice descriptions so they don't need to be recorded.

While this initially looks like a good solution it creates two problems: first swapping between voices (i.e. pre-recorded to computer generated) can be grating and this probably isn't a good experience. Second duplicate options for the pre-recorded and computer generated TTS would be required, as players might want to adjust their settings individually based on different recording volumes etc.

2: Delay description recording until descriptions are “locked”

This would go some way to reducing potential re-recording work, although not all of it. My main hesitance over taking this route is it would create a barrier (in access to descriptions) where previously one didn't exist, with this barrier then being removed at an indeterminate point in the future. In the case of solo development this is probably fine, but in a studio context might cause a barrier to slip through as it involves the scheduling of multiple teams.

3: Accept the additional scope, reduce scope elsewhere.

This is probably the solution I’m going for, but it requires me to meaningfully plan future development, which I haven’t done yet, as i don’t actually know what other parts of development could be reduced to meaningfully enable this change.

Next time I’ll be chatting about improving the user experience of the settings menu, running out of buttons and designing the first proper playtest and its goals (There's also a bug fix coming for controller sensitivity).