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

[Franco Eusébio Garcia]

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