[games_access] GAIM 0.02 updated

[AudioGames.net]

Hi,

Well written, Eelke!

*quote*
1) some of the requirements assume absolute validity but are actually only 
applicable in very specific contexts; take the "provide audio cues to visual 
information". A requirement as such does not make any game accessible to the 
blind automatically.
2) There are too many (requirements);
3) Another thing that I think is lacking with guidelines is that is does not 
specify what problem it actually solves, why it works or how it can be 
implemented.
*quote end*

I fully agree. This is why I have been so stubborn with accepting the 
requirements/guidelines defined so far. There simply is no link with the 
actual practical implementation. I also propose to drop the term 
'guidelines' - which is too fixed in my opinion ;). Patterns are that link 
to the practical, but I do think that patterns are only part of the 
solution. At the moment (but this may change in the future) I believe a 
healthy mix of heuristics and patterns is key. The patterns are (now), as 
you say, of a somewhat lower level than the high level game design and 
target software engineers. But I think it is important to target all 
disciplines within game development. Throughout the development of a game, 
decisions are made and it is important that for every decision that is made, 
accessibility is taken into account. So this includes targeting the high 
level designers (which would be targeted with "accessible game design 
patterns"), but also lower level designers (like the interface designers 
("accessible game interface design patterns") and the audio designers 
("accessible audio design patterns") - which would probably overlap ;) ). 
And even up the the marketing department ;) . I think that it is possible 
that a game designer creates a concept for a game that is very accessible 
because of using accessible game design patterns, and that other designers 
do not need patterns because of this. A game idea that revolves around the 
speech of the gamer, for instance, makes it very accessible for all sorts of 
gamers, because there simply is no physical or gestural input needed. Of 
course, there will always be the problem of what is accessible for one is 
inaccessible for the other ;)
If this is possible with patterns, than I'm all for it. I do not have that 
much experience with patterns so far, but from what I know I get the feeling 
there are limitations/obstacles with patterns. One is that I foresee that 
there can be as many design patterns for game accessibility as there are 
usability design heuristics and that number would grow as time progresses. 
That may not be practical. I also think that not all problems can be 
captured in patterns - or at least that it is very hard. The higher level 
you go with defining patterns, the less simple it gets. I think that a big 
part of game accessibility revolves around 1) input and output interface 
problems and 2) game difficulty problems. But there is still that one other 
part which is so hard to grab and that is the issue of trying to keep the 
game essence in tact and keeping the game fun for all while implementing 
different accessibility features. This requires, I think, the highest level 
of heuristics or patterns or... .

A concept I was recently introduced with and I think that may apply to this 
all is the concept of Strategy. There's this hierarchy of (Design) Goal, 
(Design) Objective, (Design) Strategy, (Design) Tactic and (Design) Task. 
One has a certain Goal (for instance "make all games accessible 
(controllable, perceivable and fun) for all players"), which is broken down 
in a certain Objective ("make Bejeweled accessible for color-blind gamers"). 
The Strategy is the Plan to achieve this Objective, which is broken down in 
conceptual actions called Tactics. So a Strategy is a collection of Tactics 
in a given context, the Objective. A Tactic is implemented as one or more 
Tasks.
While the theory of heuristics and patterns and guidelines is not so easily 
transferred to this hierarchy, you might say that a Pattern captures the 
Tactics and the Tasks. Heuristics would to, but not on a practical level? 
However, Strategy is where one designs which route to take, which 
Patterns/Heuristics to implement. This is decision making to and I think it 
is important to define strategies too. For example, the problem for colour 
blind gamers with information that is communicated with colour 
communication, can be solved with either alternative colour/contrast schemes 
or alternative parallel information communication, such as distinctive 
shapes. These would be 2 patterns. A design strategy would describe the 
problem and describe the two patterns (tactics), but also discuss which 
pattern is best in which context. I guess you could capture a strategy into 
a pattern too (since, how I've understood it, you simply make up your own 
pattern language to include strategy information). I consider strategy to be 
a path which links objectives to implementation - and I think it is 
important to define these too.

K... I wrote this very quickly and gotta go now so sorry for any vague lines 
in there, but I'm interested to hear what you think of this and if this may 
lead to something better or if you think this just makes it more difficult.

Greets,

Richard