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

d. michelle hinn hinn at uiuc.edu
Fri May 25 13:25:50 EDT 2007

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. :)


>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


More information about the games_access mailing list