This is a good discussion to ferret out how things are described. For example, the TADS 3 documentation describes it thusly:
And, of course, if you dig in:
Which is all great. But what a lot of authors I talk with – and every one who attends my classes – want to really know is simply this: “How do I provide the experience I want?”
This is a question they would ask of Inform 7 as well. So this would come up, for example, with Vorple or flexible windows.
Thus notice, contrary to the title of this overall post, what I find authors are often asking about in relation to “comprehensiveness” is not about the language (output) but about the actual game/story experience (outcome).
So consider: if “comprehensiveness” to someone means an answer to this question: “I want to be able to use modern typography – colors, styles, sizes – along with images and sounds, will my players/readers be able to experience that?” …
… well, that’s the only question worth answering for them.
I say that because the readers/players don’t care about the programming language. They only care about the experience. And a lot of what has been discussed in this thread is not so much about what the languages can do but rather about what the supporting ecosystem can provide.
It’s a reasonable question to ask. Everywhere you look there are social media sites where all those elements are in abundance. Even in the workplace now, Business IT is adopting the same approach.
We’re currently in a web-native world. Frameworks that seek to continue the lineage of the classic formats maybe create for themselves a challenge in aligning with the modern paradigm.
I’ve never used TADS. But the headless server mode sounds to me to be the way you’d go if you want to provide a rich web experience.
Features aside, my impression is that many (most) of us choose a language because we think it would be fun/pleasant to learn.
I thought I would enjoy learning Inform 7, while I expected to dislike learning the others. After looking around, I know that I was right. Others have chosen different languages for similar reasons. The features horserace is an important subject, but in this hobbyist space, determining which language would be most enjoyable is a meaningful consideration.
But that Vorple analogy doesn’t quite make sense, because Vorple games run in a browser without a server. You don’t need to download an “interpreter” for a Vorple game because a Vorple game is an HTML file.
If you try to open BlightedIsleWebUI.t3 in QTads, it fails.
VM Error: this interpreter version cannot run this program (program requires intrinsic function set tads-net/030001, which is not available in this interpreter)
Something similar happens in all of the other modern downloadable TADS interpreters https://www.ifwiki.org/TADS_interpreters, including Parchment, Frotz for iOS, Lectrote, ElseIFPlayer, Parchmap, Spatterlight, Gargoyle, and ScummVM.
But, if you really want to use BlightedIsleWebUI.t3, it is possible, if you go to https://github.com/realnc/frobtads/releases and download the source code for FrobTADS 2.0 (last released in May 2021).
Then, if you know how to compile software, you can follow the instructions in doc/INSTALL to compile FrobTADS from source.
(And this is how I learn that Vorple no longer needs a web server to run. Last I read about it, you needed to actually serve the pages to get around browser security restrictions on local HTML files; if that’s no longer necessary, that’s awesome.)
Right - the difficulty to make Vorple work falls on the author, which is often more optimal than making the player choose an interpreter if they’re not familiar with that.
Is that true? I thought you had to [go into terminal and] set up a local server to test, or (my solution) upload to itch as I do for multimedia Twine tests. Borogove now provides instant Vorple for creating and testing (and hosting) small Vorple projects online with no downloads necessary, but if you’ve got an enormous project, you probably still want to create it locally instead of online.
Unless there’s news about it that I’m (per usual) oblivious to!
For developing Beat Witch, I still had to have my local server running, or Vorple would refuse to work. This is due to browser security restrictions on running some JavaScript directly from your computer.
I used Vorple 3.2.8 (the most recent for pre-Inform 10), so I can’t speak to Vorple 4+ for Inform 10. Perhaps it’s different there.
However, running a local server is not as big a hassle as it used to be. I would open my game’s directory in Visual Studio Code and run the Live Server extension. For testers and players, however, I have to host a Vorple game somewhere like itch.io.
I totally will! Only thing is, it’s real messy… One that I can do is if you PM me the files (plus mention any specific things you changed in, say, the parser file), and I’ll add it to a project and send it to you! (Reason being I need to know what features I should put in a base file…)
At least in Safari, you can switch on reading local files in the debug menu. And the Brave browser allows it by default. Then you can just open the index.html file to run the game.
Just to be clear: if you take the Gilded Youth example provided above and just unzip it, you don’t need a server to play it. You just open the index.html file.
Note: you will get an error in the browser console:
DOMException: play() failed because the user didn't interact with the document first.
However, that’s due to a standard that was implemented in the browsers with audio and video context. The user has to interact with the page in some way before you start audio or video. “Autoplaying” is no longer allowed.
This error would not be visible to the user, of course, but they also wouldn’t hear sound. That’s because the Vorple JavaScript that runs and loads the sound resources doesn’t work. And that apparently handles the audio context bit.
That problem, however, will NOT happen if you run the game in a server. For example, if you have Python:
python -m http.server
Or any of the other options others have mentioned.
So there’s being able to play and then there’s getting the full experience, which is where some of the “do I need a server” comes in. This happens to be because resources are being used that need to be loaded. But if you just open the index.html and don’t care about the sounds, you will get all the graphics and the core game experience.
Note that Gilded Youth was written with the original ZCode version of Vorple. There were major changes when it switched to Glulx, and its ability to be run from a file: URL may have been affected.
(In theory there probably isn’t anything that would truly prevent it being run from a file: URL, if it adopted a single-file mode like Parchment has, but that doesn’t mean it would be at all easy to do it.)
All of this makes me wonder if it would be beneficial to have some game (like a Cloak of Darkness or whatever) that uses various “bells and whistles” – typography, window effects, modified status line, sounds, images – and then have those elements for each language. Or a version of it for each platform: Z-Machine, Glulx, HTML TADS, TADS WebUI, Dialog, etc.
Then someone can use that to see what and isn’t possible. With the Gilded Youth, for example, I saw that I can completely play it in a browser, without a server, but I did have to sacrifice sound. If I used a server, then I got the full experience.
So a TADS example could provide a binary for whatever interpreters are available and likewise for an Inform example. This way people could see how the experience “degrades” (i.e., sounds won’t play, images won’t show, colored text won’t appear) and how much that degradation matters to the overall experience.
And, of course, note we’re all still talking about the ecosystem bits rather than the programming language in terms of the “comprehensive” question of this thread’s title. Which I actually think is appropriate because, as I said upstream, I’ve found the programming language is purely a matter of preference for the most part. All of the primary languages seem to allow for the core experience of interactive fiction (at least of the parser-based variety, which we seem to be focusing on). Thus you can choose whichever one resonates with you, interests you, etc.
What often matters is what gets delivered and it seems that this is perhaps where a lot of assumptions are made about “how easy” something is or “how hard” it is or even what is or isn’t possible.
The play.html file (which is generated when you release something for Vorple) checks whether it is running locally: if (location.protocol === "file:") and displays an error message if true. But you can edit play.html to delete the check and the error and try if your game works normally. I tried it out on a project of my own and on the “Serinette” music box example included with the extensions, and images were displayed and sounds played without a problem from the local filesystem (at least during a brief test in Firefox and Chrome, on Windows, using Inform 7 v10.1.2 and Vorple version 4.0.1).
This discussion prompted me to re-visit Dialog. I have been porting an unfinished game that I have been working on for a couple of years. It is going well. I understand the Dialog syntax more and more.
Dialog has very enticing features with the use of AAmachine. So far, all is good.
