Exploring the Viability of Implementing Accessibility Features at a Game Engine Level – Final Year Project

This endeavour was my individual ‘Final Year Project’ at Bournemouth University. Given the span of roughly six months, we were allowed to pursue any topic that interested us in order to produce both a digital artefact and written dissertation. I opted to, as the title shows, explore how accessibility features could be built into a game engine from the ground up. I utilised a primitive game engine that I had already been developing for previous university units to allow myself access to low-level components that would be otherwise inaccessible in proprietary engines.

The primary aim of the project was to show that accessibility features are able to be implemented at a game engine level. The two parts that made up this aim were that the features should be as helpful and flexible as possible to players, and as non-intrusive to work with for developers. The implementation side of the project was intended to serve as a technical demo, and by no means would be introduced into the industry as-is. Instead, it is my hope that the implementations, alongside the research, can spark new conversations within the industry and provide a small step towards achieving widespread gaming accessibility.

The overall project consisted of the following main phases:
-> Research, where I explored existing academic papers, online resources, and the current state of the industry relating to gaming and accessibility.
-> Design, where I decided on a small selection of features to pursue and defined their attributes and scopes.
-> Implementation, where I actually programmed the features and integrated them into my existing engine.
-> Evaluation, where I distributed a small questionnaire to gather feedback on the designs and implementations from games industry developers, and analysed the results of the survey.
-> Conclusion, where I collated my thoughts and learnings from each phase and produced an overall outcome for the project.

Following on from the research portion, I decided on a small sample of accessibility features that I would explore in detail. These features were chosen to cover a range of disability types that they would cater for, a range of implementation complexities, and a range of severities of the impact that they could have. These were the features that I chose to pursue, along with some details about them:
-> Input device and method support: the engine supports various types of game controllers, as well as keyboards, and pointing devices with the use of on-screen controls. It treats all input devices in the same way, therefore ensuring that the experience remains as similar as possible between devices, and that developers wouldn’t be faced with overwhelming amounts of work.
-> Advanced input rebinding: the engine allows the user to fully customise which inputs they can perform in order to execute in-game actions. Multiple inputs can be assigned to each action, and with any combination of different devices. Developers receive all of the information that they need by querying the actions- meaning users can entirely change their bindings without issue.
-> Various settings for individual inputs: the engine allows for users to adjust various settings on a per-input per-action basis. The settings include sensitivity, dead zones, toggle mode, and value cap. On-screen controls can also have their position, size, label, and icon adjusted easily, along with the option for a configurable dwell time if set to hover-mode.
-> Adjustable game speed: the engine offers users the ability to modify the speed at which the game runs. This can be configured for specific areas of games by utilising developer-defined ‘contexts’. Examples of potential contexts could be “in combat” or “in menu”.
-> Settings to customise text colours: the engine provides the ability for users to customise how text is visually displayed in games. It gives control over the text colour, as well as the colour and opacity of a background ‘highlight’, which allows users to utilise colours that work best for them.

Whilst I wasn’t able to visualise every one of the implemented features, you can take a look at some screenshots above (the demo game is a basic ground-up reconstruction of my previous Space Game). The source code can also be viewed on this GitHub repository.

The project’s questionnaire received 15 responses and offered some very helpful insight that I was able to draw some conclusions from. Overall, I concluded that accessibility features are viable for inclusion in game engines, with some caveats. The lists below show some of the statements that support this conclusion, as well as some of the areas that would need additional research and development.

There was general agreement that the features belong at a game engine level.
The features were not deemed to be unnecessarily complex- that is, they were not too complicated for what they achieved.
There was general agreement that the benefits of including the features were clear.
There was general agreement that the features, overall, did not seem that they would be difficult to learn or add significantly to developers’ workloads.

There were concerns raised over the amount of additional testing that would be required to support some of these features.
The adjustable game speed feature was highlighted as the most problematic in terms of the widespread consequences it could have on game systems (such as physics particularly).
There were suggestions that more could be done regarding text customisation- including suggestions for offering custom fonts and sizes.

Reflecting on the project, I am incredibly happy with what I achieved in the given time span. I will likely continue to add to my game engine and add, polish, and tweak various accessibility features going forward. I am more than happy to talk about the project in more detail should you wish to know more- feel free to contact me here.

Thanks for reading!

Joseph MacLauchlan