[games_access] GAIM 0.02 updated

John Bannick jbannick at 7128.com
Sun Dec 16 17:03:15 EST 2007

Richard et al,

As a developer, a combination of the three paradigms would be useful.

The requirements, guidelines, or grid (as in Richard's 9+1 grid) approach
is useful for communicating with and influencing designers, marketers,
product managers, and the ilk.

The widespread use of the GoF patterns proves the utility of such
templates. As a coder, I actually use these things.

And I personally believe that the broader, more thoughtful academic
analyses are necessary to ensure scaleability and extensibility beyond just
this release's needs.

BTW. We're having a very similar conversation of academic vs.
implementation models in a network security pod I'm active in.


At 08:41 AM 12/15/2007, you wrote:



>Well written, Eelke!



>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


>*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













>games_access mailing list

>games_access at igda.org





>No virus found in this incoming message.

>Checked by AVG Free Edition. Version: 7.5.503 / Virus Database:

>269.17.2/1185 - Release Date: 12/15/2007 12:00 PM

More information about the games_access mailing list