[semi-OT] Roguelikes for the blind
Gero Kunter
think that RL developers might be interested in the topic.
Christian Pohl <chri...@web.de> wrote:
>> Joel Valleroy wrote:
>>
>>> How does someone who is blind play ADOM. I'm just wondering.. (excuse
>>> my bluntness)
[ ... ]
> My girlfriend uses JAWS, a screen-reader software which is basically a
> very sophisticated text-to-speech system. Thanks do ADOM's verbosity
> (especially when bumping into walls, among other things) it is very
> playable for her. [ ... ]
> Further, if she needs to find something specific, she simply uses the
> 'l'ook command. Once again, ADOM's verbose descriptions work very well.
Hi Christian,
As I'm working on a roguelike game myself, I'd like to know what I might
do to make my game playable for those who have to use screen-reader
software. You said that feedback for bumping into walls helps, which is
presumably true for all other actions: give textual feedback. What about
stat changes or hit point decreases? Any screen layout that is preferable
(for example having the messages at the top of the screen)? There is
probably an issue with colour usage -- colour shouldn't be used as the sole
carrier of information, anything else to be considered? What about the text
characters used for displaying the dungeon -- do non-ANSI charsets (anything
fancier than +-|#<>.) work?
> [ ... ] The only room/corridor-configurations that drive her mad are
> something like this (hopefully it wraps good)
> ################################################
> ................................................
> ####..>..#############....<..###################
> #.....# #.......#
> ####### #########
> since, if she does not pay attention, she might pass both rooms by and
> spend an eternity on the level looking for the stairs :-)
So maybe a message that indicates whenever a room is entered might help,
right? What about cavernous levels, like the penultimate level in the
puppy cave -- how does your girlfriend navigate through that?
> Of course, she needs a little more time per level than the average
> sighted player, but she doesn't mind, since ADOM is one of the few
> computer games (and the only RPG) she can play.
As most roguelike games don't use graphics, this is quite unfortunate. What
disqualifies other roguelikes? What makes, say, Nethack or Crawl unplayable
for her?
Thank you for sharing your and your girlfriend's experiences.
Cheers, Gero
--
Gero Kunter (gero....@epost.de)
Josh Singh
> I've crossposted this message to rec.games.roguelike.development, as I
> think that RL developers might be interested in the topic.
>
> Christian Pohl <chri...@web.de> wrote:
>
>>>Joel Valleroy wrote:
>>>
>>>
>>>>How does someone who is blind play ADOM. I'm just wondering.. (excuse
>>>>my bluntness)
>
> [ ... ]
>
>>My girlfriend uses JAWS, a screen-reader software which is basically a
>>very sophisticated text-to-speech system. Thanks do ADOM's verbosity
>>(especially when bumping into walls, among other things) it is very
>>playable for her. [ ... ]
>>Further, if she needs to find something specific, she simply uses the
>>'l'ook command. Once again, ADOM's verbose descriptions work very well.
>
>
> Hi Christian,
>
> As I'm working on a roguelike game myself, I'd like to know what I might
> do to make my game playable for those who have to use screen-reader
> software.
Actually, given that I'm also writing a roguelike, I'd like some
information as well. Accessibility to the blind never occurred to me
before now. Luckily my game is still in a very early stage.
I'm using Java to develop it (more out of necessity, rather than choice
like Herr Biskup with JADE). I suppose audible cues and suchlike are
easily implemented, but if someone could direct me to some resources on
making Java (Swing) applications accessible to the blind it would be
great. I probably won't have time to go through them thoroughly for a
while yet, but they'll be good to have later.
As for the huge and deep world I have planned, which will likely be
confusing enough in itself, I've also been plotting out the
preliminaries of (Gero, you're gonna love this) a "linguistic engine" to
generate text in various accents and dialects, as well as... erm...
tribal languages, in the case of barbarians. I doubt I'll be pulling
this out of the plans, as it's more than just a flavour element (i.e.
you may misunderstand an important NPC and screw something up as a
result, which I would find quite hilarious). Christian, I would like to
know how your girlfriend might handle such an arrangement. Would she
find it /as/ complicating as a sighted player would, or /more/?
If you don't quite know what I mean, I'll give an example of how the
engine might work. Say there is a particular provincial accent in which
the standard "th" sound is pronounced "s" ("thrill" --> "srill"). Given
the foreknowledge that variations exist, and given a sufficient amount
of text from which to empirically obtain knowledge of this particular
variation (this "rule"), would it still be too much of a hindrance for a
blind player? If it would not be significantly more difficult than it
would be for a sighted player, then I'll be able to subject all players
to the same torture (assuming they're not particularly fond of the whole
"linguistics" thing). If there would be significant difficulty, then I
suppose I would have to make the engine optional.. which, being a
Linguistics major as I am, would sort of suck. Don't get me wrong
though, I'll do it if I have to. I may have to in any case to allay
whining. :)
Keep in mind that talking to NPCs will be very important in this game,
although by no means will it be the main time-consumer (that's reserved
for slaughtering, of course). As well, the accent in the PC's home
province will be, logically, fully clear and comprehensible (in terms of
interface, it would be represented in standard English). How important
the home province's bearing is on a game will depend on certain factors
that I haven't worked out yet. It'll certainly be impossible to complete
the game without leaving that province, though.
I'm sure I haven't covered everything I need to here, so if there are
any other concerns I should be aware of, please let me (and everyone
else) know.
--
Curry Bucket's Controversial Web Presence:
The Birthplace of Teenage Angst
http://chat.carleton.ca/~jsingh3/
or http://www.currybucket.cjb.net/
ABCGi
topic :)
--
ABCGi (geek) http://codemonkey.sunsite.dk S14 D15 C13 I17 W9 c12
GCS/IT$/L/B$ d+(-) s: a? C++ ULUSU-- P+ L+>++ E- W++$ N+ o+ K--
w+++(--)$ O- !M- V PS++(+) PE-@ Y+(++) PGP>++ t++ 5+ X R(+++) tv
b++(+) DI++++ D+++ G e++>+++ h++(home office!) r++ y++* BAS-----
Christian Pohl
<snipples beginning>
> Hi Christian,
>
> As I'm working on a roguelike game myself, I'd like to know what I might
> do to make my game playable for those who have to use screen-reader
> software. You said that feedback for bumping into walls helps, which is
> presumably true for all other actions: give textual feedback. What about
> stat changes or hit point decreases? Any screen layout that is preferable
> (for example having the messages at the top of the screen)? There is
> probably an issue with colour usage -- colour shouldn't be used as the sole
> carrier of information, anything else to be considered? What about the text
> characters used for displaying the dungeon -- do non-ANSI charsets (anything
> fancier than +-|#<>.) work?
The first order of business would be that the "map area" terminates with
the left/right window/screen border. One thing that makes Crawl
unplayable for her is that the characters' stat block is on the
right-hand side of the screen. The screen reader usually works in "line
mode", so it reads the whole line, producing even more gibberish than
normal.
One feature my girlfriend uses a lot is the 'l'ook command, which
provides astounding levels of information, starting from the floor space
the cursor is positioned ("tunnel" in corridors, "a section of floor" in
rooms) up to monster info ("You see an ogre. It is hostile. It is not
injured). The only thing the ADOM 'l'ook command does NOT tell is the
character's position.
Consider the following:
This is a goblin. It is hostile. bla bla.
########
#...@g.#
#....^.. <- ^= Cursor position
########
A section of floor.
########
#...@g.#
#...^... <- ^= Cursor position
########
Further, ADOM gives feedback while moving. Every time you move, the
description line on the top two lines is updated, something no other
roguelike does, neither NetHack, nor Angband, nor Crawl. Believe me, we
have tried 'em all.
Back to "display" techniques. Adom has several status messages (lower
left hand side, like Coward, Hungry! or Poison). They ARE coloured, but
further, they use exclamation points to signify the severity of the
condition (at least when burden/hunger levels are concerned). But these
status changes are also mentioned in the descriptive text ("The dark
elven lord hits you. You feel poisoned!")
Thanks to the turn-based nature of the gameplay, my girlfriend has ample
time to pause and use some manual functions of her screenreader to get
needed info. Since the hit points are not updated audially (sp?) she
takes a break from hackin' and slashin' every couple of turns to switch
to "read mode" and check out how bad she's hurt. So that's not a big
problem.
While on the topic of "read mode". I don't know what kind of display
routines Thomas uses, but the ADOM output seems to be the only one the
screenreader my girlfriend uses can process. As mentioned before, we
tried several other roguelikes, but they seem to use some kind of
graphical output (although it shows Ansi/Ascii characters). NetHack in
pure ascii mode at least outputs the status bar, but Angband doesn't
work at all. Crawl seems to work, although the screen layout and lack of
movement feedback prevents any kind of enjoyment for her.
<snipples room/corridor thingy>
>
> So maybe a message that indicates whenever a room is entered might help,
> right? What about cavernous levels, like the penultimate level in the
> puppy cave -- how does your girlfriend navigate through that?
>
To quote a horrible german song: "immer an der Wand lang" :-) (Cling to
the wall)
She picks a direction at random, walks until she hits a wall and follows
it. Afterwards she picks one "corner" or alcove and uses the 'l'ook
cursor to peek into the center of the room, slowly mapping out the "you
don't know anything about this place"-map squares. As she just told me,
it's _very_ bothersome and takes ungodly amounts of time, but nevermind.
A _really_ cool feature would be if the game would announce "You enter a
room. It contains x beings, y items and a stair up/down". That would of
course only work if there's a clear distinction between rooms and
corridors. Just phantasizing: Maybe have this system work with several
verbosity levels, the most verbose stating the above, the minimal
setting just state "entering a room" and as a third option to toggle if
off (for the fully sighted :-))
>
<snip>
> As most roguelike games don't use graphics, this is quite unfortunate. What
> disqualifies other roguelikes? What makes, say, Nethack or Crawl unplayable
> for her?
see above :->
>
> Thank you for sharing your and your girlfriend's experiences.
>
> Cheers, Gero
You're welcome. If you need beta testers, just yell or throw a mail our
way. For imformational purposes, you might want to download the trial
version of JAWS for Windows from either www.freedomscientific.com or
www.freedomsci.de
See you around
Christian "BlackFurredBeast" Pohl
Christian Pohl
Sound effects are not neccessarily needed, as long as you don't plan on
using a text-to speech engine in the game itself ie. make it "self
voicing". JAWS is a real sound thread hog, completely killing all other
sound threads going to the sound card (Not even Winamp plays at the same
time when JAWS is active).
As far as developing accessible games is concerned, maybe you should try
www.audiogames.net, although this site (as is obvious from it's name)
revolves mainly around sound-based games.
>
> As for the huge and deep world I have planned, which will likely be
> confusing enough in itself, I've also been plotting out the
> preliminaries of (Gero, you're gonna love this) a "linguistic engine" to
> generate text in various accents and dialects, as well as... erm...
> tribal languages, in the case of barbarians. I doubt I'll be pulling
> this out of the plans, as it's more than just a flavour element (i.e.
> you may misunderstand an important NPC and screw something up as a
> result, which I would find quite hilarious). Christian, I would like to
> know how your girlfriend might handle such an arrangement. Would she
> find it /as/ complicating as a sighted player would, or /more/?
<snipples explanation>
Nah, don't worry. As long as the general text output can be managed with
JAWS, a blind player can simply have specific words SPELLED letter by
letter through the screen reader. That's actually the way my girlfriend
gets the monster names in ADOM (for using with the Monster Memory)
And the dwarves' accent (or the grizzled gladiator) is fully
understandable to her.
>
> Keep in mind that talking to NPCs will be very important in this game,
> although by no means will it be the main time-consumer (that's reserved
> for slaughtering, of course). As well, the accent in the PC's home
> province will be, logically, fully clear and comprehensible (in terms of
> interface, it would be represented in standard English). How important
> the home province's bearing is on a game will depend on certain factors
> that I haven't worked out yet. It'll certainly be impossible to complete
> the game without leaving that province, though.
>
> I'm sure I haven't covered everything I need to here, so if there are
> any other concerns I should be aware of, please let me (and everyone
> else) know.
>
Hope that helped a bit
Christian "BlackFurredBeast" Pohl
Gero Kunter
> I don't see RL's for the blind as anything near off topic. It is very on
> topic :)
The thread started in rec.games.roguelike.adom, as Christian posts there,
and I crossposted it to r.g.r.d, hence the subject line.
Gero Kunter
[ ... ]
> The first order of business would be that the "map area" terminates with
Okay, that is helpful information. What about the positioning of the text
messages? Does it make any difference in accessability if they are displayed
below the map, above the status line instead of the more traditional first
lines of the screen?
> One feature my girlfriend uses a lot is the 'l'ook command, which
> provides astounding levels of information, starting from the floor space
> the cursor is positioned ("tunnel" in corridors, "a section of floor" in
> rooms) up to monster info ("You see an ogre. It is hostile. It is not
> injured). The only thing the ADOM 'l'ook command does NOT tell is the
> character's position.
You mean the fact that there is no indication whether the cursor is on
the PC's position or not? I can see that this might help orientation, and
is easily avoided.
[ ... ]
> Further, ADOM gives feedback while moving. Every time you move, the
> description line on the top two lines is updated, something no other
> roguelike does, neither NetHack, nor Angband, nor Crawl. Believe me, we
> have tried 'em all.
Do you mean that it's important that the message lines are cleared after
every player turn, even if there is no actual new message?
> Back to "display" techniques. Adom has several status messages (lower
> left hand side, like Coward, Hungry! or Poison). They ARE coloured, but
> further, they use exclamation points to signify the severity of the
> condition (at least when burden/hunger levels are concerned). But these
> status changes are also mentioned in the descriptive text ("The dark
> elven lord hits you. You feel poisoned!")
What about the fact that ADOM, and most of the more complex roguelikes,
use the same letter, but in different colours, for different monsters of a
similar type (light green 'O's for normal ogres, bright cyan 'O's for ogre
mages etc.)? Is the additional information provided by the 'l'ook command
sufficient for differentiating them? Given the scope of my game, I've
thought about assigning a unique letter to each monster, so that wouldn't
be a problem, but I'd just want to ask this point for clarity.
[ ... ]
> While on the topic of "read mode". I don't know what kind of display
> routines Thomas uses, but the ADOM output seems to be the only one the
> screenreader my girlfriend uses can process. As mentioned before, we
> tried several other roguelikes, but they seem to use some kind of
> graphical output (although it shows Ansi/Ascii characters). NetHack in
> pure ascii mode at least outputs the status bar, but Angband doesn't
> work at all. Crawl seems to work, although the screen layout and lack of
> movement feedback prevents any kind of enjoyment for her.
Hmmm... That's a tough issue. The (n)curses library is the standard
library for this sort of text output, and it is used in many or most
roguelike games, apparently including ADOM. I'd have thought that Nethack
and Angband also used this library, but there seems to be some other factor
involved.
> <snipples room/corridor thingy>
>>
>> So maybe a message that indicates whenever a room is entered might help,
>> right? What about cavernous levels, like the penultimate level in the
>> puppy cave -- how does your girlfriend navigate through that?
>>
> To quote a horrible german song: "immer an der Wand lang" :-) (Cling to
> the wall)
Fortunately I seem to be completely ignorant of this song! :)
> She picks a direction at random, walks until she hits a wall and follows
> it. Afterwards she picks one "corner" or alcove and uses the 'l'ook
> cursor to peek into the center of the room, slowly mapping out the "you
> don't know anything about this place"-map squares. As she just told me,
> it's _very_ bothersome and takes ungodly amounts of time, but nevermind.
Okay, so caverns are suboptimal. Mental note added.
> A _really_ cool feature would be if the game would announce "You enter a
> room. It contains x beings, y items and a stair up/down". That would of
> course only work if there's a clear distinction between rooms and
> corridors. Just phantasizing: Maybe have this system work with several
> verbosity levels, the most verbose stating the above, the minimal
> setting just state "entering a room" and as a third option to toggle if
> off (for the fully sighted :-))
This is, in fact, an idea that I pondered upon while I was lying in bed
this morning. I thought about keeping a list of all monsters and items that
are currently in the field of view, with a (probably configurable)
notification whenever something new enters this field, and a command to
display the information contained in the list. A problem that I see with your
suggestion is that monsters and items don't only appear inside of rooms
(Martin Read's Dungeon Bash is the only exception that I know of). Hmmm...
This feature needs some more thought and beta-testing, I think.
[ ... ]
> You're welcome. If you need beta testers, just yell or throw a mail our
> way. For imformational purposes, you might want to download the trial
> version of JAWS for Windows from either www.freedomscientific.com or
> www.freedomsci.de
Thanks for the link and the offer. A problem is, however, that I'm
programming my project in Python under Linux. Installing Python under
Windows, and getting ncurses run as well, is not exactly trivial, but doable
(for example, you'd have to download the whole Python interpreter, which is
a package of something like 10 MB). I'll have another look at this issue
over the weekend.
For beta testing, there isn't that much yet to test: levels get created
(and flooded, for that matter), monsters can be fought, items be gathered.
Personally I like playing it, but of course every parent thinks that their
own baby is the most beautiful ever... :) But if you're still interested, we
might get in touch about this. (Note that I hardly ever check the email
address I use for newsgroups. If you want to send me an email, try
gero Punkt kunter at gmx Punkt de)
Gero Kunter
[ ... ]
> As for the huge and deep world I have planned, which will likely be
> confusing enough in itself, I've also been plotting out the preliminaries
> of (Gero, you're gonna love this) a "linguistic engine" to generate text
> in various accents and dialects, as well as... erm... tribal languages,
> in the case of barbarians.
How did you know I'd be interested in this? :) Even though I ditched that
aspect in my current roguelike game, playing around with Markov chains to
create random names that still matched the theme of each settlement
(Egyptian/Nordic/Greek etc.) was implemented in my previous project almost
before I had any display routines!
The Sheep
> In rec.games.roguelike.development Christian Pohl <chri...@web.de> wrote:
> This is, in fact, an idea that I pondered upon while I was lying in bed
> this morning. I thought about keeping a list of all monsters and items that
> are currently in the field of view, with a (probably configurable)
> notification whenever something new enters this field, and a command to
> display the information contained in the list. A problem that I see with your
> suggestion is that monsters and items don't only appear inside of rooms
> (Martin Read's Dungeon Bash is the only exception that I know of). Hmmm...
> This feature needs some more thought and beta-testing, I think.
I think it is a good solution for the even-based AI. Might be annoying
when tehre are `coward' monsters clinging on the edge of your FOV, though.
--
Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
`The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
ABCGi
> ABCGi <ab...@yahoo.com> wrote:
>
>>I don't see RL's for the blind as anything near off topic. It is very on
>>topic :)
>
> The thread started in rec.games.roguelike.adom, as Christian posts there,
> and I crossposted it to r.g.r.d, hence the subject line.
Still on topic and a good idea to cross post :)
[Cross post]Roguelikes for the blind maybe, but why bother...
Christian Pohl
> In rec.games.roguelike.development Christian Pohl <chri...@web.de> wrote:
> [ ... ]
<on screen layout>
> Okay, that is helpful information. What about the positioning of the text
> messages? Does it make any difference in accessability if they are displayed
> below the map, above the status line instead of the more traditional first
> lines of the screen?
>
Don't know. So far we had only ADOM to test this thoroughly, and it uses
the first two lines. If it doesn't involve to much code shuffling, it
would be best to simply try both versions. :-)
<on 'l'ook mode>
>
> You mean the fact that there is no indication whether the cursor is on
> the PC's position or not? I can see that this might help orientation, and
> is easily avoided.
Yup, you got it.
<on move feedback>
>
> Do you mean that it's important that the message lines are cleared after
> every player turn, even if there is no actual new message?
>
Don't get me wrong. ADOM generates a message for each move you make.
Check out the first few steps after firing up a new game, you'll get
terrain feedback "a road"... until you actually hit something else, like
"plains", "forest" etc. It even goes farther, including such flavor
messages like "you pass beneath a beautiful tree" when walking in
Terinyo. Check out what I mean :-)
To clear up any old text would be in order anyway, coupled with a
message buffer, so if you are busy hacking monsters to bits, you can
review the battle later. Cue: ':m'-command in ADOM.
<on monster feedback>
> What about the fact that ADOM, and most of the more complex roguelikes,
> use the same letter, but in different colours, for different monsters of a
> similar type (light green 'O's for normal ogres, bright cyan 'O's for ogre
> mages etc.)? Is the additional information provided by the 'l'ook command
> sufficient for differentiating them? Given the scope of my game, I've
> thought about assigning a unique letter to each monster, so that wouldn't
> be a problem, but I'd just want to ask this point for clarity.
no big problem here, the 'l'ook cursor clearly states monster and
variant, including wound, hostility and experience status. You need to
use it more, it seems :-)
<on courses libraries and other hi-tech>
>
> Hmmm... That's a tough issue. The (n)curses library is the standard
> library for this sort of text output, and it is used in many or most
> roguelike games, apparently including ADOM. I'd have thought that Nethack
> and Angband also used this library, but there seems to be some other factor
> involved.
Maybe that has to do with the tileset support NH and *Angband have?
<on cavernous levels>
>
> Okay, so caverns are suboptimal. Mental note added.
>
Yes, but a challenge. The CoC huge cavern is one of my girlfriends'
favorite spots for monster hunting. But there's just four walls, two
staircases and bucketfuls of beasties.
<on room inventories>
>
> This is, in fact, an idea that I pondered upon while I was lying in bed
> this morning. I thought about keeping a list of all monsters and items that
> are currently in the field of view, with a (probably configurable)
> notification whenever something new enters this field, and a command to
> display the information contained in the list. A problem that I see with your
> suggestion is that monsters and items don't only appear inside of rooms
> (Martin Read's Dungeon Bash is the only exception that I know of). Hmmm...
> This feature needs some more thought and beta-testing, I think.
>
No need to go all crazy here. On the most basic level, the feature could
simply alert if there's a staircase in there. The rest, especially
monsters, get noticed anyway :-)
> [ ... ]
>
>
>>You're welcome. If you need beta testers, just yell or throw a mail our
>>way. For imformational purposes, you might want to download the trial
>>version of JAWS for Windows from either www.freedomscientific.com or
>>www.freedomsci.de
>
>
> Thanks for the link and the offer. A problem is, however, that I'm
> programming my project in Python under Linux. Installing Python under
> Windows, and getting ncurses run as well, is not exactly trivial, but doable
> (for example, you'd have to download the whole Python interpreter, which is
> a package of something like 10 MB). I'll have another look at this issue
> over the weekend.
Well, I'm not good at coding, but I can manage some system setup myself,
and with a 10 Mbit fiber uplink into the 'net, 10 MB are a snap.
>
> For beta testing, there isn't that much yet to test: levels get created
> (and flooded, for that matter), monsters can be fought, items be gathered.
> Personally I like playing it, but of course every parent thinks that their
> own baby is the most beautiful ever... :) But if you're still interested, we
> might get in touch about this. (Note that I hardly ever check the email
> address I use for newsgroups. If you want to send me an email, try
> gero Punkt kunter at gmx Punkt de)
Maybe there isn't much content yet, but at least the compatibility with
JAWS can be tested, for example with the message line positioning etc.
Have a nice evening!
Regards
Christian "BlackFurredBeast" Pohl
Ray Dillinger
> The first order of business would be that the "map area" terminates with
> the left/right window/screen border. One thing that makes Crawl
> unplayable for her is that the characters' stat block is on the
> right-hand side of the screen. The screen reader usually works in "line
> mode", so it reads the whole line, producing even more gibberish than
> normal.
Hm? Crawl's stat block reads as gibberish? Isn't it just something
like stat:value every line? like this?
str: 15
con: 17
dex: 18
I'd have thought that the map itself would be way more confusing
and gibberish in line mode.
Duly noted though; configurable layout would seem to be the
right thing.
> One feature my girlfriend uses a lot is the 'l'ook command, which
> provides astounding levels of information, starting from the floor space
> the cursor is positioned ("tunnel" in corridors, "a section of floor" in
> rooms) up to monster info ("You see an ogre. It is hostile. It is not
> injured). The only thing the ADOM 'l'ook command does NOT tell is the
> character's position.
Hmmm. A 'l'ook command that allows you to position the cursor and
get target info. That's reasonable. I like a 'L'ook command that
allows you to use 'tab' to jump around to points of interest from
closest to furthest, but I see where it would only be useful for a
blind player if it included some indication of distance and direction.
> Further, ADOM gives feedback while moving. Every time you move, the
> description line on the top two lines is updated, something no other
> roguelike does, neither NetHack, nor Angband, nor Crawl. Believe me, we
> have tried 'em all.
Hm. Okay.... currently I have messages for walking into walls,
closed doors, onto stairs, etc. I report all movement *exceptions*.
But I hadn't thought it was worthwhile to have messages for
"unexceptional movement" like moving on floors. Is this important?
> Back to "display" techniques. Adom has several status messages (lower
> left hand side, like Coward, Hungry! or Poison). They ARE coloured, but
> further, they use exclamation points to signify the severity of the
> condition (at least when burden/hunger levels are concerned).
I copied that. Hunger, poisoning, wounded, and several other status
messages use varying numbers of exclamation points (0 = point of
information, 4 = you will die very soon if you don't do something
about this now) to indicate severity.
> But these
> status changes are also mentioned in the descriptive text ("The dark
> elven lord hits you. You feel poisoned!")
Don't have that. Yet. I should definitely add it. Status changes
are important game events.
> Thanks to the turn-based nature of the gameplay, my girlfriend has ample
> time to pause and use some manual functions of her screenreader to get
> needed info. Since the hit points are not updated audially (sp?) she
> takes a break from hackin' and slashin' every couple of turns to switch
> to "read mode" and check out how bad she's hurt. So that's not a big
> problem.
Better to have hitpoint messages in the message stream, at least
as an option?
"The Elf Lord hits you. You have 37 hitpoints left. You feel poisoned!"
> While on the topic of "read mode". I don't know what kind of display
> routines Thomas uses, but the ADOM output seems to be the only one the
> screenreader my girlfriend uses can process. As mentioned before, we
> tried several other roguelikes, but they seem to use some kind of
> graphical output (although it shows Ansi/Ascii characters). NetHack in
> pure ascii mode at least outputs the status bar, but Angband doesn't
> work at all. Crawl seems to work, although the screen layout and lack of
> movement feedback prevents any kind of enjoyment for her.
Adom uses ncurses, directly. *bands mostly use a replacement
library that provides the same interface as curses but doesn't
actually work in character mode. The "characters" in *bands
are just another tileset. Someone could probably compile
Angband etc. to use just plain curses again in an afternoon or
so of work spent hacking out the tile support.
> A _really_ cool feature would be if the game would announce "You enter a
> room. It contains x beings, y items and a stair up/down". That would of
> course only work if there's a clear distinction between rooms and
> corridors. Just phantasizing: Maybe have this system work with several
> verbosity levels, the most verbose stating the above, the minimal
> setting just state "entering a room" and as a third option to toggle if
> off (for the fully sighted :-))
That seems to be a good, flexible approach. Each message would
be associated with a priority level, and you could set the game's
verbosity to include only messages above a particular priority
level. So the sighted player could set verbosity 3, and only
get "kill" messages and errors, and a blind player could set
verbosity 20, and get approximate personal and monster injury
levels after every hit, relative locations of monsters, etc.
It's fairly easy to code, too.
Bear
Christian Pohl
<snip>
>
> Hm? Crawl's stat block reads as gibberish? Isn't it just something
> like stat:value every line? like this?
>
> str: 15
> con: 17
> dex: 18
>
>
> I'd have thought that the map itself would be way more confusing
> and gibberish in line mode.
sorry for me being a bit unclear on this one. You're right, of course.
The stats themselves are absolutely clear, but it is a little confusing
to have the map read out and then, directly afterwards, the stats.
<snip>
> Hmmm. A 'l'ook command that allows you to position the cursor and
> get target info. That's reasonable. I like a 'L'ook command that
> allows you to use 'tab' to jump around to points of interest from
> closest to furthest, but I see where it would only be useful for a
> blind player if it included some indication of distance and direction.
>
sure, for a sighted player a "jumpy" look command is helpful, since it
eliminates unneccessary keypresses, but the blind player needs to
pinpoint where _exactly_ a thing is.
>> Further, ADOM gives feedback while moving. Every time you move, the
>> description line on the top two lines is updated, something no other
>> roguelike does, neither NetHack, nor Angband, nor Crawl. Believe me,
>> we have tried 'em all.
>
>
> Hm. Okay.... currently I have messages for walking into walls,
> closed doors, onto stairs, etc. I report all movement *exceptions*.
> But I hadn't thought it was worthwhile to have messages for
> "unexceptional movement" like moving on floors. Is this important?
>
At least a feedback that announces if the move was successful. On the
most basic level a simple "tick" from the PC speaker, if you are loath
to include floor checks :-)
>> Back to "display" techniques. Adom has several status messages (lower
>> left hand side, like Coward, Hungry! or Poison). They ARE coloured,
>> but further, they use exclamation points to signify the severity of
>> the condition (at least when burden/hunger levels are concerned).
>
>
> I copied that. Hunger, poisoning, wounded, and several other status
> messages use varying numbers of exclamation points (0 = point of
> information, 4 = you will die very soon if you don't do something
> about this now) to indicate severity.
>
>> But these status changes are also mentioned in the descriptive text
>> ("The dark elven lord hits you. You feel poisoned!")
>
>
> Don't have that. Yet. I should definitely add it. Status changes
> are important game events.
>
>> Thanks to the turn-based nature of the gameplay, my girlfriend has
>> ample time to pause and use some manual functions of her screenreader
>> to get needed info. Since the hit points are not updated audially
>> (sp?) she takes a break from hackin' and slashin' every couple of
>> turns to switch to "read mode" and check out how bad she's hurt. So
>> that's not a big problem.
>
>
> Better to have hitpoint messages in the message stream, at least
> as an option?
>
> "The Elf Lord hits you. You have 37 hitpoints left. You feel poisoned!"
ADOM includes a configurable bell when hitpoints are low or starvation
sets in. Maybe do it like (I don't know which one had it) *band or
Crawl, which has a configurable "low hitpoint warning".
"The Ogre hits you. LOW HITPOINT WARNING!" So you don't need to clutter
the message stream too much.
>
>> While on the topic of "read mode". I don't know what kind of display
>> routines Thomas uses, but the ADOM output seems to be the only one the
>> screenreader my girlfriend uses can process. As mentioned before, we
>> tried several other roguelikes, but they seem to use some kind of
>> graphical output (although it shows Ansi/Ascii characters). NetHack in
>> pure ascii mode at least outputs the status bar, but Angband doesn't
>> work at all. Crawl seems to work, although the screen layout and lack
>> of movement feedback prevents any kind of enjoyment for her.
>
>
> Adom uses ncurses, directly. *bands mostly use a replacement
> library that provides the same interface as curses but doesn't
> actually work in character mode. The "characters" in *bands
> are just another tileset. Someone could probably compile
> Angband etc. to use just plain curses again in an afternoon or
> so of work spent hacking out the tile support.
>
sure, but to make *band playable for the blind, more work needs to be
done, like a freelook command or better move feedback...
>> A _really_ cool feature would be if the game would announce "You enter
>> a room. It contains x beings, y items and a stair up/down". That would
>> of course only work if there's a clear distinction between rooms and
>> corridors. Just phantasizing: Maybe have this system work with several
>> verbosity levels, the most verbose stating the above, the minimal
>> setting just state "entering a room" and as a third option to toggle
>> if off (for the fully sighted :-))
>
>
> That seems to be a good, flexible approach. Each message would
> be associated with a priority level, and you could set the game's
> verbosity to include only messages above a particular priority
> level. So the sighted player could set verbosity 3, and only
> get "kill" messages and errors, and a blind player could set
> verbosity 20, and get approximate personal and monster injury
> levels after every hit, relative locations of monsters, etc.
>
> It's fairly easy to code, too.
>
> Bear
>
Well, nice to hear some pro's opinion :-) I'm no good at all at coding,
but the creativity department works fairly well :-)
Have a good time
Christian "BlackFurredBeast" Pohl
Martin Read
>sure, but to make *band playable for the blind, more work needs to be
>done, like a freelook command or better move feedback...
Angband's "look" command already *is* a "freelook". (use 'o'ffset targeting
instead of +/- targeting.) It just needs a bit better feedback, I
suspect.
--
Martin Read - my opinions are my own. share them if you wish.
My roguelike games page (including my BSD-licenced roguelike) can be found at:
http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
The Sheep
> Ray Dillinger wrote:
>> Adom uses ncurses, directly. *bands mostly use a replacement
>> library that provides the same interface as curses but doesn't
>> actually work in character mode. The "characters" in *bands
>> are just another tileset. Someone could probably compile
>> Angband etc. to use just plain curses again in an afternoon or
>> so of work spent hacking out the tile support.
> sure, but to make *band playable for the blind, more work needs to be
> done, like a freelook command or better move feedback...
Angband runs in text mode when invoked from text terminal.
I guess there was a commandline option to run it in text mode regardless
of the terminal it's invoked.
The look command can use cursor keys -- you have to switch it's mode.
You can even bind sounds to game events (not sure whether you can bind
a sound for walking, but you can surely bind one for `bumping the wall')
matija
> As I'm working on a roguelike game myself, I'd like to know what I might
> do to make my game playable for those who have to use screen-reader
> software. You said that feedback for bumping into walls helps, which is
> presumably true for all other actions: give textual feedback. What about
> stat changes or hit point decreases? Any screen layout that is preferable
> (for example having the messages at the top of the screen)?
perhaps several extended info screens would be very helpful.
let's take this ADoM layout snippet for example:
###########
..f....rk.+
####..O...#
#._.@.(#
########
<examples>
you are at dungeon coordinate 47,12.
nearby monsters:
a cave lion at 42,10 (peaceful)
a ratling archer at 47,10 (immediate threat!)
a kobold at 47,10 (hostile)
an ogre at 46,11 (immediate threat!)
nearby items and features:
a closed door at 50,10
a lawful altar at 45,12
a wooden arrow at 47,12, beneath you
a weapon at 49,12
changes in the last turn:
your willpower increased by 1 to 18 points!
an arrow fired by a ratling archer at 47,10 hit you!
your hitpoints have dropped by 8 to 35 out of 43 points!
a cave lion moved from 43,10 to 42,10.
an ogre moved from 45,11 to 46,11 and is now an immediate threat!
a kobold at 47,10 is now hostile!
</example>
--
there is a cheer. the gnomes have learned a new way to say hooray. [-shpongle]
address is scrambled - remove the superfluous "x" marks to reply
The Sheep
I think it'd be much better to use coordinates relative to the player
character.
Christian Pohl
<on coordination systems>
>
> I think it'd be much better to use coordinates relative to the player
> character.
>
I'd strongly disagree. The relative approach might be less spoily (since
you don't know where in the greater scope of things you are) but the
fixed system would be easier to handle, IMHO. If the player has it put
down firmly, it would quickly become second nature to calculate in
coordinates. But I'm open to counter-examples though :-)
Cheers
Christian "BlackFurredBeast" Pohl
Christian Pohl
announces the coords, it would make a very helpful navigation tool.
Furthermore, it could deal with dungeons that are larger than 1 screen
(by simply expanding the coord grid)
Cheers
Christian "BlackFurredBeast" Pohl
The Sheep
But most of the time you don't care where on the dungeon the object is.
You want to know how far it is and how to get there.
Relative coordinates will tell you exactly this, without the need for any
calculations. If yous see (-3,5) then you know you must press `left' three
times and `up' five times to get there. The order in which to press those
keys may, offcourse, depend on the obstacles in the way.
To know relative positions of the objects you still have to do some
calculations, but with relative coordinates the numbers you're dealing
with are much smaller.
Those kinds of things would have to be tested, however, to really decide.
There could be one more approach -- just give the path to given objkect,
instead of coordinates, something like `88899' meaning 3 steps north and
two steps north-east. A path without obstacles would be chosen.
But this approach makes it hard to compare relative positions of objects.
Gero Kunter
> matija wrote:
>> perhaps several extended info screens would be very helpful.
>> let's take this ADoM layout snippet for example:
[ ... ]
>> you are at dungeon coordinate 47,12.
>>
>> nearby monsters:
>> a cave lion at 42,10 (peaceful)
>> a ratling archer at 47,10 (immediate threat!)
>> a kobold at 47,10 (hostile)
>> an ogre at 46,11 (immediate threat!)
[ ... ]
> Interesting idea. When combined with a look command that actually
> announces the coords, it would make a very helpful navigation tool.
Both implemented into my game this afternoon. matija, the extended info
screen was a great idea, I think!
Christian Pohl
How about a "level features overview" screen? Of course that should only
contain features that the character has already discovered. A sighted
player need only check the screen on levels he visited to check where
shops, stairs, altairs and pools are, but for a blind player,
re-visiting a level often necessitates exploring it again just to find
stuff already found on the first run through. So that screen could tell:
Discoveries on this level:
Stairs down at (14,8)
Stairs up at (69,22)
Evil altair at (55,17)
Would that be feasible?
Christian "BlackFurredBeast" Pohl