In my WIP I ask the player whether they have played IF before and if not, I enable the tutorial mode, which currently does two things (I blatantly copied this idea from Bronze by Emily Short):
[1] highlighting names of things, e.g.:
At the Master’s Home
The noon sun beats mercilessly from a cloudless sky on the Master’s home, a modest dwelling at the end of a dusty road that leads east to the city. Its highly polished front door reflects dancing images formed by the lake to the south. The forest to the west has swallowed up the remainder of the road, and behind the house, a large mountain dominates the landscape.
[2] suggest commands to try, e.g.:
look to have a look around. i or inventory to have a look at your belongings. x sun or examine sun to have a look at the sun. open front door to open the front door.
Disabling this feature would disable both [1] and [2]. But I am wondering, might players also want to be able to only have [1] (the highlighting) without the (more or less spammy) dump of commands to try? As a game writer I use the highlighting to find any shortcomings (e.g. in forgetting to create a scenery object for something, or forgetting to properly define it), but I can imagine it is also convenient for a regular player (i.e. someone who did play IF previously…)
I would say yes. If the game has a long amount of text per description (in this I mean like a lot), I would prefer to have bold text for rooms, but I still don’t want actions. If people want to know where to look, but not exactly what to try, then that would be a preferred option.
In some cases, I like for players to know when certain nouns, phrases, or even verbs can be entered verbatim at the command prompt. Besides tutorial messages, I’ve used it for specific game mechanics that players might find confusing. Oh, and exits, too. I’ve also highlighted exits.
However, screen readers don’t pick up on bold type so far as I know, so I use
*THIS FORMAT*
When I asked around, I was told that this would be the best way. Asterisks are usually read as “star,” I think. Other screen reader users might feel differently; I know a player that advises me on this stuff as a person without sight.
Anyway, I guess my contribution is that you consider a format that works with screen reader tech. So far as whether people will want every noun highlighted in this way… I’m not sure. I would probably ask testers to try it. Unfortunately, since testers tend to be experienced players, you may have trouble finding your target audience in test.
Yes, I think so. I’ve played what I guess is about two thirds of Counterfeit Monkey – by the same author – and it had this sort of highlighting (I think as part of “easy mode”). It seemed to save time but I wondered whether it made me too “robotic” and reliant on the highlighting.
I definitely wouldn’t have wanted suggested commands. Though it did suggest topics to ask the characters. I don’t know whether that also was part of easy mode.
I was already using bold text for aesthetic but mechanically insignificant purposes, but I realize that this wouldn’t be important in a lot of games.
E: though I prefer the big “this is a video game” energy. I considered doing a conditional with fixed letter spacing, but I was worried about monospace players
Can anyone point me to a game which supports screen readers? I’d like to know how it works (e.g. does it explicitly ask if the user is using a screen reader, can it somehow detect it?) Technically I can format it any way I want to, right now I basically do something like this:
To say b:
say "[bold type]".
To say r:
say "[roman type]".
Before printing the name of something:
if the game-level is beginner, say "[b]".
After printing the name of something:
if the game-level is beginner, say "[r]".
Screen readers are usually an OS-level thing, so an interpreter usually can’t detect them. In my two games I’ve asked about accessibility features up front.
Phil’s recent game asks. Mine does, too. Both at the very beginning (technically, I ask if the player would like to read text descriptions for images).
I don’t know if Phil’s source is up somewhere. Mine is, but the setting doesn’t affect a whole lot.
E: IMO it’s fine to use bold text in a game, just don’t use it as the only way to experience a feature.
I have played Galaxy Jones or are you referring to the other two games in your name? When I choose the accessibility option I see text highlighting using blue text but also boldface…
Yeah in that case “accessible” just means no ascii banner. You can also turn off the blue text for the convenience of players using different color schemes.
I do use some features in my game which might be hard to “translate”…
[1] highlighting for nouns which can be referred to in commands (I could also consider that as a “feature for lazy readers who just want to pick out the things to look at etc”)
[2] highlighting for sample commands to try (the real meat of the tutorial bit)
[3] Italicized text for transitions, dialogue (back story), as a visual effect to make it stand out vs regular gameplay text.
[4] The phrase “— ( press any key ) —” to ensure its noticeable, I have no idea how that would read out for screen readers, if it reads as “dash dash dash …” then maybe I need to re-think the prompt.
[5] Some artwork (might be added later, all depends on timelines and availability of my artist), purely for a cosmetic effect.
I am not sure how to deal with the bigger challenges when looking at gameplay though. Looking at my puzzle designs, they look very visual to me (as in elements related to adjacent rooms etc. think sliding block puzzle but maybe thats not a good analogy). In fact one of the puzzles is like a mini chess mating puzzle. I can of course present that visually (like a board) or maybe as a list (where each piece is). But not sure what would be a better approach here.
1 & 2. I recently used the *EXAMPLE* construction for commands and some nouns. I think it went ok. If you aren’t using bold for anything else, you could probably do a substitution as Phil has suggested.
3. A lot depends on whether this is an appearance thing, or if someone needs to see it to understand. I used bold and italics extensively in my game, but I think people would understand the text without them.
4. I did
To say asterisks:
say "[if resolution is not 4]***[otherwise]"
as in say "[asterisks]Press Any Key to Continue[asterisks]"
I’m not sure about hyphens. Screen reader might not even read them aloud. I’m a Windows user, so I check things like that with NVDA and MS Narrator.
5. I think the convention there would be to make text descriptions an option. This is what people expect on Mastodon, etc
Just my thoughts re: dealing with these issues myself.
e:
Not every game is going to be accessible, but I think this forum is a good place for getting advice. It’s a thing people have wrestled with. You might want a new thread, since that’s a new issue to think about.
Do I understand correctly that it would look like this:
*AT THE MASTER'S HOME*
The noon *SUN* beats mercilessly from a cloudless *SKY* on the Master’s *HOME*,
a modest dwelling at the end of a dusty *ROAD* that leads east to the *CITY*.
Its highly polished *FRONT DOOR* reflects dancing images formed by the *LAKE* to the south.
The *FOREST* to the west has swallowed up the remainder of the road,
and behind the house, a large *MOUNTAIN* dominates the landscape.
And
*LOOK* to have a look around.
*I* or *INVENTORY* to have a look at your belongings.
*X SUN* or *EXAMINE SUN* to have a look at the sun.
*OPEN FRONT DOOR* to open the front door.
Since I don’t highlight every noun it isn’t so dramatic in my case.
She looks more unstable than previous sources of psychic energy I've encountered, but I should still be able to *SIPHON HER SICKNESS*.
or
The shower is a poor target for entropic magic as potent as *THE SEETHING ORDER*, especially since other, more productive (read: hazardous) candidates are nearby.
I’d probably do the conditional for nouns. On the other hand, I liked the way commands were formatted in my game. So probably a yes to the commands but the nouns need further consideration.
Formatting every noun as in in your example will probably be a challenge aesthetically. Bold for visual players is easy to “zone out” if the player doesn’t care about it. I’m not sure how screen reader players would experience so many special characters. It would be important to have a toggle during play, I think.
Thank you for your feedback, very much appreciated. It seems the best approach so far (until I can send something out for testing) is to make both features optional (the highlighting and the command hinting). Then players can toggle it on/off at any time (unless they do something so stupid in the beginning I have no option but to punish them severely by disabling all tutorial options and putting the game into its hardest difficulty just because I can *EVIL LAUGHTER ENSUES* ).
(Updated for screen reader compatibility. I wish I could check these things myself but I am not allowed to install any software on my company laptop. which is currently the only Windows compatible device I have available. I now am using a raspberry pi but that is not quite the same thing as a fully fledged PC. this summer I will buy a new PC.)
Just spent several hours refactoring and revising a lot of my code to implement something like this, as inspired by your post.
I am trying to make this game fairly forgiving for new players, but I also have quite a few new commands and concepts to communicate, and I was trying to figure out how to best handle this kind of scenario with screen readers!
I think I might also include an option at the beginning of the game that lets screen reader users choose which encapsulation they prefer.