Qantic Dream’s 2005 game, Fahrenheit, left an indelible mark on me. The mental health mechanic it uses, and the way even the smallest actions. Something else.
Author: Drew
-
When you work on marketing or PR campaigns, typically you don’t get to go back and continually refine what you do. Everything moves forward: pre-launch, to launch, to post launch, to the next game on the slate. You learn to do the best you can, then move on. Hopefully, take some small learnings from title to title, launch to launch, activity to activity, acknowledging that audiences and the market are always shifting.
This week, I’d finally decided that the basic mechanics of the blind accessible gamebook engine I’ve been coding were done. They weren’t pretty, but they worked and, as someone who has only been learning JavaScript for a month and a half (self-taught), I was pretty happy with the result. I was ready to move on to something else–an Escape the Room engine–which I’d already decided was a better idea and could use a significant chunk of the code and ideas.
I’d already spent some time sketching and dreaming up mechanics and ideas, when, and don’t ask me entirely why I did, I reached out to a blind person I (sort of) knew on Twitter–Michael Feir–and asked him politely about the type of screen reader he used. Michael was very helpful, and before I knew it, I’d sent him a link to the prototype.
Unfortunately, it didn’t work for him.
None of the passthrough keys seemed to work, rendering the entire choice system (and therefore the whole gamebook) unusable. I knew from my own testing that the systems worked. But they wouldn’t for Michael. And he was blind. And if they didn’t work for him, then it didn’t matter how much they worked for me, or any other sighted person I’d asked.
Michael suggested I added radio buttons.
Initially, I’d ruled out radio buttons for choices. Screen readers such as NVDA announce them, stating that the user is at an “unchecked radio button” and the extra voice work was something I’d wanted to remove, so that, as much as possible, all the player heard was pure narrative.
I knew I was at a crossroad: I could move on, or I could make this better.
Michael’s encouragement clinched it for me:
More than 80% of blind people are unemployed, he explained. As I’ve learned, for those with significant visual impairment, entertainment is crucial to being connected to social circles, to quality of life, to feelings of self-worth, and more. Especially when that entertainment is free.
“The story idea sounds good,” Michael messaged me, “and there’s quite a big appetite for rpg gamebook-style stuff.”
The latest version of the prototype now has an improved heading navigation system and two mechanics for selecting player choices–one of which uses radio buttons. Better yet, the choices now work for Michael.
Instead of moving on to the next prototype, I’m now looking at what I can improve.
You can check out the latest version of the prototype here: http://drewmtaylor.com/toll/prototype20may.html.
I recommend you using NVDA as a screen reader (http://www.nvaccess.org/), if you’d like to try playing it as a blind person would. (Fun fact: NVDA was developed here in Australia, and is regarded as one of the best resources for blind desktop users!)
-
Nine weeks or so ago, I was sitting in a hospital bed, sharing a small room with a woman who had just been told that cancer had entered her brain and lungs, and she would die; she had two, maybe three, months to live.
Attempting to give her–and her many friends and family members that came to see her–as much privacy and freedom as I could, given we were separated by a single curtain and 8 feet of linoleum, I spent a considerable number of hours quietly listening to game soundtracks on my phone, watching my social media feeds (without contributing), and reflecting on life.
After a couple of days, my laptop was brought in, but I had no WiFi access, so I was limited to a few standalone programs, some of which I’d installed quite some time ago. Twine was among them, and I decided it was about time I gave it another go, particularly given my love for interactive fiction and gamebooks. I pulled up a Twine tutorial series on YouTube on my phone and started playing around with it.
It wasn’t long, however, before I was frustrated by the limitations of Twine. It looked like the only way I could have the functionality I wanted was by using Twine’s SugarCube story format and coding in new mechanics using JavaScript (which I didn’t know). Eventually, I surmised: a tool which simplifies some things usually makes everything else harder. I gave up on Twine.
Home from hospital, I went back to playing games. But I felt overwhelmed by the number of new games being released that I didn’t have the time to play, and I frequently felt like I was under pressure to ‘keep up’ in order to stay part of the conversation.
So, I did the opposite.
I made the decision to stop playing games at night*, and use that time to create something; something meaningful. I was finally going to write a gamebook engine (from scratch) that was designed to be completely blind and VI accessible.
For the first few weeks I taught myself the basics of JavaScript (–I strongly recommend the free courses at Kahn Academy and Code Academy). And, for the rest of the time, I’ve been writing code 2-4 hours a night to develop a working prototype.
It’s now done.
The engine runs inside a browser window, using vanilla JavaScript within a single HTML file. It features anytime and retrospective font sizing, a high contrast mode, and (I hope, ultimately) full screen reader compatibility. It can run completely customised CYOA and Fighting Fantasy adventures with full combat features, and has “classic” Fighting Fantasy or “wake” (survival level emotion) narrative responses.
The full feature list is at the bottom of this post.
If you’d like to try out the prototype, you can find it here:
www.drewmtaylor.com/toll/prototype.html
Sure, the narrative is not consistent, only the Four-by-Two has been detailed as a weapon (and even it could do with more creativity), the enemies actions and reactions are not narrated to the depth they could be, and if you’re not using a screen reader you may miss 90% of the benefit of the prototype. But, it’s a prototype, designed to test general functionality, and it works. I have also intentionally made it completely playable for a sighted person. As I was told, just last week, by someone with B2 blindness, “I want something my sighted friends can play as well, so we can all talk about it.”
At this point, the goal is to create a web site–a repository of high quality games and adventures for blind and VI players (and their sighted friends).
I have bigger ideas, but the rest of the path is still to be determined. The prototype is a first step.
Let me know what you think.
Feature list
Accessibility:
- Designed from the ground up specifically for VI accessibility
- Compatible with all major screen readers (only tested so far with NVDA)
- Text only Single page document, dynamically appends content
- Uses tags for logical and expedient page navigation
- Anytime and retrospectively increase or decrease font size
- High contrast mode
Play:
- Browser-based
- Completely playable online or offline
- Includes all major CYOA and Fighting Fantasy mechanics
- Unlimited narrative length, from short stories to full length adventures
- Player creation and Hero select character options
- Random dice rolls
- Full inventory system, including: equipment, weapons, things the player knows
- Test Your Luck, Try Your Luck (point-based) and Test Your Skill checks
- ‘Classic’ Fighting Fantasy or ‘wake’ (survival level emotion) combat
- Randomised enemy encounters
- Each enemy is capable of multiple types of attack (specific to itself), custom damage, randomised percentage hits, customised text
- One-on-one, one-at-a-time and one-against-all combat
- Customisable, weapon-based damage system with modifiers
- ‘Win’, ‘survive’ and ‘consecutive hits’ victory conditions
- Path tracking
Coding:
- Works completely in-browser
- Compatible with all major browsers
- Written completely in vanilla JS
- No added libraries or external files
- Flexible code framework
- Easy to ‘bolt on’ new features or customise existing ones
- Dynamic change possible at passage level
- Streamlined and documented code structure
*With the exception of the Mirror’s Edge: Catalyst and Overwatch betas. Who could resist those? 🙂