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

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

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

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

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,

More information about the games_access mailing list