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

[d. michelle hinn]

Thanks for your great advise, Ben, as usual!

Just a quick reply to say that there are a few of us working on these 
developer tools but it's too early to say too much now because 
funding details are still being worked out. I agree -- at the end of 
the day, having proof of concept and tools that can be used are key. 
That much I've found out from this month posting on Terra Nova -- no 
one wants to take our ideas and integrate them in -- they want us to 
do it for them. Unfortunately..."us" is a very small overworked group.

Now...what is really needed is more programmers here...we need the 
"pre-interns" here to help work on their resumes...because we have a 
LOT of projects they could work on. :)

Michelle

>The personas idea sounds pretty cool and I agree it would help.
>
>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. 
>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