[games_access] Looking for Feedback regarding a Game Engine For Accessible Games (Franco Eus?bio Garcia)
Ian Hamilton
i_h at hotmail.com
Sun Apr 6 19:11:16 EDT 2014
Hi Franco, nice to meet you!
By UA games I assume you're talking about Dimitris' work? If so I've seen usage stats of mainstream games that are entirely based on the principles in Dimitris' UA games paper (although I'm not allowed to share the data unfortunately) and it can work fantastically well. I've seen completely life changing benefits for people with profound cognitive impairment that have been made possible solely through UA games principles, allowing mainstream mechanics to be customised to some really quite extreme individual needs, people who traditional business cases don't support. And it is not only useful for people with impairments, the stats show that the individual customisation is used by many more people on top of that, simply because people in general have different needs, motivations and abilities.
However there are some constraints on how much is possible solely through using the UA games principles, particularly for more complex games. One example being resulting interface complexity (even for very simple games), meaning that too many options and too much customisation can actually make a game less accessible rather than more accessible. So you still really need to have as widely accessible a default design as possible and use customisation as an enhancement, rather than rely on it exclusively. Or in other words, strive towards getting as close to the unobtainable goal of universal design as possible, and combine that with carefully chosen customisation.
But that aside, you're absolutely right, it's a really important and effective principle and makes a huge difference. Not just for simple games but in AAAs too. The fact that it is even possible is something that makes accessibility in games pretty unique in the wider field of accessibility.
A nice reference for your dissertation might be FIFA 13, which is a great example of the benefits of allowing people access to some of the variables that are already there sitting beneath the surface. Steve's review of it is worth checking out if you haven't seen it already: http://community.ablegamers.com/PC/fifa-13-pc.html.
For examples of gameplay that can work without any or with greatly reduced input, have you looked at the autopilot mode in New Super Mario Bros Wii, or the automatic option in Bayonetta's easy/super easy mode?
In the nutshell document you mention an example prototype of a UA-game bundled with the engine source code, do you have a separate and compiled version of the prototype?
Also what kind of bureaucracy are you facing with the testing?
Ian
> ------------------------------
>
> Message: 3
> Date: Sun, 06 Apr 2014 16:31:20 -0300
> From: Franco Eus?bio Garcia <franco.garcia at dc.ufscar.br>
> Subject: Re: [games_access] Looking for Feedback regarding a Game
> Engine For Accessible Games
> To: IGDA Games Accessibility SIG Mailing List <games_access at igda.org>
> Message-ID:
> <20140406163120.Horde.Sq-pPa7-6F-lIQuAIdq_qw2 at webmail.dc.ufscar.br>
> Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
>
> 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
>
> End of games_access Digest, Vol 125, Issue 2
> ********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist7.pair.net/pipermail/games_access/attachments/20140407/7d9ee364/attachment.htm>
More information about the games_access
mailing list