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

[Michelle Hinn]

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

Cheers,
Michelle
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: <https://pairlist7.pair.net/pipermail/games_access/attachments/20140406/7e5973ac/attachment.htm>