[games_access] Looking for Feedback regarding a Game Engine For Accessible Games

Michelle Hinn michellehinn at gmail.com
Sun Apr 6 16:08:30 EDT 2014

Welcome to the SIG, Franco! I hope that your project is extremely
successful and that others as well, like Steve already has, can comment and
help where needed! Sounds like you are off to a great start! :)

Co-Chair, IGDA Game Accessibility SIG

On Sun, Apr 6, 2014 at 3:31 PM, Franco Eusébio Garcia <
franco.garcia at dc.ufscar.br> wrote:

> Hello, Steve,


> Wow. This is both amazing and scary. (I apologize for the very long

> message)



> Your project is amazing. I'm really proud that you decided to use the

>> practical game accessibility guidelines of Includification. Many try to

>> adhere to these guidelines already, therefore, an engine that could meet

>> the entire level I of accessibility for all disabilities with very little

>> coding effort would be a project the entire game accessibility movement

>> would be behind.



> Excluding from friends, this is the first serious response I have ever

> gotten since I tried getting feedback, and it is from one of the authors of

> Includification himself!



> First, I would like to thank you for your great work. AbleGamers'

> resources have helped me a lot since I have started. Another very useful

> resource was <http://gameaccessibilityguidelines.com/>. I have read

> papers from most (if not all) of the authors.


> I am the one who is thankful here, as I stand over the shoulders of

> giants. :)



> In particular, AbleGamers would love to help any way we can. We have some

>> in-house accessibility experts who are some of the top developers in the

>> industry. Shoot me some details and I will get you in contact with those

>> developers.




> This would be amazing! All I need all the feedback I can have.

> So far, this has been a one-man project. It would be incredible to have

> such world-class talent helping us. I was having a very hard time getting

> feedback here in Brazil and even on programmer's forums.


> I am adding my advisor to the e-mail, as she may help defining a better

> way to evaluate the project.

> I can share more technical details should you wish, I just ask your

> comprehension as most of this is still unpublished.


> Our dream is allowing people who would have a hard time interacting in the

> real world to have a connection within a game. We are slowly working

> towards it. :)

> Here we are also having a hard time getting users to test the prototypes,

> due to bureaucracy. This is one of the reasons the prototypes are so low

> level at the moment. Due to this, I have been working mostly on technical

> aspects. More here in a second.




> an engine that could meet the entire level I of accessibility for all

>> disabilities with very little coding effort would be a project the entire

>> game accessibility movement would be behind.



> Ooops, my motto would be for an ideal day. As it is written in

> Includification itself, creating a fully UA-Game is a dream - especially

> when we consider the seriousness of cognitive disabilities.


> I apologize if I was misleading - let us say it is technically correct

> after a point. Please allow me to explain.



> I would not say with very little or coding effort; however, it is with

> decreasingly effort. It is a very iterative process. As I wrote at

> GameDev.net, we are currently considering very simple games, such as Pong,

> Snake and Space Invaders as case studies. Space Invaders is a nice case

> study because of games such as Access Invaders.



> I strongly believe the approach is very flexible - it works really well

> for simpler games. We are working from ground-up, slowly increasing the

> difficult of the games and trying to find out where it will take us.


> With the approach, it is possible to implement the game logic in a way it

> is completely IO-free. This means it is possible to specialize the game at

> a later step to implement the interaction. I can provide a high-level

> description the approach if you would like. It would be incredible to have

> feedback from more experienced developers. Section 7.2 of the Developer's

> Guide.



> For the first few profiles, there will be many features to implement. This

> is reduced the more profiles we have - as I wrote, it is a very iterative

> process. For instance, let us consider the Space Invaders example.



> For a first implementation, we could focus on a traditional game for

> average users. This makes developers more comfortable to create and debug

> the game.


> Our first implementation creates the IO-free game logic. This game logic

> is extremely event based. Everything that could be important to the game

> logic or have an important side effect should trigger an event. Think as

> the IO-free game logic as a meta-game or a game template that can become

> anything later on - it contains the entire game simulation.


> The game logic is then specialized during run-time to create the game view

> (with IO components and event handlers). The game view adds input and

> output devices to define how the user interacts with the game. For our

> average user profile, one possibility would be to add graphics and sounds

> to the game output and using a keyboard for the game input.


> The IO choice is not defined in the codebase, however. It goes to a

> profile. The game engine parses the profile and chooses the IO it should

> create according to the parsed data.



> For the user point of view, he/she is playing a complete game. The

> developers, however, have a template to the next iterations.



> After one implementation is ready, we can start thinking on a second. This

> time, we address a different interaction need. Let us consider, for

> instance, color blindness.


> As the game logic is already implemented, we can focus only on the

> defining the interaction for the profile. For simplicity, let us assume it

> is only necessary to change the color of a model or a texture. This is

> possible to do with the player profile: it is just necessary to change

> values. There is no need to create or change an existing game view.


> As this change did not required introducing new code, it is possible to

> add it to a profile list and just re-run the game.


> After this, let us add a third profile - low vision this time. We can use

> everything we defined above without changing the code or we can code a new

> game view. Once again, for simplicity, let us consider just changing the

> models' size and gameplay speed are sufficient; let us add input mapping to

> it.

> Once again, this can be done at profile level, as they only modify the

> components' data, and requires no change.



> For a fourth profile, let us consider a profile for blindness. This time,

> we will need audio-only game interaction. What we have so far for the

> average user is not enough to cover the disability this time. Let us assume

> the input is good enough.


> We develop a completely new output for this game. For instance, an entire

> 3D audio presentation of the game, maybe using a different perspective.

> This presentation use events and components only. Many audio-only games use

> event-driven architectures (for instance, Top Speed 3), which is reassuring.

> At this point, do you remember all the events we have defined in the first

> implementation? They come at hand here. We are not starting an audio-only

> presentation - we have beforehand defined many of the important points and

> times to provide feedback!

> There will be required implicit feedback we had not thought before; for

> instance, consider a ping-pong ball bouncing on a wall. As the graphics

> indirectly offered feedback for it (we could see the collision), we forgot

> this one. The game-logic is already implemented; we just send a new event.



> Once we are done, the presentation can be used by all the previous

> profiles. This means we added a new profile and made the low vision profile

> potentially much more accessible. The other profiles benefit from improved

> gameplay due to the better audio immerson.



> Finally, we add a fifth profile, this time addressing motor impairment.

> The current input schema is not suitable yet. We create a new game

> controller for which provides automation for one game command (let us say,

> movement) and make the game use a single button.


> Like with audio presentation, all of the previous profiles can now use

> this new controller as well.



> However, there is more. As the profiles are text based and IO is defined

> during run-time, we can create a tailored one using all the existing

> events, components and controllers we defined so far. This time, without

> changing the code, it is possible to create a profile using the extra-large

> models of the low vision profile, combined with the aural gameplay of the

> blindness profile and the movement automation of the motor impaired profile.



> Suddenly, we might enable more users to play. This means every new

> component or event handler we created improves the game for someone. Maybe

> it enables someone new to play. And the more we have, the better the change

> to provide an accessible experience.


> So far, we have only considered using events and components. Let us add a

> scripting language such as Lua to improve this tenfold. :)

> If the game-logic is implemented in Lua... Well, now we also have the option

> to load a new script during run-time and redefine problematic aspects of

> game play.


> Well, that was a very long message.

> I hope it was somewhat enjoyable. It would be easier to describe it as an

> algorithm, but alas.



> Finally, I have yet another favor to ask you: would you kindly give me

> permission to quote your message?

> I have yet to finish writing my dissertation (April 15) and defend my

> Master's.

> It would be awesome to add a statement of someone as important as you to

> the monograph.



> Thanks for your help in advance!

> Best regards,


> Franco


> _______________________________________________

> games_access mailing list

> games_access at igda.org

> http://seven.pairlist.net/mailman/listinfo/games_access

> The main SIG website page is http://igda-gasig.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/games_access/attachments/20140406/7e5973ac/attachment.html>

More information about the games_access mailing list