2019-04-14 15:00:36 (edited by ianhamilton_ 2019-04-14 15:08:28)

There is a bit of variation in the approaches that developers taking their first stabs at text to speech have taken.

It ranges from simply reading out the name of menu items that are highlighted all the way up to Minecraft's approach of replicating standard screenreader level of verbosity; screen titles & headings, label/role/state for all elements.. telling you what page you're on, wether what you're highlighting is a button or a slider or a checkbox, wether it is part of a list, etc.

The purpose of this post is to pass on a question from some developers who are pondering what kind of end of the scale to aim for themselves, is a Minecraft approach what you're after, the same level of detail you would expect when using an app or a website?

Or given game UI's often simpler nature than something like a website, is that too much detail, detail that gets in the way of efficient navigation?

Would you prefer multiple navigation modes like on a screen reader, or is that overkill for game UI?

Thumbs up

2019-04-14 15:06:59

I think just speaking titles would be ok.

I post sounds I record to freesound. Click here to visit my freesound page
I usually post game recordings to anyaudio. Click here to visit my anyaudio page

2019-04-14 16:09:08

I think this really depends on the game. Just saying the highlighted item name is, I think, not enough verbocity. At minimum, what I'd like to know is the title of the menu/screen I'm on when it opens, and then the name of a highlighted item as well as its selection or state. If there are multiple tabs that can be switched between with bumper buttons on a controller, which is somehow indicated visually, then it should also be indicated with speech (even just saying something like page 1 of 3 would be enough I think.) And maybe sometimes knowing what kind of item something is might be helpful as well - For instance, some games just put things like music/effects volumes or graphic detail settings as sliders, so you can just use right/left to adjust them. But then some other games put them in as sub menus, so I'd want to know if I'm dealing with a case where I might first need to press A before I can adjust an option.

Finally, there's the problem with additional text. If I'm on a screen giving me a yes/no prompt, the screen reading should read that additional text when the dialog opens, as it may be important. And sometimes you have additional screen tooltips that change based on what's selected, which might give equipment stats or explain what an option does. These should also be spoken.

<Insert passage from "The Book Of Chrome" here>

Thumbs up +1

2019-04-14 16:31:47

Personally, the only indications I'd like are if the options are different to standard press to move to the next menu-type menu items (sliders, on/off toggle buttons though these are much less common, left/right menus as opposed to up/down ones if the rest are up/down etc).  This information could be conveyed differently, i.e. through just a quick audio cue panning left/right or the other way round to indicate your navigation arrows have switched, or by the words "left right" being spoken.

However, in terms of overall accessibility, having more options is always a plus.  Maybe just have it as part of the accessibility setup ("read element types", or "menu narration level" settings could go a long way to achieving this).

I just want to get into tweaking my game to how I like it then playing it rather than having to listen to large amounts of extraneous text, though said text could be useful to somebody else.

Sightless Kombat.
***If you wish to refer to me in @replies, use Sightless***

Thumbs up

2019-04-14 18:42:04

I prefer minimal verbosity; that said, there are some elements of game UI that we need to know exists. I think others have covered them like tabs, whether to press A to be able to choose options, etc.

I felt the wind of your passing
        is preferable to
I felt the passing of your wind

Thumbs up

2019-04-15 08:13:13

I think this depends on different types of games.

For example, in the fighting game, it is fine if menus and character list is being read. but the same thing wouldn't work on something like a tactical rpg.

Aside from that, all other topics have been covered by others already.

Thumbs up

2019-04-15 18:37:36

Thanks all, anyone else have any thoughts?

Thumbs up

2019-04-15 18:51:18

Post 3 pretty much covers my thoughts on it. I think verbosity choices are good as well, however.


Thumbs up

2019-04-15 19:10:43

Also any thoughts on speed? E.g. in this video from sightlesskombat the xbox system menus set to super fast, but the menus in the game itself are locked to a low speed


Thumbs up

2019-04-15 19:34:59

I would personally be ok with a locked speed to lessen the work for developers in building their own TTS systems, but others may differ in opinion. If it isn't information that needs to be processed quickly like menus or static dialogs, then one speed should be fine... case may differ if, say, it's a ine of text that updates in realtime.


Thumbs up

2019-04-15 20:47:16

as fast as possible.

I felt the wind of your passing
        is preferable to
I felt the passing of your wind

Thumbs up

2019-04-16 00:02:31

@10 as always don't worry about what may or may not be excessive dev effort, they can decide that themselves smile What's useful for them being able to decide that though is knowing what the ideal scenario from a player's perspective would be

Thumbs up

2019-04-16 01:17:23

Okay, so here goes. If you're using a text-to-speech engine, let the user choose the speech rate. I personally don't like extremely rapid-fire speech, so I'd personally want it to be a little faster than the average human speaking rate, but not cranked all the way up.

For menus and screens, speak the title of the screen as it opens, as well as what is selected. This could include the status of a list, the currently selected item in said list, or whether a box is checked. When moving around, speak the new information once it gains focus. The role information like button, checkbox, etc is not strictly necessary. If it says checked or unchecked before the items, that works.

There should also be a way to speak static information that may be on the screen. Perhaps this could be done with a keystroke or button? Let's also not forget to speak all important text that may appear in the game which may include story text, and various pieces of status information like health or ammunition.

Honestly, get some of these developers to play a few audio games and most people can get the idea really quickly. It's not incredibly complicated, we just have to educate people. Speaking of which, can you convince some of these developers and studios to register on here so that we can have a discussion? I keep reading these random topics, but nothing seems to be done.

Grab my Adventure at C: stages Right here.
You may access my NVDA Remote, Three-D Velocity, Sound RTS, and Road to Rage servers by using the address christopherw.me. Road to Rage uses the default 6789 port.

Thumbs up

2019-04-16 01:29:59 (edited by ianhamilton_ 2019-04-16 01:30:32)

@13 plenty is being done, games take years to make though!

I used to send people here all the time but stopped after some unfortunate perspectives that I didn't really want devs to be exposed to.

Also - thank you for your post

Thumbs up

2019-04-16 01:34:43

my question is, for rpg's how would the health bar be shown? lets say you just finished a battle how would you know what your health is at. would it be beeps like the progress bar in NVDA or speech? how would you tell your health bar from your other party members? how would that work for fighting games?

Thumbs up