[games_access] Top 3 Top 3 and IGDA GASIG Awards Ceremony 2008

Sun Dec 2 17:57:55 EST 2007

(updated pic): http://www2.hku.nl/~mosh/ga/GAcriticalpat0006.jpg

... notice the symmetrics?

btw: I think I will drop Hollistic Game Accessibility from this Key point set up. My argument: the first 9 key points discuss how to make a GAME accessibile. Key point 10 discusses "things" (websites, packages, etc.) around the game that need to be accessible. But in order to MAKE these accessible, you can (in theory) use (a setup similar to) key point 1 to 9 ;)

  ----- Original Message ----- 
  From: AudioGames.net 
  To: IGDA Games Accessibility SIG Mailing List 
  Sent: Sunday, December 02, 2007 11:47 PM
  Subject: Re: [games_access] Top 3 Top 3 and IGDA GASIG Awards Ceremony 2008

  Hi,

  *quote*
  I wouldn't want us to scare off developers by saying there are no "easy" accessibility features for developers to add. 
  *quote end*

  I think the point is not mentioning the difficulty at all :) It is as Reid said, the difficulty is different for each game. 

  Concerning the "Top 3 Most Requested Accessibility Features for each disability area": I agree with Barrie that "requested" can also be dubious. I think what we're trying to achieve here is to describe a list of "very-easy-to-understand-and-good-to-start-with [1] accessibility features that can be applied to a large number of games in order to make them more accessible". At least, that's how I interpret Barrie's blog-posting. Please correct me if otherwise ;) But if this is the case, than why not try to describe them with a simple line of text that carries this message of 'easy' 'start with' 'list' and 'features'.
  Something like: "The Game Accessibility Features List For Beginners" ... :?
  Also, if this is what we're trying to achieve here, than I would not go for seperate lists for each disability group. Actually, I do think it is wise to look at which features serve which group, but for the type of feature list we're talking here, I guess it would be better to try and serve all groups in one go (hate to bring W3C up, but somewhat similar to the W3C Priority 1 Guidelines ;)  
  And I think we can. Have a look at this:

  (if it doesn't get through to the list, see: http://www2.hku.nl/~mosh/ga/GAcriticalpat0005.jpg )

  This is an illutration of how I think my 10 key points serve which of the four target groups. It's only a sketch and I probably could have better used a simple table but I got carried away in Photoshop ;). To explain what you see: I think that the first 6 key points and keypoint 10 are the ones that make games accessible for gamers with physical impairments (the magenta blocks). I think that keypoint 4 to 8 and 10 are the ones that make games accessible for gamers with learning impairments (the grey blocks). And the blue blocks show that keypoints 4 to 10. My interpretation may not be very accurate [2] but it's a start. For those who missed it, see http://www2.hku.nl/~mosh/ga/gatheoryshort029.doc for the descriptions of the key points so far. In short, key point 1,2 and 3 are about letting the player CONTROL the game (which is mostly the problem with physical impaired gamers). Key point 4, 5 and 6 concern features that allow the player to PLAY the game (which concerns all gamers with impairments). Key points 7,8 and 9 are about letting the player PERCEIVE the game (which is mostly the problem with visual and hearing impairments).

  The reason I show this is that if this is correct, it means that there are 4 key points that serve ALL target groups. So for a "The Game Accessibility Features List For Beginners" (if that is what we're talking about here), we might need to search for design features that fit these four key points. If we would, than I would suggest leaving out keypoint 6 (experience compensation) because that one is still under construction and still needs a good definition, and maybe also key point 10, because that discusses "out-of-game"-features (which are important too but maybe are less important to start with). This leaves design features found in key point 4 (adjustable gameplay options) and 5 (assistance). Interestingly, these are key points that are not about CONTROLLING or PERCEIVING the game, but about PLAYING [3] the game.

  In my document I mention about 6 or 7 features here such as: adjustable difficulty level, adjustabel speed [4], pass functionality, tutorial agent - to name a few. So maybe this is a good starting point for looking for features?

  One thing... after typing this all, I did find a small flaw in my own story (blush). Not that my story now is worthless, but I do want to share this: I am of the opinion that game accessibility features of the different keypoints work together to create accessible functionality. So keypoint 1 is pretty much useless unless you add keypoint 2 and 3. Not in all cases, but still most of the time. This also means that a certain feature found in key point 4 might only make a game accessible when combined with another feature, either from the same key point or a different one. So looking at my illustration and saying "here's the overlap so let's start there" might result in a list of features that are useless because they depend on other features. I do think that mostly features from key points 1,2 and 3 and 7,8 and 9 depend on each other, and that features of 4,5 and 6 (and 10) are less related to each other [5]. So when picking features, we might need to consider the dependence on other features too.

  Which maybe turns into a slightly new concept of the "The Game Accessibility Features List For Beginners" : "A List Of Independend Game Accessibility Features List For Beginners" ;)

  Greets,

  Richard

  [1] 'accessible game accessibility features' ? grin ;)
  [2] For example, I can imagine that #2 and #3 might be able to make games more accessible for learning impaired gamers as well, for instance by creating a control scheme that can be memorized better ;) In the end, I think we can agree that accessibility can serve all, and also improve the game experience even for those without impairments. But that is not the point of this illustration. 
  [3] my personal definition of game accessibility revolves around these three goals: game accessibility is about making it possible that everyine can control, perceive and play games.
  [4]  Just read Reids post about physics and Pinball games and he definitely has a point. I've read some stuff about LucasArts' upcoming Indiana Jones game where (rag doll) physics are an extremely important aspect of gameplay and I can already imagine some of the problems with adjusting speed.
  [5] Which actually is another argument to start looking for features in these key points ;)

    ----- Original Message ----- 
    From: Barrie Ellis 
    To: IGDA Games Accessibility SIG Mailing List 
    Sent: Sunday, December 02, 2007 9:46 PM
    Subject: Re: [games_access] Top 3 Top 3 and IGDA GASIG Awards Ceremony 2008

    Hi Reid,

    Thanks for your suggestions. I appreciate the point that some access 
    features are harder than they first seem to implement. But there definitely 
    are easy to add features for specific genres. Quickly:

    a. Driving games - imagine OutRun - adding wider difficulty level adjustment 
    such as much more generous time limits to complete a stage is very easy.
    b. Pinball games - allowing for adjustment in ball speed as a menu option 
    seems pretty straight forward to me.
    c. Golf games - allowing an Easy Play option whereby hook and slice can be 
    turned off also sounds very easy to me.

    Maybe the Extra Suggestions part is confusing the original message. These 
    are intended to show some ways devleopers can stretch out and go a bit 
    futher with that type of accessibility.

    I wouldn't want us to scare off developers by saying there are no "easy" 
    accessibility features for developers to add. I really don't believe it. If 
    Atari could do it regularly for the Atari 2600 in the early 1980's...

    2. If it's really that contentious, I'll change it - but "3 most requested" 
    isn't bullet proof either.

    3. Why don't we make a Top 3 Most Requested Accessibility Features for each 
    disability area? Sounds like a good idea to me...

    Barrie

    ----- Original Message ----- 
    From: "Reid Kimball" <reid at rbkdesign.com>
    To: "IGDA Games Accessibility SIG Mailing List" <games_access at igda.org>
    Sent: Sunday, December 02, 2007 8:07 PM
    Subject: Re: [games_access] Top 3 Top 3 and IGDA GASIG Awards Ceremony 2008

    > Hi Barrie,
    >
    > I like what you have but do have a couple suggestions.
    >
    > 1) I agree with Richard, there are no "easy" accessibility features
    > for developers to add. I have said that adding closed captioning to
    > games is easier than a physics or rendering system and it is true, but
    > creating the captioning system itself presents tricky design problems
    > and depending on the sound engine, maybe even technical issues. In
    > general, I don't think we have the right to designate whether an
    > accessibility feature is easy or not for a developer to implement. How
    > hard it is will depend on the developers technology foundation and
    > programming/designing talent they have.
    >
    > 2) On the contention of Top 3, why not slightly change the wording so
    > it's Top 3 Most Requested Accessibility Features.
    >
    > 3) Why don't we make a Top 3 Most Requested Accessibility Features for
    > each disability area. Richard can submit a list of his top 3 for
    > blind/visually impaired, I'll submit mine for hard of hearing/deaf and
    > so on.
    >
    > -Reid 

----------------------------------------------------------------------------

    _______________________________________________
    games_access mailing list
    games_access at igda.org
    http://seven.pairlist.net/mailman/listinfo/games_access

------------------------------------------------------------------------------

  _______________________________________________
  games_access mailing list
  games_access at igda.org
  http://seven.pairlist.net/mailman/listinfo/games_access
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist7.pair.net/pipermail/games_access/attachments/20071202/ac3a16f7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GAcriticalpat0005.jpg
Type: image/jpeg
Size: 57811 bytes
Desc: not available
URL: <https://pairlist7.pair.net/pipermail/games_access/attachments/20071202/ac3a16f7/attachment.jpg>