[games_access] Looking for Feedback regarding a Game Engine For Accessible Games (Franco Eus?bio Garcia)

[Franco Eusébio Garcia]

Hello, Ian!

The pleasure is all mine. This is quite incredible, as your work have  
also helped me.
Thank you for your work and your guidelines – and for the great response!
You are absolutely correct on all your points.

> By UA games I assume you're talking about Dimitris' work?

Yes, you are correct - Dimitris Grammenos.

> 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.

You are indeed correct. This is something we are trying to address  
with a very flexible player profile.
Regardless of whether it is a game or a software, considering  
accessibility and usability during the design makes a better solution  
for everyone. I believe it is incredible the amount of interactions  
issues we find when we use a software considering a different  
perspective.
This is even more interesting with games. Disable the graphics and  
suddenly we notice many different improvements we could make. We can  
implement these new features and improve the game for both situations.

> 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.

This goes along with the “no interface is the best interface” or less  
is more. Unfortunately, I do not remember where I have read it:  
someone once wrote the goal of the designer is to make choices for the  
user. Such as your comment, this is very spot on.
The same applies to regular software – presenting too many options to  
the user can be frightening. Depending on the number of options, even  
I, as programmer, become scared sometimes.
That being said, I am an awful designer myself. I am slowly improving,  
though. :)

> 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.

Thanks for the resource!

> 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?

Yes, I have read about both of them.

> 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?

I just compiled one here: <http://1drv.ms/1qaNIz5>. It has the “works  
on my machine” seal of quality. Please tell me if you are unable to  
run it. (Note: if you die the game will crash as I did not handle the  
player’s death)
As I said, the prototype by itself is pretty raw and un-accessible, as  
its goal was to provide an example for other programmers to evaluate  
the engine. It was an afternoon project to add to the documentation.  
Left, right arrow move, left, right button mouse fire.

What is interesting to check are the profiles. In the data folder, go  
to ‘config/player_profiles’. To change a profile, just uncomment a  
line of the ‘active_profile.xml’ and comment the remaining ones.
Then, for instance, check the folder of a profile. Let us say,  
‘average_user’. In this folder, check the ‘profile.xml’ for a quick  
idea, then either the ‘events’ or ‘entity’ folder.
The first allows you to enable/disable events to provide feedback.  
This is quite nice, as it reusing events handlers for different  
profiles. For instance, in ‘aural_events.xml’, set them to true and  
re-run the game. There we go, audio feedback for shots and enemies  
destroyed.

As events can be handled anywhere, it is always possible to define  
many different handlers and let the user choose them, if they wish.

The second allows adding or removing components from the entities. In  
my IO-free game world, the game logic uses only non-output components.  
This means that we can always add a different output component without  
affect the logic (this simple example assumes a fix collision shape,  
although it would be possible to get a bounding box of the model, if  
wanted).

Open ‘spaceship.xml’. These are the specialization components. In this  
case, they made the spaceship stronger (change health to zero to crash  
the game) and provided the graphical output. Comment the  
OgreGraphicalComponent and see the spaceship vanish. If you wish,  
later uncomment it again and change the model to another one (for  
instance, to ‘sphere.mesh’). Are the bullets underpowered? Just  
increase their firepower in the respective XML file.

Then open the other profiles and see what changes in the events and  
entities. ‘low vision’ – it changes the transform scale to offer  
extra-large graphics. Blindess changes the game perspective to first  
person and explores 3D audio – add a graphical component to the  
entities should you wish to see them. Cognitive change speed. Motor  
uses the bad enemy AI to auto-control the ship.

In some, you can also remap the game commands. I didn’t think I  
enabled this for each profile, which I apologize for. As I don’t  
remember for which I did, if you cannot change in the profile, change  
in ‘data/game/commands’ and change the ‘default_command_mapping.xml’  
(‘data/actors’ have the IO-free entities, by the way). ‘MB’ is mouse  
button, ‘KC’ are key constants (keyboard keys). Should you wish to  
swap mouse for keyboard and vice-versa, just change the device then  
the ‘input_value’.

Please disregard accessibility issues and see how tailor-able the  
solution is – in run-time!

I think it is quite nice – and that the engine it is shaping very  
well. I hope you do like it, too! :)

Best regards,
Franco