I’ve changed Texture to parser-choice hybrid. Pretty sure it’s right up there with Versificator 2 in this regard. By way of contrast, StoryNexus probably qualifies as strictly choice-based (and Eamon as parser-based). Hope that’s alright.
Hey, I know this one!
Quest has two modes:
- “text adventure” mode is parser + worldmodel - by default object and exit links are clickable, but a game author can turn these off
- “gamebook” is the multiple choice branching narrative link type
Looking at recent Quest games published on textadventures.co.uk there seems to be good mix of both types.
1 Like
Thanks!
How about Squiffy? Is it safe to say that games made with Squiffy are choice games?
Yes, Squiffy games are choice games (no worldmodel or parser)
1 Like
Thanks for all your help so far!
Let’s change the rules slightly. We can create a temporary (hopefully over by Christmas) value of “Probably Parser”. That would reduce the unknown games from 2,354 to just 323.
So it would be good to know which authoring systems are “Probably Parser”, especially the ones with several games. Let’s use the four-leaf clover for luck 
TADS 3 is able to make choice games. The two major libraries (Adv3 and Adv3Lite) are tooled for parser games, but TADS 3 as a platform was intended for general software, with a focus on text-based interfaces.
TADS 3 is to Adv3 as JavaScript is to Twine.
The reason why TADS 3 tends to be considered a parser system is because most people authoring a game with TADS 3 have chosen Adv3 or Adv3Lite for a library, and any interpreter which does not have a full implementation of the HTML TADS 3 spec will not support clickable buttons or clickable hyperlinks, so authors have been discouraged from trying to make a choice-based game in TADS 3, because players tend to strongly prefer a specific interpreter, and are unlikely to switch to a different one when the game tells them that they have the wrong interpreter for the game.
In fact, these warnings are only manually implemented by authors who are aware that this is even a problem. The HTML TADS 3 features are typically treated as perfectly normal and commonplace in the documentation, so using the wrong interpreter will often present the player with a single uninteractive, with zero indication that anything has gone wrong.
2 Likes
Do you support the various TADS variants as being “Probably Parser”? Or are any definitely “Parser” (in practice)?
1 Like
TADS 2 I have no idea.
TADS 3 should be categorized the same way as JavaScript would be.
Adv3 and Adv3Lite are libraries which are for making parser games.
The older non-HTML TADS 3 version is limited to type-in input only, but it’s successor/replacement handles clickable text and clickable images for sending actions.
WebTADS is actually a webpage system for handling TADS, and is directly the TADS version of Vorple. It requires a web browser to run, and you can directly embed JavaScript and other webpage tricks into it.
However, it’s very important to understand that HTML TADS 3 is like if Vorple didn’t require a web browser to play, and was supposed to make Inform 7 obsolete. HTML TADS 3 was supposed to replace non-HTML TADS 3, which is why Adv3 and Adv3Lite treat it as the current standard. This is like differentiating different versions of JavaScript; you only focus on ancient JavaScript versions to support old browsers, but the newer versions are treated as standard.
EDIT: Sorry if it feels like I’m avoiding the answer; the truth is that the framework of the question being asked doesn’t quite match the reality of the situation in the TADS ecosystem, so it’s very difficult to answer in a useful way.
Long Story Short
- TADS 2: Probably parser
- Outdated non-HTML TADS 3: Probably parser
- Modern (HTML) TADS 3: Could be parser, could be choice-based, could even be a music player or an image slideshow presenter. The statistics for how frequently it’s used for parser games is a direct result of ecological pressures put upon it by the wider IF community and history, and not a reflection of its actual capability.
- Adv3: Parser library
- Adv3Lite: Parser library
- WebTADS: Same as modern TADS 3, but hardly anyone uses it because it requires a client-server system to play.
TADS is still all Greek to me! My current thoughts are
- JavaScript
(can’t tell what it’s likely to be) - TADS (any variant) (probably parser)
1 Like
Sorry, I’m on mobile and didn’t see you post this. I’ve edited my previous post to have a hopefully-clearer breakdown.
1 Like
If we’re going by historical statistics of how TADS 3 is used, then it’s probably parser.
If we’re going by actual capabilities then it’s unknown.
And this is me flexing quite painfully to meet the framework of the question.
I would also like to say, though, that if we’re going with historical usage statistics, then JavaScript is likely choice-based.
I think this is the relevant part for IFWiki. People have built playable Tetris on the Z-machine, for example, but for cultural reasons it’s almost exclusively used for parser IF; if you want to build parser games on the Z-machine, there’s a whole ecosystem of dev systems and libraries and technologies to help you, while if you want to build Tetris, you’re left to pore over specification documents on your own.
Similarly, people could build a music player or a slideshow presenter in TADS, but I get the impression they generally don’t—at least not in the IF community?
2 Likes
I’d like to re-iterate the above, in this case. If this is disagreed with, then I would like public acknowledgement that an arbitrary exception is being made for an endangered IF language, based entirely on stereotype and assumptions.
JavaScript is also Greek to me (modern Greek maybe). I probably shouldn’t admit it, but I don’t know what you mean. Here are the interaction style figures for the 15 JavaScript games currently on IFWiki:
None (8) · Choice (3) · Parser (4) · Parser-choice hybrid (1)
That is wild. There are only 3 choice games on the IFWiki???
There are only three choice games that have JavaScript listed as an authoring system.
If a choice-based game uses Twine, then it uses JavaScript, according to the same category system that is being placed upon TADS 3.
1 Like
We’d have to look at the 15 games to confirm, but I think for both Twine and TADS people just haven’t included JavaScript as the authoring system in the wiki infobox.
1 Like
Sorry, I should have typed that out better. TADS shouldn’t get classified as JavaScript (to be clear), Twine games should be given the JavaScript tag, and TADS games should ideally be tagged as either Adv3 or Adv3Lite. Failing the latter, there should be a tag for “Adv3/Adv3Lite”.
I’m only being so neurotic about this because the wider cultural perception of TADS 3 matters quite a lot, especially when it has so few remaining authors.
In an ideal world, the categories would be consistent in what level/type of technology is being categorized, so:
- JavaScript would be at the same category specificity level as TADS 3.
- “Twine” (under JavaScript) and “Adv3/Adv3Lite” (under TADS 3) would be in the same subcategory specificity level.
- Snowman, Harlowe, Sugarcube, etc (under Twine) would be in the same subcategory specificity level as Adv3, Adv3Lite, Adv3Liter, etc (under “Adv3/Adv3Lite”).
- Choice would be applied to anything in the Twine subcategory.
- Parser would be applied to anything in the “Adv3/Adv3Lite” subcategory.
When all the TADS 3 authors are finally stretched too thin to keep the TADS 3 candle burning (hopefully a few decades from now), then I would demand at minimum that TADS be recorded and remembered for what it actually was.
If TADS 3 gets remembered as a parser authoring system, and not as a general-purpose language that had an ecosystem of individual parser authoring systems constructed from it, then that would be enough for me to leave the IF community. That is how important this neurotic clarification is for me.
This seems extreme, probably, but it’s been a severe pain point for a while now, and it feels like I’m trying to swim up a waterfall sometimes.
1 Like