The number rolls for changing items and the arrows for moving isn't a vital thing to maintain, for example i preffer using the keys a, w, s and d for moving when speaking about rotational games. I like using radar like a cane for moving, but the problem is sometimes the radar sound behing too loud, dificulting us to ear some other important things going on.

Damn you, Assault Freak. I was going to write the same thing, but you beat me to it. These conventions should communicate what we need to successfully play a game, rather than be guidelines to design the same interface for every game. *yawn*. I, for example, have envisioned a menu system for audio games where the menu itself is an actual area, and you walk around interacting with various objects to change settings and activate various functions, such as save or mission start. Establishing such conventions as illustrated in this setup would eliminate uniqueness of interface design.

Kai

This is not a definitive list, it is more of a way for developers who have never played an audio game to understand the norms that have developed around an audio game. It is like music theory, it is there, but only so novices can have something to follow and experts can have something to break. The blindness community is too small to have well meaning sighted developers creating content that is completely based on what they think a blind person would like. This list defines what is out there.

Well put, dark. Thanks for eloquently restating what I didn't do as eloquently! hahaha. These so-called norms on the list are things that, if all developers followed, we would end up seeing more of the same than if they went with their own ideas while consulting those people who are experienced gamers, preferably both with audio and video games.

@@roelvdwal I wasn't so much of conventions that would be features as simply of ways of doing things that might be idiosyncratic to the game.
For example, in captain dynamite and the fallen hero you perform the actions such as punch block and jump using the x c and z keys.
in the context of  rhythm action games these are pretty cool controls, all next to each other (actually I felt rather as if I were using a joypad while using those).

If however a developer is told "audiogames usually use control and space" we would have lost that.
Does it matter in the scheme of things? Well not realy, but the controls did make the game feel different to others.

Similarly, look at how spacebar is used in castaways to turn off the clock rather than to select things, and how castaways uses instant letter shortcuts as an alternative to the menu with curser keys to get to your different types of people.

Heck, if you want to see a game with about the least standard controls you could find, look at tube sim.

There are far more important things developers do! need to put into potential audiogame design around the audio interface itself, lessons that have! been learned from games of the past and would make major problems if they are missed, indeed frequently people complain if they are.

Consider how often a new developer comes up with a game and misses something like clearly indicating in audio the position of an enemy or other object, actually it seems one of the main mistakes made by some new developers is to assume that difficulty equats to simply by increasing the confusion of the soundscape, eg by throwing as much at the player as possible rather than giving the  more difficult problems of judgement and learning.
After all it's much better to have a game which is hard but where you know exactly how and why you died, than one where you die just because you can't hear what's going on under all the babble .

I'd therefore myself prefer to give developers the essential information on how to make an audiogame coherent and solid, and leave the nitpicking little details such as controls up to their own preferences for design in the game.

To my thinking, that is exactly the problem. Since the inception of audio games, particularly action ones, developers have relied on the same designs and conventions from the very beginning. How many side scrolling actions games have left and right for movement, jumping with the up arrow, space bar for the weapons, number row for inventory and h for health? The answer is pretty much all of them... whereas even the beat em ups from the 80s had slightly varying mechanics and controls, so none of them played exactly alike.

Area-based menus, as Kai said, are not designed to have things done quickly and have it be that. They are designed that way to help introduce the player to the game world, as well as to possibly aquaint you with npcs in the game. Shadow Rine has implemented this idea in the merchant system where you have to actually locate someone in the game world to enter a shop menu, whereas other games, in a less fun approach in my opinion, have a shop menu you can access from any time, anywhere. While it is convenient, it certainly doesn't teach me much about the world or immerse me in it.

Personally, I think if there is a how to document written for potential indie developers, it should focus more on relaying audio information and making information available to the player, while still having enough freedom for the developers to do what they want in the area of base game design and controls. For example, if a developer is considering making a final fight type game, aka a 2d beat em up, I don't want it to be another move left and right, hammer space as much as possible, press the number 2 to cycle to a different weapon, hammer space, then jump a pit,  rince and repeat. And the one key thing I would stres is ramping up the difficulty does not mean piling on more health for enemies or damage dealt by such, but more complexity in how enemies behave, or an increase in reaction speed from the player's part being required to finish something.

Not quite the same, imho, but that's interpretation, of course. It is natural to study what is done by others, yes, but that doesn't mean you need to start using their design as a base model. That having been said, I think your list is very, very general.. and it communicates a very different message than what I think you are trying to create. Your first post reads:

I have been asked by a group of developers to come up with a list of conventions we have in audio games. This list will help both sighted developers create applications for blind users and create a "what is normally done in audio games" document for Audio Games. It was asked for when my first thought to solve a problem was using special audio. Apparently that is not something most developers jump to when trying to create auditory based applications. This list will help bring to light assumptions Audio Gamers have when presented with an application. It is not an audio games developer guide, but it is a list of thoughts that go through a player's mind when they open an audio game for the first time.

I would say most of these are not thoughts that go through a user's mind when they open an audio game for the first time, rather they're a list of control schemes and design ideas held by some games, not by all, and the whole list reads in a way that suggests developers should take note of these conventions, when they don't really matter in the scheme of things. 3d games don't have to use the left mouse button to move, or arrows. They can use whatever the developer would like them to use.

One needs to center monsters in headphones and shoot them
Sounds from behind are muffled or lower in volume or pitch

This describes the first person shooter genre, and that is the problem with putting this as a convention... this will lead many to assume that is what has to happen in every shooter, which is why shooters in the audiogames market have become stale, because that is all you do. Center, shoot, center, shoot, center, shoot, center... etc etc etc. That is why even multiplayer shooters like RTR aren't enjoyable, because it boils down to who can center and shoot the fastest, which often boils down to luck. The definition of 2d and 3d games is also inaccurate, as is the assumption that all levels in 2d games have to start going right.

I'm not trying to criticize, just that there are better ways to create a how to document for creating accessible games. Game developers know how to make games, we don't need to tell them how to make them... because in the end, all an audiogame is is a game with no graphics. The only thing developers have to do to make good audiogames is ad auditory cues to relay normally visual information. the rest is the same as making any game.

This is something I've noticed a lot, A LOT in audiogames. Now, this can't really be an audiogame thing specifically, but what I've noticed is that, of late, story games are far less common and far less substantial. It's all about kill or be killed at a million miles an hour, and not like an RPG, where you can spend time on upgrades, buying things, etc. I think games that do that the best are the games by Aaron Baker, especially Paladin of The Sky and Manamon. I think his games introduce conventions that SHOULD be in the audiogames community, namely the well-developed stories and puzzles, customization and replayability. Again, I know this is not done by just one person, but we are becoming increasingly narrow-minded in this community, I think. We are so concerned with playing mainstream games now, which I do not object to in any way, that the games we can't play remain unplayable to us and people don't take initiative to make one for the blind similar to it. And now, I can see where you'd say,

@Frastlin, I looked at your audio graphs but I'm afraid I couldn't get any idea.
I found two buttons saying "pie graph 1" and "bar graph 1" and a message saying "please enter focus mode if using a screen reader to hear examples"

There were no mode switching buttons on the page I could find andAs far as I know Nvda doesn't have a focus mode, even in Supernova which used to call the virtual curser the "virtual focus" it's now called the dolphin curser so I'm afraid I don't know what your getting at though I'd be interested to see what representation your actually trying to achieve particularly with what you say about audio conventions, since I would've thought that for a project like this it would be more a of suggesting the groundwork for representing information coherently in an audio setting than the less critical matter of what control schemes or specific design models of gameplay were used in previous games, ---- eg it'd be important to understand how to represent using sound, but it wouldn't matter too much that say most space invaders audio games have not bothered with enemies who actually attack and have tended to use a smaller number of invaders on a more random movement pattern across  sterrio field to increase difficulty, as opposed to having a large number of invaders moving slowlybut attacking frequently as is the tradition in mainstream games.

As to the more general comments on game inovation, well I agree to an extent, however before everyone gets too much into the doom and gloom I will note that comparing the situation now to the situation ten years ago there is a huuuuuge! improvement in what is around and the sort of work being done, both within the community and from interested developers on platforms like Ios.

hell, look at the difference between something like Crazy party and the arcade games produced  five years ago.

Or consider that ten years ago we had no flight sims at all, now we have several, one of which even uses real world gps maps!

Yes, we do need things pushing further, and I still! want that audio Final fantasy game, but I'll say that it seems a lot closer now than it has been in the past, ---- another reason why I am afraid I am against the sort of conventions for control or game design mentioned earlier and would rather concentrate upon the important lessons of design.