Verb coins and accessibility

Authoring General Design Discussions
1

I’d like to address accessibility in interface design for a moment. Verb coins are nothing new, even in text games. Even modern adventures like Return to Monkey Island arguably use something of a verb coin interface.

My question is, how might this be handled for blind players? Text games are kind of wonderful in that they’re very accessible; no matter who you are, blind or sighted, you can play Photopia. That’s pretty cool!

But I’m thinking a lot about verb coins in my next game, and wondering if there’s a way to do this without shunning an entire group of people who might want to play. I’m already feeling a little guilty because I think my last game, which featured some visual puzzles, likely did this.

Is there an example of a verb coin text game that is highly accessible for both sighted and blind players? Is there something I can do in the interface that will make it a better experience and more usable for, say, a screen reader?

2

Verb coin text game… the examples I can think of are the Legend Entertainment games (Timequest, Gateway, Eric the Unready, Spellcasting 101, etc) and Infocom’s “Journey”. These are parser games. Is that what you mean?

Off the top of my head, I am now idly thinking of a keyword based system that gives you options.

Test Room

You are in a test room with some cheese and a mousetrap.

>CHEESE

It looks quite yummy. TAKE; SMELL; EAT.

>EAT

It may look yummy but it’s actually pretty stinky. You pass. TAKE; SMELL; EAT.

>LOOK

You are in a test room with some cheese and a mousetrap.

>MOUSETRAP

It looks quite deadly. GET; SPRING; LOAD

>SPRING

You spring the trap, nearly losing a finger in the process. How violent. You set it again. GET; SPRING; LOAD

…etc etc etc. Is this a useful concept? I literally just thought of it.

3

What sort of input devices does your game support? If you assign a keyboard key to each verb and make the tab key cycle through the various things you might click on, that ought to be usable (and save sighted players from trying to click every pixel when they get stuck).

4

I’ll make a shameless plug for my system. In it is the ability to emit author defined menus. The menus have a list of items that get turned into choices. [1] Take [2] Eat, … [3] Smell. Logic is then built around the menu choice 1: do this. 2: do that. 3: do the other, etc… Even making no choice can be handled. It is how I provide the CYOA moniker to authors and allow menu stacking for branching. I made a whole demo game, Road of Darkness, using it to demonstrate the capability.

5

This is a really interesting idea, and sort of like what Adv3Lite does with topics, just with suggested verbs instead. This also has the advantage of being pretty good for a screen reader; everything you can do is just listed as text.

6

Well, if you like that idea, it seems that the obvious next step is to see what Candy64’s engine has to offer. :wink:

7

CYOA like demo

8

My current prototype does something similar to what candy64 already implemented: basically menus, assigned to single press keyboard keys, or selectable via arrow keys.

9

On that game page I showed the backing logic of how that game is made. You can also download the system and starter project files, including RoD, and load them up in the studio.

10

They’re not just old, they’re of a specific vintage. I think of verb coins (contextual menus) as a transitional stage that point-and-click adventure games went through.

The first graphical adventures were parser games with background art and a player avatar. Then they had menu interfaces, but the designers were stuck in the parser mindset so they tried to provide a list of all possible verbs. But this was clearly terrible. If you’re looking at a list of verbs, one of them is clearly right and the rest are wasted space. Or else you can’t tell which is right, so you click down the list until something works.

Removing some of the extras from the list clearly resulted in a better UI. Iterate.

So then you had, at best, EXAMINE and USE and maybe TALK if it was a game with lots of NPCs. And a lot of design pressure to cut that down even further. One verb? Well, Myst had one verb (MOUSECLICK) and it sure sold a ton of copies.

(This is really a lie about Myst but that’s another lecture.)

This is where we are today, or really even twenty years ago.

11

Broken sword sort of did this with point n clicks: left click was “use/take” and right click was “examine”. The rest was inventory object puzzles, where you clicked an item and the mouse cursor WAS that item. Verb coin games handled inventory puzzles pretty much the same way.

12

Yeah, it’s the interface that Revolution Software used in Beneath a Steel Sky and kept for Broken Sword. In the AGS scene there are essentially three interfaces: BaSS-Style, Sierra-Style and LEC-Style (and variants, but usually it’s based off of one of these three). I think Sierra’s popularity’s been dwindling, and BaSS has been going strong, and LEC isn’t getting much love because it seems to be regarded as wasted space for no real gain (and indeed, if you’re used to the Sierra-style or BaSS-style simplification, there’s no need to have all those verbs. It’s a different designing mindset, I think, nothing more).

Fully agree, if I think of Lucasfilm’s Labyrinth and The Scoop and stuff. But Full Throttle and Curse of Monkey Island also used verb coins to good effect. Essentially a floaty GUI that didn’t take up permanent screen space, and didn’t force you to scroll all the way up or down to a verb and then scroll back to the item.

Interestingly, in the modern age of touchscreens, I personally really really prefer the LEC interface. But my opinions usually differ from others. :slight_smile: Verb coins can also work really well in touchscreens.

Have you lectured about that in a different post? I would be interested in taking a look. :slight_smile:

13

(My reply assumes that you are using the browser to present your game, but the same still applies for screen readers with custom applications.)

I looked into making a blind-friendly interface for an IF-RPG game recently. When using a browser, it’s tempting to let the player use their own screen reader. (They have a favourite voice, pitch and rate already setup.) However, screen readers do not have a listener API open so that a browser (or any other program) can access it. Meaning, if you want a truly customized playing experience, you’re out of luck. Try cancelling the message that a screen reader is speaking to prompt a new message to replace it… and you can’t; and that was non-negotiable for me.

Currently, I have a satisfying navigation menu that softly dings and speaks the options, but they can be interrupted. The thought was about traversing familiar menus, so you could press down, down, down and hear ding, ding, ding then hear the menu option read aloud, press accept to go forward or cancel to go back. (Since I’m making an RPG, there will be a few menus that become familiar enough to remember the placement/pattern of options.) My intention is to have the game work with a gamepad, so tabbing around and navigating a webpage is not what I wanted.

I used JavaScript’s speech API and embraced the built-in OS voices. They are not pretty, but they are very effective and once you get used to them, they are usually preferred at faster-than-natural reading speeds. (A beautiful, natural voice sounds weird at higher rates, but a slightly robotic one sounds more acceptable to me – the uncanny valley of voice audio, perhaps.) Interestingly enough, after playing around, my main “verbs” were better suited by sound effects. Attack became a sword unsheathing. Using Magic became a swirling, twinkling noise. This felt better than a robotic voice for common actions. Speech was still used for targets and such, but sound effects become your “graphics”.

When you mentioned verb tokens, maybe a gamepad interface is a good start for exploring possibilities. (Remember to not use any browser-reserved keys for your game pad keyboard mappings.)

My recommendation is to build the accessible, audio-only interface as the primary interface. Ignore the visual output altogether until you have your game working (aside from an on-screen log for testing and debugging). Then construct a visual interface as a new mode of play afterwards. In researching blind accessible interface design, I concluded that visual and auditory sensibilities do not jive seamlessly. Having an interface that is audio only is ideal for blind players and you’ll soon learn where friction occurs as you test it. Describing an interface with speech is not the same as operating an interface with only sound.

If visual feedback is 2D, audio feedback is 1D. Yeah… my mind was blown too at this realization! All audio output is a linear stream of information that can only be cancelled or interrupted with a new stream. Text adventures feel like a stream of only text (1D), but our eyes reread things, glance at the status bar, see the exits list and items dropped on the floor, reread that specific sentence in the description… but audio-only output is pure 1D with the player’s attention. This realization can change game play design as well; just putting that out there.

Hopefully some of this resonates with you, but ultimately you have to decide, am I making a blind-accessible game or a game for blind people? Two significantly different answers emerge from that question.

I love interface design and I’m not apologizing for my preachiness. :wink:

14

I’ve thought a lot about gamepads for IF before. You’ve got 4 cardinal directions built into a gamepad, and with 4 common face buttons you’ve got a touch-based interface that’s easy to feel.

Inventory… Now that’s another beast

15

The inspiration for my RPG is Dragon Warrior. Yes, that crappy game on the original NES.

image
image993×896 7.02 KB

Inventory would work just like any other menu. Press down, and it reads the next item out loud. You can choose to order the inventory by how recent the items were obtained so newest items are listed first. Allow blind users to change the sorting order with a single button – INTERFACE DESIGN ALERT! – that toggles the sorting. Create a “favourites” menu for inventory intensive games.

In my opinion, the SNES (and to some extent, the PS1) had the perfect controller. Analog sticks can go to hell! :wink:

Though Maniac Mansion was on the NES, it used a cursor, I believe. Still maybe it’s verb menu will inspire you in some manner.

image
image1024×960 5.2 KB

16

You now need another menu for inventory interactions. Does the item interact with other items, or room objects? Or, the player? Or do you want to just examine the item? The menus start stacking on top of menus

17

Yes. But you are not subjected to a complicated stack of menus like a visual interface would entail. You shift to context sensitive modes of interaction. The menu is replaced with another menu. You only have one menu at a time.

So let’s say you want to use an item on another item in your inventory. That sounds about as complicated of an interaction as one could make.

(Note: I’m of the opinion that the first item in a menu needs to be read with an additional button press, so pressing down feels like activating the first choice to me. Like, I’m ready to hear it. Up might give a “bump” sound and say the first choice. I’m still questioning wrapping menu navigation at the moment.)

If you have a truly free-form system, like a regular parser, you might do something like:

The alternative is to make a more streamlined, less deliberate system. You can offer common sense interaction shortcuts if you have the right components (and it’s not a puzzle):

Note: Keep in mind that blind players are used to exercising a bit of patience (within reason). What we see as possibly inconvenient or tedious, they might accept as simply necessary.

EDIT: Also, for additional convenience, you can omit choices that you can’t “verb” with. Like, when the player chooses to use the gun on inventory items, you wouldn’t list items that couldn’t be combined with the gun. Less frustration, but also less trial and error (illusion of freedom).

It’s hard for me to explore this further without knowing how you envision your game working. If you see the merit of a “verb token” system, share a scenario and how you see it working with a visual interface. (Or at least the construction of how the command is formed.) Maybe that will help me to help you explore a blind interface design with a gamepad for that. I’m up for that challenge! :slight_smile: It’s also entirely possible that the traditional parser command/input system is the superior method for blind players of your game. :face_with_diagonal_mouth:

Fun Fact: A comma , is recognized as a natural pause with reader software. Use it intentionally with this in mind, even it it looks funny syntactically in the text you wish to have spoken aloud.

18

I note that seems that for “graphical adventure” many fellows means the Sierra-style ones; for me a “graphical adventure” is one with text and pictures, with or without selectable/clickable interface (spanning from Quill+Illustrator thru Legend, thru Magnetic scrolls, ICOM &c, e.g Tass Times in Tonetown or Borrowed Time)

on Hal’s opinion audio, is true that I’m deaf, but I’m also a military/Naval historian, and from this perspective, I’m inclined to call 1.5D the audio, not only because of the stereophony, but also for the discerning of frequency/tones (“signal vs. din of battle”)

Said that, what about an “speak-when-hovering” interface ? that is, an “audio highlighting” when the cursor/pointer is above a verb (I’m sure that is best on headphones, I’m sure that a continuous stream of “look-take-get-take-open-drop” from a computer is rather annoying to non-blind people living with the blind player), but aside the potential issue above, seems an idea worth to exploring to me (ok that being deaf I can’t asses the annoyance factor of a stream of random verbs from a speaker…)

Best regards from Italy,
dott. Piergiorgio.

19

The MAUI Framework that I use to target different platforms for “native” applications has a TTS (text to speech) interface. “Native” here means an app, with an icon on the “desktop”, and not a browsing interface. The web version would probably start to depart from the “native” app in this regard. (It is my design choice that apps are the first class citizen and the web was the visa holder)

After seeing this post I’m now considering a toggle switch that enables this function. It looks pretty free to use and my pipeline is already setup to fold it in. Here is an example of source code that shows how simple it is. await TextToSpeech.Default.SpeakAsync("Blah Blah Blah"); It also has regional settings that control the sound of the voice. I have not tried it but I’m going to now.

20

Have two separate versions for screenreader use and non-screenreader use. I Am Prey* and Portrait With Wolf do this.

*linking to the spring thing version because the ifdb version seems to be borked right now