[games_access] GAIM 0.02 updated

[John Bannick]

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.

John

At 08:41 AM 12/15/2007, you wrote:
>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
>
>
>
>
>
>
>_______________________________________________
>games_access mailing list
>games_access at igda.org
>http://seven.pairlist.net/mailman/listinfo/games_access
>
>
>--
>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