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

[Eelke Folmer]

HI Ben,

> 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




>  Perhaps everything
> can't be solved this way but until there is a standardized SDK to
> some extent you won't get as far.
>
> Once there is an open source standard SDK that is updated and worked
> on (hopefully with aide by professional developers and perhaps with
> funding too) and perhaps aided by university research in an organized
> fashion then it becomes a matter of brow beating publishers to do the
> work to integrate it just like every other SDK past/present/future
> works.  It becomes a semi-singular response - this games supports the
> SDK this game does not.
>
> Also it would seem if you could create standard icons for
> accessibility like we see from GameSpy, ESRB, PC-CDROM, EAX, XBOX
> LIVE!, etc. that showcases in a second such compatibility that would
> help as well.   Perhaps a standard logo that would provide some quick
> response to users about its compatibility with the SDK or various
> specific standardize accessibility issues.  What you might not know
> e.g. is that the EMA (entertainment merchants association) controls
> the standard PC-CDROM logo and that they license its use to the
> publishers in return I think for nominal fees or at the least I think
> it was 3 copies each of all games (which they then donate).
>
> If you followed this idea in the long-term what you could do is A)
> develop/galavenize the development of the SDK(s)/Librarie(s) and then
> a standard logo of compliance with the SDK.  No publisher could use
> the logo without making a per-sku (not title) payment to the non-
> profit that controlled the trademark (you could even write it into
> the EULA of the open-source license probably) and the cost would be
> low like $50-$100 per sku.  EA put out probably 500-1000 worldwide
> skus last year across all formats.
>
> If you want to make progress in games you need to do it in software.
> It's like getting press - the easier you make the other persons job
> the more attention you will get.  You need to create an ecosystem of
> code not just an ecosystem of pressure because at the end of the day
> linking in an API is a process most publishers and development
> studios can deal with but writing new code from scratch doesn't
> work.  Going to several different sites to cobble together existing
> code doesn't work.  Etc.
>
> If you had a one-stop code repository and GOOD docs then what happens
> if the accompanying pressure/customer service comes into play is you
> will probably see 3-4 things happen:
>
> 1. You will be able to boil down average strong compliance to an
> average cost per title to link in the SDK as opposed to an amorphous
> cost it would be fairly standard and trackable.  When you have that
> you can create awareness that EA and others are ignoring a trivial
> cost and QA process.
>
> 2. You will be able to argue that the console companies could
> integrate the SDK into their own libraries and middleware and (cross
> fingers) their QA process.
>
> 3. You will see studios/publishers assign junior / intern programmers
> to the SDK as a project.  With an API, docs, standard process it's a
> great "here kid do this!" project.  There is little supervision and
> worry about virgin code.  As a manager you have to hope a new
> programmer is at least good enough to integrate in a standard API or
> they're worthless.
>
> 4. You will see programmers inside companies who are trying to win
> the right to integrate these features do so more frequently because
> it will be a standardized process.  The industry is beginning to
> standardize development practices more and with an SDK you can get
> into that pipeline better.
>
> 5. You will see more industry support for the SDK itself and in
> general I think far better compliance.
>
> I'm not the expert - perhaps such code exists but I googled for it
> and didn't see anything right away.  It would seem you could
> standardize some libraries for color blindness, one switch
> controller, head mounted mice, closed captioning, etc.  If you at
> least outlined what an spec for it would be then a place like
> Carnegie Melon, USC, and other universities could be asked to assign
> students to develop the initial codebase.
>
> If you want a campaign to work write code.  That is the single
> biggest impediment.  With it then the excuses or non-attention by
> developers will be much harder for them to pull.  If you're going to
> apply a hammer you need the anvil.
>
> - Ben
>
> _______________________________________________
> 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
----------------------------------------------------------------------------