Introduction

It is widely known that billions of people every day enjoy video games, whether on their computers, mobile phones or gaming consoles. But how many of you thought about making those great titles accessible to those with special needs?

Recently more and more games get accessibility options. And while some games make only the minimum effort to comply with the existing accessibility laws and regulations, some titles take this a step further and make their titles fully playable for disabled people. One of the newest example is a recent remake of the widely awarded “The Last Of Us” game that includes an abundance of various accessibility options which allowed me as a fully blind gamer to complete it autonomously.

However as said before, not all titles get such treatment. But don’t forget that we also have a huge modding scene - countless people dedicating their free time and resources to improve our favorite titles and making them alive for the years to come. Today’s post is dedicated to those modders, as without them, the gaming scene would be dominated by money-hungry corporations of the 21st century. However I digress, and today we have a lot of things to work through, so let’s start right away.

Playable VS. accessible

Those of you who are either disabled themselves, have disabled friends and family or just lurk in the communities for disabled gamers, often hear the terms “accessible” and “playable”. It is widely accepted to use those terms interchangeably, however that is the first mistake which often leads to misunderstandings, false hopes, and wasted time and/or money.

An accessible game, by definition is a game that can be played autonomously by the target audience without the help of external tools and intervention of others. An accessible game in context of a blind gamer means having a full speech support or equal, a way to convey all the game world’s information through speech, sounds or other means. Of course those requirements vary from title to title, as different games have different mechanics and requirements. Let’s take the Rhythm Heaven Fever game for the Nintendo Wii as an example.

  1. The game is a rhythm game, requiring the player to complete various levels in accordance with the music: here we can see right away that music plays a very important role. That, theoretically checks the requirement that says that an accessible game must convey all the necessary information through speech and/or sounds.
  2. The game includes a sound that tells the player when there’s a special challenge available for him/her to complete: that also checks the requirement about making the game’s UI accessible, as the player does not require any external help to get an information about special challenges available to him/her.
  3. The game’s story screens require an OCR technology or a sighted person to read them: this point effectively exempts the game from being called “accessible”, as not all of the information are conveyed to the player.

What is a playable game then? Well, a playable game is a game that can be played and enjoyed by the target audience, however It doesn’t convey all the informations to the player via the native means and/or some features of the game are not available for the target audience at all.For example, the Soul Calibur VI game can be played by a blind person, as the combat generates all the necessary audio output, however actions such as changing the warrior’s weapon or outfit require considerable effort and so this game cannot be called accessible, it is only playable.

When designing your own game mod or an accessibility module for a game you own and control, you need to take those elements into consideration in order to set yourself a set of clear goals and make a plan on how to take on your project. I can tell you that this is the element that is a biggest failure in my mod that I am going to describe below

Designing a mod of your dreams

A word of warning: this, and subsequent sections of this article are going to be highly technical, in that I will illustrate my words with code snippets taken from my game mod. But if you want to follow along, you don’t need to be a programmer. Just listen and read, and it shall be explained to you.

A vision for making my own game mod started somewhere around 2007, 2008 when my elder brother was playing the Gothic II: Night Of The Raven game. As a child I fell in love with the world, characters, music, sound effects and the rest of the game’s lore, but there was a small problem. I am blind, and so playing such a complex 3D game wasn’t possible for me. ANd so I started to search, in my childish stupidity a way to play my favorite game. My brother was no programmer, he knew that there are ways to extend Gothic/Gothic II with additional content, that is monsters, quests, characters or even worlds and he just told me what he knew. Then I have already decided: “I need to be a programmer”.

Years flew by and I already made some serious mistakes when learning programming, the least of those is starting with the C language as my first one. However I was more and more frustrated as I was nowhere close to making a Gothic mod that would make the game playable for me. I had some attempts, some more ambitious than the others but all of them were a failure because there were no correct tools for such an undertaking. And here we come to the first conclusion: when starting a game mod, before you rush to write your first line of code learn about all the tools the game offers you, because without proper tooling, even the most brilliant of ideas will fail.

Another few years have gone by by and the Gothic modding scene has seen countless changes, such as release of the Ikarus script pack, Lego or even complete engine reimplementations such as Open Gothic (its still coming on nicely!) or ReGoth. However what changed everything for me was the release of the Union SDK, which, in very simple terms allowed me to edit whatever I wanted in the game Engine. This is when the YAGA project was born…

AFter I have written some basic stuff such as Screenreader abstraction library I have decided to take a little while, sit back and think about how my mod should work from the player’s perspective.

  1. Gothic is a 3D game that is played from the third-person perspective. This is not only about the graphic rendering but also the audio. This is because the game’s audio is played from the camera’s perspective. So a very important thing to do was to force the game to be first-person. I still don’t know how does it all work for sighted people, but here goes the rough implementation. If you are not interested in the programming details, feel free to skip this part. void BlindCameraLoop() { zCVob* cameraVob = ogame->GetCameraVob(); cameraVob->SetSleeping( True ); zVEC3 playerHeadPosition = player->GetPositionWorld() + zVEC3( 0.0f, 70.0f, 0.0f ); zVEC3 playerAtVector = player->GetAtVectorWorld(); cameraVob->SetPositionWorld( playerHeadPosition ); cameraVob->SetHeadingYWorld( playerHeadPosition + playerAtVector ); } }

There are some important parts to this code:

  1. The camera is a vob. Basically everything in the Gothic’s world is a vob which is just an object which has some properties.
  2. At the very beginning of our loop we make the camera sleep to avoid any unnecessary movements which would disturb the player’s hearing.
  3. We get the rough position of the player’s head by getting his position in world coordinates and adding a new vector to it.
  4. We get the player’s heading.
  5. Finally in the last two lines, we fix the camera’s position to the player’s eyes.
  6. Since this runs in a loop, this code is executed basically every frame.

That’s a very important think down, but… its till so little! How the player can navigate around or access the information such as menus, health, journal, ETC? Well, if that is something that would interest you then I have a good news: I am already starting to create the second part of this series, as I want to give people less information so they can learn and comprehend better.