I’ve read a little about the HTML TADS situation (such as this post), but I don’t totally understand it.
Would it be it correct to say that in order to run an HTML TADS game at all, you need a TADS interpreter that supports multimedia TADS? These are the posts that make me ask this question:
If this is the case, can we explain that more clearly on IFDB (on the 1893 page, for instance) and/or the IFWiki interpreter lists? Do we need a separate list of interpreters at IFWiki just for interpreters that will run HTML TADS games? I understand not all interpreters support all features, but if this is a situation where the game won’t even run at all, that seems like a different situation than an interpreter that has a reduced set of features but still runs the game.
Basically, if you want to play any TADS game, it’s best to play it in QTADS.
If you’re a screen reader user then I recommend Lectrote, and the TADS game should hopefully support a screen reader mode to accommodate the interpreter.
Hmm. I’ve now tried running 1893 in Lectrote just a little bit, and Lectrote does seem to run the game. It looks very confusing when you start, because there’s what looks like a menu, but instead of each menu option being on its own line, all options are together on the same line. (I’m not sure if this looks different on QTads?) And at one point the screen looks blank. But if I push enter I’m able to get to the next screen.
If I click the “play online” link on the IFDB page, it seems to get stuck on a “Loading” page for a while before getting to the menu screen.
For now I’ve edited the description of the download link on IFDB to add “To make sure the game displays correctly, please use an interpreter that supports Multimedia TADS, such as the QTads interpreter.”
Is this true? I tried running PQ in Lectrote, and it seems hopeless to try to use menus (hints and instructions)… the status bar wouldn’t show up, and the terp froze on pause-for-more…
You need to include logic in the game that is compatible with Lectrote as part of screen reader mode. Basically all menu functions don’t work outside of QTADS. Also, you generally don’t want to use status bars in screen reader mode, because screen readers don’t see them.
TADS has been beaten up over these issues for years now. The full game, with its images, maps, and compass rose in QTADS, looks so polished and professional. It’s almost a shame to default the game to a Play Online version instead of the complete version. Makes some of the IF classics look less appealing, not more.
The Glk terps will run TADS games in console mode (like a DOS or Linux console interpreter). Many games work really well in console mode, and most others run acceptably. But if the author didn’t ever test it in console mode then it could perhaps be almost unplayable. I haven’t actually ever seen reports of one that’s totally unplayable though.
In Lectrote, the title, the author, and the instructions for how to navigate the menu are missing. And the instructions at the bottom of the screen (“Please press a key”) are missing, too.
It seems like this game is not designed to be played in an interpreter that doesn’t support multimedia TADS.
Looks like the instructions are only in the image, so that’s a bit naughty from the perspective of accessibility. Adding images to Glk TADS is probably doable without the rest of HTML TADS support (I think I saw some experimental code that did so, but haven’t tried it myself. Edit: no, I was remembering experimental Hugo graphics code.)
It’s an old game so perhaps accessibility wasn’t as much of a public concern back then, but it’s unfortunate it wasn’t tested in text mode. 1893 used to be a commercial game, maybe it was only sold with an interpreter so that incompatibilities weren’t much of an issue?
I’m going to have to look at this the next time I get a chance. I thought the library automatically showed menus based on the terp’s ability. I don’t think I have the bandwidth any time soon to rewrite a second version of all the hint and instructional material…
I wonder if it would make sense to put a similar note near the Play Online link for this game, saying, “The online interpreter does not support all features of this game. To make sure the game displays correctly, please use a multimedia TADS interpreter, such as QTads.”
FWIW, there was some work done back in 2021 to make 1893 playable with VoiceOver (the macOS built-in screen reader) in Spatterlight, so that should still work for screen reader users on Mac.
Okay, I dug and tested a little deeper. Stock adv3 menus are indeed displayed by non-HTML terps without special logic, but with certain quirks. Lectrote’s quirk is the worst, where if there is a push-key-for-more prompt within a menu item, the program seems to freeze completely. It seems that all of them share another quirk (I tried Parchment, Lectrote, Gargoyle and Spatterlight in this wave): at least the first time a menu is accessed, the terp acts like the enter key has already been pressed for the first menu item. My game is supposed to provide the player with a menu to choose full or brief introductory text after typing BEGIN, but none of these interpreters provide the option, because they automatically select the first (longer) option. Then when the instructions are accessed, no menu appears but the player is dumped into the content of the first of the menu options (which happens to be “For beginners: concise version”). Subsequently, however, the instructions command will present the selectable menu, which mostly works normally (Gargoyle was almost unusably slow).
@Dannii , is there a common denominator in these TADS runners that causes it to seem like the command line is pre-loaded with an ENTER stroke, as soon as the menus are accessed? QTads does not do this. Much smaller note: in Parchment, the menu headings shift to the right a little bit when the arrow cursor is moved to them.
As far as I know, only @Morningstar has tried playing it in Spatterlight using VoiceOver, so it probably needs more testing before I could recommend it in good conscience.
