[games_access] Personas, etc. but what is really needed...
bsawyer at dmill.com
Tue Jun 5 08:42:09 EDT 2007
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?
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
>>> 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
>> 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
>> 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 :)
> 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
> -- "unbreakable"
> games_access mailing list
> games_access at igda.org
More information about the games_access