[games_access] GAIM 0.02 updated

AudioGames.net richard at audiogames.net
Sat Dec 15 08:41:25 EST 2007


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








More information about the games_access mailing list