2019-07-12 03:37:20 (edited by daigonite 2019-07-12 17:31:05)

Discord server: https://discord.gg/6Nu7U6Z

(Please only join if helping build specifications. This is not a generic audiogames.net server. I'm also inviting outside developers to encourage discussion.)

Hey there everyone, this is a thread I'm making where we can talk about establishing blind accessibility specifications in gaming.

I'm currently building a framework right now called maxseer that helps developers automate accessibility, but I only know about making top down games like JRPGs accessible. maxseer could probably be used in a game like Pokemon or maybe even a first person shooter, but it has some limitations. maxseer is currently only in monogame but I'm going to start building a game maker version this weekend, and hopefully eventually Unity as well. But I'm going to need to eventually migrate attention back to my game. The nice thing about maxseer as well is that it's open source and free to use so that any developer (especially indies) can easily implement some level of blind accessibility into their games.

I think we need to gather our knowledge together then, and establish a specification. I can continue to develop maxseer in its current form, but the specification can also allow me to develop accessibility for games that I normally don't build (such as platformers for example). We should also be focusing on automation, things that we can build a framework around, although having non-automated components or semi-automated components is acceptable.

In this specification we really need to establish on an abstract level what the game needs to do in audio in order for it to tell the player vital information that is usually only visible to the player. We also need to make sure our solutions minimize impact of the non-accessible player experience.

The only "specifications" that really exist are weak guidelines that don't really offer much value to the developers. I think having both a specification and an open source framework to use as a guide will help blind game accessibility tremendously, and it has the bonus of being a community based, non corporate owned project that we all contribute towards.

The problem is, I'm not a very technical guy in regards to organizing people and I was thinking we should talk about our ideas first before we start building a system for establishing a means of action. So I made this thread to talk about it.

Let's actually do something about game accessibility for once, this forum has been around for like 20 years, surely we can figure out something

By the way, here is a list of the main components of maxseer. This is mostly something that would be helpful in top down games. But insight on how other styles of game work would be very helpful.

- Proximity detectors, which are a set of detectors that surround the player. As they approach collisions, the detectors get louder as they get closer to the player.
- Footsteps, which trigger at regular intervals for calculating distances
- Sound Emitters, optional but allow for more immersive environments
- AXLabels, which are labels that as a player approaches them it reads off text
- Pathfinding, which allows a player to find a location from their current position.

There is also a menu prototype as well, that reads off TTS text as you navigate the menu. (there's also a keybinder project but it's not exactly related to blind accessibility)

EDIT: Oh i was just thinking, a specification is a good idea as well because while maxseer can provide some level of automation, it can help explain how to do semi-automated components such as linking up maxseer's TTS engine with a developer's text box engine.

Demo of colors here (PC) (Gamejolt link): https://gamejolt.com/games/ColorsChromatics/248621
Braillemon last release(stable): https://www.dropbox.com/s/v4n08tale65w8 … 0.zip?dl=1
maxseer, blind accessibility automation kit for developers: https://forum.audiogames.net/topic/2970 … -monogame/

2019-07-12 03:48:24 (edited by Ethin 2019-07-12 03:51:42)

When we're ready to determine the writing of the spec, I'd be happy to create a git hub repository for it so that we can develop it all together. Before we do that we need to agree on some kind of approval process for contributors. Naturally, the spec would also follow the Contributor Covenant. We'll also need to select individuals who will act as maintainers so that I'm not the only one managing the repository. big_smile

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

2019-07-12 07:22:23

I already have a repo for maxseer, would that work? It's written in c# for monogame. But it only contains the parts that are fully automated. There's already a bunch of wiki documentation I've written for the current engine.

Some elements will require the dev to add some implementation (such as menus). I can build prototypes but I doubt them being used in large custom projects. They serve better as templates to grasp the design.

FYI, I'll also be making a game maker port, to at least encourage some accessibility. But I need to shift gears into game development by the end of august. So the goal is to have something people can experiment with.

While I'm designing the game, I'll be taking note of the accessibility features I implement so I can at least provide that to help provide standards for those kinds of games (jprg style games)

I'm not sure of anything with verifying contributors. I would need more input from others. Might talk to my other dev friends.

Demo of colors here (PC) (Gamejolt link): https://gamejolt.com/games/ColorsChromatics/248621
Braillemon last release(stable): https://www.dropbox.com/s/v4n08tale65w8 … 0.zip?dl=1
maxseer, blind accessibility automation kit for developers: https://forum.audiogames.net/topic/2970 … -monogame/

2019-07-12 07:30:38

@3, yeah, that should probably work. We can create a separate branch to hold the specification, or even throw it on the wiki.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

2019-07-12 10:37:58 (edited by frastlin 2019-07-12 10:44:05)

Eventually this should be its own repo, but for now, it can dovetail on another project.

I have broken down Audio Game interfaces in my master's thesis.
What it comes down to though, is following established user experience heuristics, such as Jakob Nielsen's 10 heuristics.
We just need to give ideas on how each area relates to games and what is normally done. Each of these areas should be debated and commented on. Here is my initial set of thoughts:

Visibility of system status

In audio games, there are several system status messages that should be conveyed:

1.    Is the game running. This can be done through music or environmental sounds, such as the guards shouting outside the safezone in Swamp.
2.    When the user first logs in, there should be some recognition that something happened. This is done through a status message, such as the message in Swamp or Survive the Wild.
3.    When the user is moving, there should be some kind of feedback. This is often done through footstep sounds, such as in Swamp, or engine sounds, such as in Cyclepath.
4.    Barriers. There needs to be something that tells the user they can't go in a direction. Adventure at C does this very well by repeatedly making a sound when the user hits a wall. The problem with Adventure at C, is that new users may not understand that the knocking sound is actually hitting a wall and not a footstep (I showed adventure at C in a workshop and someone spent 5 minutes running into the first wall in the tutorial level). Swamp makes one hit sound, and the footsteps stop. People who don't know they should be hearing footsteps don't realize they can't move, they just think the game is broken. So I have used a "uh" sound coupled with another sound and every person I have shown the interface to seems to get that is a hit sound, especially if they are told once that is a hit sound.
5.    Pressing keys, such as "h", to hear your health and "g" to get items on the ground. Messages are read through the text to speech.

Match between system and the real world

Sounds should be as close to the real-world as possible. Mario is a famous example where the sounds were too abstract for people to understand without playing the game. Yes, the themes were very distinct, but it did not make sense without playing the game. In A Hero's Call, there is the sound of water when you get near water, there are the sounds of fires if there is a camp fire. They use auditory Icons (sounds that are of real objects) to represent a data point, like a camp fire, in the game world. Sounds that are just beeps and buzzes are OK, but they take a while to understand. A good example is the navigation system in A Hero's Call. Doors have a particular sound that take a little while to understand, but it is very unobtrusive, not like the doors in Manamon, that sound like doors, but I don't want to stand by a door and listen to it for more than a couple minutes.

User control and freedom

Menus and dialogues should not be super hard to exit out of. Menus have existing conventions, such as up and down arrow keys to move through items, enter to select an item, and escape to go back in the menu. Dialogues need a way for you to repeat the message, go forward through the messages, and preferably go back through the messages (escape is also used to close messages). The game itself has a menu where you can save, load a game, pause, and that is gotten to by pressing escape.

Also, for speech, I have found that players prefer to use their own screen reader most of the time, rather than the system voices. There should always be a self-voicing feature, but screen reader access should be an option.

Consistency and standards

The second chapter of my thesis and this ICAD paper talk all about conventions within audio games and each interface type. For tree interfaces (or menus), up and down arrow is used to move through items (except in some games that use left and right arrows), escape exits out of the menu or goes back, enter selects an item, there is often first-letter navigation, page up and page down jump by 5-10 items, and home and end jump to the top and bottom of the menu. There is also something (either a voice saying "top of menu" or a sound that plays, and the top item repeated, so you know you're at the top or bottom of the menu.
Each interface has its own conventions, and these should be followed.

Error prevention

Many developers think that hitting a wall in an audio game is an error, and this is not necessarily the case. Games like Entombed and Swamp, make wall hitting part of the experience. A Hero's Call and Manamon do a great job in warning users before they hit a wall, that there is a wall coming up.

For lava, or something of that nature that users should not step on, there is a warning of generally two steps that means "danger". Adventure at C and the Gate do this very well.

Also, important messages should not go away in a button masher if you press a button. Enter and space generally mean "accept, but if someone is pressing space to fire a gun, space to accept a message while they're firing is not a good idea.

Recognition rather than recall

Part of this is using iconic sounds of the environment rather than symbolic earcons (beeps and buzzes) for entities in the world, but also, instructions should be present at the end of the important information. For example, if there is a dialogue, the system should say the dialogue, then after the important information is done, a message like "Enter to continue, r to repeat" should be said.

Flexibility and efficiency of use

Menus should give you access to almost everything. Tactical Battle is an excellent example of this principal. You only need to know to press enter and arrow keys to play the game. Everything can be retrieved through the menus. If there is a key shortcut, it should be placed at the end of the menu item. "Attack, A". The readme should have a key commands section as well, and there should be a keymap, like Swamp has, where users can change key commands if they wish.

Tutorials and cut scenes should be skippable when you press enter.

Aesthetic and minimalist design

When users press "h" for health information, it is better to say "55 health remaining", not "You have 55 points of health remaining". This keeps the important information at the front so users can interrupt the message once they have the "55", if they know that is the important part. Also, don't have so many key commands to start playing. Tactical Battle is great with minimal key commands, and Survive the Wild takes a while to learn what you need to take a drink.

Help users recognize, diagnose, and recover from errors

If the user is doing something that they should not be doing at that time, let them know that is a feature, but they should be doing X instead. Also, if users do the wrong command, like trying to drink a rock, the message should indicate what kinds of things you can drink from: "Drinking that would be difficult. Perhaps water would be better." Or if you need a cup to drink from a fountain,: "Drinking from that would be unsanitary. I should find something to put the water in first."

Help and documentation

Unlike most mainstream games, many Audio Game players expect a readme. This should be included in any game, but there should also be in-game help messages and an in-game tutorial to help users get familiar with the game. If users are doing something wrong, like repeatedly hitting a wall more than 10 times in 5 seconds, then it would be helpful if a message said "You're hitting a wall, it, you should probably go the other way or figure out how to get past the wall".

Thumbs up +4

2019-07-12 10:47:23

BTW, this maybe should go under developer's room or game discussion.

Thumbs up +2

2019-07-12 13:51:45 (edited by daigonite 2019-07-12 15:37:07)

Thank you so much for your input Frastlin. Also you're right, these specifications should be separate from a project that just gives a solution.

What I could possibly do is try to consolidate my knowledge of top down JRPGs to combine with the concepts in your post to establish structural standards. Your thesis will be extremely helpful helping clean out the edges.

One thing I've noticed in particular with communicating accessibility is that a big problem is that ideas are given, but not specific, technical solutions to problems. So combining your thesis with more technical specifications is definitely the route to go.

I'll write more when I get home from work tonight.

By the way I still have no idea how we should manage things like contributions and stuff. I know there are definitely some members here who would provide a ton of benefit but we need to establish a means of allowing contributions...

And can someone notify a mod about this so it can be moved in the right section? thanks...

Edit: I made a discord server, since discord is doing a lot better with accessibility now.

https://discord.gg/6Nu7U6Z

Please only join if you're interested in discussing specs. Also please announce who you are so we know your identity.

Demo of colors here (PC) (Gamejolt link): https://gamejolt.com/games/ColorsChromatics/248621
Braillemon last release(stable): https://www.dropbox.com/s/v4n08tale65w8 … 0.zip?dl=1
maxseer, blind accessibility automation kit for developers: https://forum.audiogames.net/topic/2970 … -monogame/

2019-07-12 16:03:45

Hello folks. Well, from my experiences, the kind of sound used for the game design is more a matter of choice from the devs. In regards to accessibility, the sounds have to be distinct enough so you can know what is happening. A know the game sounds menu can help with the learning curve, but I personally don't see realistic sounds being a requirement.
Best regards, Haramir.

The true blind is the one who refuses to see.

Thumbs up

2019-07-12 18:44:10

While optional, specifications give an in depth analysis of tools devs can use. Currently most of what's passed around on twitter are just cute protips, not enough technical design to really give it that much meat. So we need to establish a better set of specifications than "it helps if you do this"...

Demo of colors here (PC) (Gamejolt link): https://gamejolt.com/games/ColorsChromatics/248621
Braillemon last release(stable): https://www.dropbox.com/s/v4n08tale65w8 … 0.zip?dl=1
maxseer, blind accessibility automation kit for developers: https://forum.audiogames.net/topic/2970 … -monogame/

2019-07-14 15:41:59

I think a github repo would be the best. You can give people who are willing to significantly contribute access to the repo without approval, then if people want to debate particular aspects, like the sounds, they can open an issue with a proposal for what should be there instead.
Then the contribution list can just be a list of Github names or audiogames.net names.
Do you want me to make the repo or do you want to?

Thumbs up

2019-07-14 15:45:06

I think it should be like that post on heuristics I linked to above. There is a brief description and then a link to more detailed examples. WCAG is also formatted in this way.
Higher-level concepts followed by code and sound examples.

Thumbs up

Today 13:59:32

I just saw this, it is a set of specifications or "wishes" that games should do to be accessible:
https://www.specialeffect.org.uk/access … -wish-list

Thumbs up