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

Franco Eusébio Garcia franco.garcia at dc.ufscar.br
Sun Apr 6 15:31:20 EDT 2014


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



More information about the games_access mailing list