[games_access] Fwd: Personas, etc. but what is really needed...

Tue Jun 5 19:13:41 EDT 2007

Hi,

Hey are there different people working on CC for torque? Mabye we can join up?

I can share my experiences so far. My student started out yesterday
and today he already showed some basic captioning for the FPS.
Basically a widget in the UI that just lists the name of the soundfile
currently being played (everything is implemented in torquescript so
far, no engine hacks necessary yet). Implementing it actually is way
easier than we thought. Here's some problems though: 1) minimizing
cognitive load, e.g. if a same soundfile is repeated it kind of
becomes annoying to list it repeatadly so you basically only want to
display a unique sound once (thats actually how its done in halflife
2). Another issue: multilanguages. Captions can be different for each
language so we are actually considering wrapping the audio files in an
XML container and provide captions for each language/ or have a
multilanguage caption file.

I'll send out a link to a downloadable demo by the end of the week for
those who are interested. (ow yeah we're creating a script that works
for the race game as well as for the fps).

Ben: color blindness, that's incredibly hard, I don't even think you
will be able to write code for that. Checking for particular color
schemes (lets say red on green) can be anywhere in the game e.g. on
game objects / textures. Interaction between objects, Light effects &
shading & blending can lead to non desirable color schemes. There's no
way you can possibly identify that upfront. The only way I can imagine
to deal with it would be to make artist aware to use non colourblind
colour schemes.

So if you look at the game industry you see that game developers use a
plethora of components. If we consider accessibility to be a "feature"
of games its kind of similar to something like physics or AI, since
accessibility features tie deep into the game engine core (Even
something simple as colourblindness, see my example above (how to you
detect a green on red texture on a game object). Well try to
incorporate a well known physics library like havok into any
particular engine X and you will soon find out that's incredibly hard.
Game components are not designed for flexibility. Most game designs as
a result end up to be a spaghetti of dependencies
(www.eelke.com/publications/CBSE.pdf here's a paper that I wrote about
component based game development which I will present at CBSE in july
which describes some of the problems). CC is
simple to create as a component since it only affects the UI and the
sound component but most other accessibility features in my opinion
tie deep into the game core. What I can imagine is providign some kind
of boiler plate or template solution that developers can look at when
implementing an accessibility feature.

cheers Eelke

On 6/5/07, Ben Sawyer <bsawyer at dmill.com> wrote:
> I don't know if I agree with Eelke's assessment in general- I still
> think with a lot of hard work there is a way to abstract a decent
> bundle of code that can plug in to many different engines and
> rendering pipelines to create a beachhead here.
>
> Explain to me how color blindness issues can't be encapsulated into a
> fairly basic piece of code that can be linked in by any number of the
> engine codebases or a generic DirectX/OpenGL/SDL pipeline to deal
> with that - offering a simple XML base settings file that then could
> be written to with whatever interface the developer wants to use.
>
> I think when you start making excuses for programmers you start
> shooting yourself in the foot.  If it were easy then maybe someone
> would have done it by now but that doesn't mean it can't be done.
>
> Sure autoaim or changes to gameplay might create problems to
> replicate but I'd not go there yet to start.
>
> What is a list of accessibility features that could be encapsulated
> easily across many platforms/engines/etc.
>
> Color Blindness seems easiest - maybe closed captioning but what else?
>
> - Ben
>
> On Jun 4, 2007, at 10:21 PM, <hinn at uiuc.edu> <hinn at uiuc.edu> wrote:
>
> >>> One of the things that I think would get developers moving a bit
> >>> more
> >>> and really possibly improve progress and pressure on developers
> >>> is if
> >>> there was a universal SDK and set of standard libraries that
> >>> could be
> >>> linked in to any game where the result of XX programmer weeks would
> >>> result in a game that has far more accessibility.
> >>
> >> That would be nice unfortunately game developers use a plethora of
> >> game engines. Accessibility features tie directly into the core of
> >> the
> >> game engine. Only something like closed captioning that we currently
> >> build for the torque engine can be relatively easily plugged in
> >> between the sound engine and the game specific GUI but a feature like
> >> autoaim or multiple difficulty levels ties deep into the game core
> >> and
> >> it's incredibly hard to generalize that into a component without
> >> resulting into a spaghetti of unwanted dependencies.
> >>
> >> cheers Eelke
> >
> > I agree that our tackling the closed captioning system for Torque
> > is going to give us a good first crack at things (The DonationCoder
> > contest gave us access to the Garage Guys a few months before GDC
> > so I could set up the meetings with them at GDC to get things going.
> >
> > BTW -- has everyone who needs a Torque GE or associated account
> > gotten one? I put in a few requests that I haven't heard back about
> > (from Josh or the people waiting) so I'm not sure if we're still in
> > a bit of a backlog or not. If so, I'll ping him again about it. And
> > if there are others who want one to work on the Torque [cc]
> > project, let me know and sign up for a user account at GarageGames
> > and then email me that account login.
> >
> > So just to check in -- what is the status currently of the [cc]? If
> > there's anything we can demo at GDC, we definitely should but I
> > want to take the direction from those of you working on the project
> > and not put in a proposal with deadlines that can't be met! I think
> > we had a few zig zags with direction so Eelke started something and
> > I know Reid may have also started something so we all need to get
> > that merged together as a project group just so we don't reinvent
> > each other's wheels! :D
> >
> > So Eelke, Reid (anyone else?) I know are in the thicke of the
> > Torque [cc] stuff -- so I'll yield the floor (hmm...what's the
> > "floor" on the internet?) to you guys to let me know what I and
> > others can do to push things along, set up online meetings or phone
> > conferences with Josh, etc
> >
> > So fill me in :)
> >
> > Michelle
> > .......................................
> > these are mediocre times and people are
> > losing hope. it's hard for many people
> > to believe that there are extraordinary
> > things inside themselves, as well as
> > others. i hope you can keep an open
> > mind.
> >  -- "unbreakable"
> > .......................................
> > _______________________________________________
> > 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
>

--
----------------------------------------------------------------------------
Eelke Folmer                           Assistant Professor
Department of CS&E/171
University of Nevada              Reno, Nevada 89557
Game interaction design        www.helpyouplay.com
----------------------------------------------------------------------------

-- 
----------------------------------------------------------------------------
Eelke Folmer                           Assistant Professor
Department of CS&E/171
University of Nevada              Reno, Nevada 89557
Game interaction design        www.helpyouplay.com
----------------------------------------------------------------------------