I began the first blog with a declaration of intent saying that I would have updated the blog on a weekly basis, but as the title suggests, I may have skipped a couple of blog posts.
The developing of the prototype is proceeding with some difficulties, which I'll talk about it later in the appropriate section, nonetheless I am satisfied with the progress that I made given the circumstances.
Given the length of the blog post, here are the link for each section:
DIRECTIONAL SOUND INDICATOR
What are Directional Sound Indicator?
Directional sound indicator is an accessibility feature that helps those that suffers from hearing impairment understand where sounds are coming from with a visual cue on the screen.
Traditionally this feature has not being included in games due to the fact that games usually have similar features, such as damage Indicator or detection indicator as shown in the gallery below.
Even thought the features above mentioned are welcome from an accessibility standpoint, the amount of information that they relay are not enough to offset a player that cannot hear/is hard of hearing, hence the necessity of this accessibility option, which convey both the direction and the "cause" of the sound.
Example of Sound Subtitles in Far Cry New Dawn
The idea was to recreate a system similar to the one shown in the picture above, with a similar position but with a broader range of sounds to "locate".
Designs for the indicator
First iteration
This design was confusing and not easily understandable at a quick glance in hectic when the player is in a firefight and similar.
Video of first iteration
Second iteration
Scrapped due to the fact that the arrow is not clearly visible in every environment and it can be hard to notice with certain background.
Video of the second iteration
Third iteration (current iteration)
Clear bold shape, no chance to misinterpret the direction. The yellow colour with black outline is one of the best way to highlight an element regardless of the background colour and content. This iteration is the best from both a visual standpoint and from the cognitive standpoint.
Video of third iteration
The making of Directional Indicator
The jump from one directional sound to two shown on screen was quite rough.
The difficulty derive from the fact that with only one directional indicator the way it works is pretty straight forwards, the nearest sound that plays relative to the player is shown on the screen, while with two sounds on screen, the problem of which sounds to display arises.
To solve this issue, each sound that is playable in the level is put inside a data table with a value that represent how important the sound is to the player.
below is the screenshot of the data-table
The rank of importance is based on the amount of theoretical damage that the source of the sound can deal to the player.
This is based on the assumption that the game is an fps game; If the assumption was different, for example a walking simulator, then the priority ranking would be change based on what is important in that genre (dialogues etc.).
At the end the most important sound is displayed on top, while the second most important sound is displayed below. If only one sound is playing, only one will be displayed and the other arrow+text component will be automatically hided.
Current iteration (but still old)
In the current iteration the system can display zero, one and two directional sounds. I still have to resolve a couple of issues, for example, sometime the second indicator get stuck with the same text and direction as the first one, but it shouldn't take me too much to troubleshoot (the famous last words).
I also need to migrate all of the code
I know, I know, it's stupid to touch something that works, but the way that this function was built is not sustainable anymore, as you can clearly see the monstrosity right below.
By not sustainable, I mean that the function was built inside the Subtitle UI Widget, which is now becoming too heavy and tanking performance, hence the need to optimize performance and migrate the whole function to its own UI widget.
For now we are done with the features of this option, even tough I have a lot to fix still.
Tinnitus Friendly Mode
Hearing impairment can manifest in multiple ways and one of those way is with tinnitus.
Defined by the National Institute on Deafness and Other Communication Disorders as "... commonly described as a ringing in the ears, but it also can sound like roaring, clicking, hissing, or buzzing. It may be soft or loud, high pitched or low pitched. You might hear it in either one or both ears."
Tinnitus can get worse when those that are affected by it, hear a similar sound to their tinnitus.
This usually happens in fps, where explosions and various grenades have the ringing sound effect included and is not possible to remove or disable it.
This accessibility option aim to solve this problem.
The way it works is pretty straightforward, if the option is on, only the sound effect without the ringing will play.
Here is how the sound blueprint work
Explosion audio file with no ringing
Explosion audio file WITH ringing
CAUTION LOUD RINGING, ADVISE TO LOWER THE VOLUME AS MUCH AS POSSIBLE TO AVOID DAMAGE/DISCOMFORT
Video showcasing how it works in game
CAUTION LOUD RINGING, ADVISE TO LOWER THE VOLUME AS MUCH AS POSSIBLE TO AVOID DAMAGE/DISCOMFORT
Autosolve puzzle
In my project I am to tackle at least three accessibility option for each area of impairment, one of which is cognitive.
The Auto-Solve puzzle option is an option that helps those that suffers from cognitive impairments
At the moment the option is implemented and it works
Making the Puzzle
But to have an auto solve puzzle option, one need a puzzle to solve it, right? I did not thought about that when I first started to work on the auto solve option.
The puzzle that I design is very basic, the player has to pick up key-cards and combine their colours to recreate the colour of the door that is locked.
Example of the puzzle working in game in the video below
UI design
First draft for the UI.
This was used as a quick mock up for the user interface.
From the beginning I wanted to make sure that everyone would understand the difference between the player's inventory and the key inserted in the door.
Even tough the puzzle was specifically made for the skip puzzle (oh, the irony), I still decided to put an effort into assuring that the interface would end up being as clear and as accessible as possible from a visual and cognitive point of view.
This version was sketched in Photoshop and later recreated within Unreal Engine
Second Draft
This is the UI in Unreal Engine.
I am still working on the some component of the puzzle itself (fixing key related issues with combination of colours) and I aim to have a more refined interface by next week.
Below are images of the key-card and puzzle blueprints
Miscellaneous
This weekly book about accessibility and being a decent human being is:
"what a body can do? How we meet the built world" by Sara Hendren
Comments