[games_access] GAIM 0.02 updated

[Barrie Ellis]

Richard, you are fast in danger of disappearing up your own arse! ;)

Come on - let's not turn Game Accessibility into some impenetrable academic
science. Let's chip away at the things that are simple - then go on from
there.

You've lots to offer - but you seem to me to be getting yourself tangled up 
in unnecessary knots.

Barrie

----- Original Message ----- 
From: "AudioGames.net" <richard at audiogames.net>
To: "IGDA Games Accessibility SIG Mailing List" <games_access at igda.org>
Sent: Saturday, December 15, 2007 1:41 PM
Subject: Re: [games_access] GAIM 0.02 updated


> 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