[games_access] GAIM 0.02 updated

Barrie Ellis barrie.ellis at oneswitch.org.uk
Sat Dec 15 11:44:34 EST 2007


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






More information about the games_access mailing list