Okay so excuse my ignorance, as I got here from the larger gamedev community and didn’t grow up with IF and yadda yadda I think I’ve opened with this disclaimer quite a few times now.
So what is the deal with HTML TADS 3 vs non-HTML TADS 3 vs WebUI vs Parchment?
I don’t know enough about the nuances and history here.
Is WebUI still a thing?
Can WebUI run HTML TADS games, or does a game specifically need to be designed for WebUI?
Does a game lose any features from HTML TADS if it’s ported to WebUI?
Does Parchment run just non-HTML TADS 2&3, as far as the list of supported TADS formats goes? Or can it also run WebUI games? Is HTML TADS the last thing on the TADS list to get support?
Are there any other in-browser platforms for running HTML TADS 3 games?
Did HTML TADS get created before or after WebUI?
I’ve been sorting through forum posts and I feel like I’m missing the full picture here.
HTML TADS was first introduced in TADS 2, and is a way of authoring TADS games with a basic form of HTML. Note that HTML TADS interpreters do not have to use an actual web browser to play them; as far as I know none of them actually do. HTML TADS games can generally also be played in non-HTML text mode interpreters, but with limited formatting of course. This includes the Glk port of TADS found in Gargoyle, Parchment, and Lectrote.
WebUI was the first way of getting TADS games online, but it required games to be compiled specially for it, and it needed a dedicated server to run the games. You could still set up a server, but it would be a lot of work, and I don’t think anyone in the community has the personal expertise. And now that Parchment can play TADS games there’s little need. Consider WebUI dead.
My long term goal is to add HTML TADS support to the Glk port. It should be possible, but it will take a lot to get there, and there are other things in the priority queue.
WebUI is (was?) more than TADS in the browser. It also permitted multi-user game play and the opportunity to incorporate full HTML / CSS / JavaScript into the game. (More here.). Games have to target WebUI upfront. It’s not something you can easily port an existing game to use. And, I don’t believe you can code a WebUI TADS game in adv3Lite (only the standard adv3).
That said, I agree with the above—WebUI is largely dead. I’m unaware of any TADS WebUI game out there.
I just really wanted to know how we got here, because I’ve had a lot of conversations now where I get the feeling that the main interpreters don’t really support full HTML TADS 3, so a lot of people don’t realize all the stuff that HTML TADS 3 does differently from Inform. Like, I’ve gotten the feeling from these conversations that many wonder what the purpose or niche for TADS even is, and assume it’s just “Inform for coders”, and don’t realize that HTML TADS 3 is actually for making entirety different kinds of parser games, and not just another approach to making a .gblorb. I’m pretty sure that Inform 6 or PunyInform is “Inform for coders”, even if we ignore the fact that plenty of coders use Inform 7 as well.
I wondered if the online scene had a lot to do with this, and I was trying to figure out why WebUI didn’t solve the issue, but…
…this explains a lot, lol.
Ah, the future! Excellent to see the roadmap now!
That would also explain some of the networking code I saw in some of the libraries, which strongly suggested multiplayer capabilities. That’s pretty cool!
True, I forgot WebUI had some multiplayer support. It had potential for lots that couldn’t be done before, but the way it worked meant it wasn’t easy to make incremental steps from normal TADS 3 games.
Quite a few TADS 3 games were recompiled for WebUI and have been uploaded to the Archive, but there isn’t a good server option right now.
Online aside, i think that as markdown language HTML is more or less a recognised standard, so I think that, generally, HTML markdown is excellent for handling styles, colour &c. in a consistent way between IF languages.
(I’m unsure about using at least … in TADS 3, because of the 'terp support consideration of Joey, albeit in some places centered text make sense in my WIP.
(a good chunk of my debugging is checking that the tags are in the right place and correctly nested & terminated. the quantity of builds where the entire output became stuck in bold and/or italic because I missed the correct tag terminator I have accrued is considerable. One out of five, at least. That I never give testers builds with text formatting bugs is a little miracle of sort, I guess.)
What is actually required? Is there any way people can help? Looking at the repo, it’s not clear.
Alternatively, is there a way to use a callback in Parchment so that when it adds a new node, we can do a poor person’s fix and replace new node text? While not being great for tables etc, it might let you change MYGAMEURL to <a href="...">Link</a>.
I’ve been trying to hack together something today to do this, but the dynamic and slightly opaque DOM does not help.
The way I’m intending will be for a Glk extension that lets you set arbitrary CSS values. I’ve made small hacks to RemGlk previously, but I’m intending to write a new Glk implementation in Rust (a Rust port of RemGlk, but more Rust-y.) Once that’s done it shouldn’t take too much to add a HTML TADS handler to the Glk port that uses the Glk extension.
The Glk extension may be able to be added to terps like Gargoyle too, at least in part. HTML TADS might not be as fully supported in Gargoyle then, but it would still be more than now.
There’s not really much anyone else can do now, unless they want to write my Rust RemGlk port for me…
I could add an optional callback function to AsyncGlk. Question is at what stage. Just before each individual text run is appended to a window? Once for each time a window gets an update?
AsyncGlk makes very few changes compared to GlkOte, the main one being that the style classes are applied to the lines as well as the individual spans.
I suspect a callback for individual text runs might be better for performance. You get your one chance to alter the transcript. My janky solution probably slows down after long sessions because it works per DOM mutation.
Well, it doesn’t seem like anyone ever really put it to use, but I don’t think that’s really because of any fatal flaw (the closest would be deployment requiring a server, but I’ve seen people deploy using gs.tads.io and it works perfectly fine), more that it’s a very different (IMO better and more powerful) paradigm from other web players, because it isn’t its own service that runs an interpreter directly in a browser and you just plop the game file in, it turns your game into a server that serves up a rich interpreter interface whenever someone connects, and maintains a conversation with the player in the browser, sending user input to the server and receiving new results back.
Can WebUI run HTML TADS games, or does a game specifically need to be designed for WebUI?
Games need to be explicitly/purposefully compiled for Web UI to run with it, but as long as you haven’t been using interpreter - specific functions directly, and have stuck to e.g. using inputManager and stuff instead, you should be able to convert an existing HTML TADS game to Web UI with minimal changes (just a few tags that change meaning bc HTML TADS uses a custom HTML-like monstrosity, whereas Web UI actually uses real HTML).
Does a game lose any features from HTML TADS if it’s ported to WebUI?
You can read the docs on this, you’ll see that in terms of capabilities and features, Web UI is a strict (and massive) superset, but a few things are slightly different in a lateral way. But, you can embed arbitrary actual HTML (not the faux partial HTML of HTML TADS)! Like, I just stuck a button with some onclick JavaScript to create an alert right in the middle of one of my scene descriptions to test, and it worked!
Does Parchment run just non-HTML TADS 2&3, as far as the list of supported TADS formats goes? Or can it also run WebUI games? Is HTML TADS the last thing on the TADS list to get support?
I don’t think it would be possible for it to run Web UI games, considering how Web UI works? Also, yeah, HTML TADS is basically the one single windows-only interpreter that comes with the TADS Workbench as far as I can tell. I really don’t know why it even exists.
IMO that is a fatal flaw. It creates an always-online requirement for players, and unless you’re implementing a multiplayer game there is no reason to require the player to be always online. (Always-online DRM is rightly derided in commercial single-player games, and I see no reason why we should be more lenient in the IF scene.) If the connection drops and the player can’t reconnect before the server terminates the session (something like five minutes, I think), their progress since the last save is gone. And if the server is not in the same geographical region as the player, they start experiencing noticeable ‘lag’ while playing due to network delays.
I’m not sure what you’re trying to get at with this remark. First, “HTML TADS” means “using HTML markup to format the output of TADS 2 and 3 games”. The QTads interpreter fully supports this. Second, “HTML TADS” is also the name of the reference interpreter Mike Roberts wrote for Windows. As to why he wrote it that way… probably because writing cross-platform GUI software was a lot harder around the turn of the millennium than it is now.
Ah, yeah, I didn’t think of that. That is problematic.
Thanks, yeah, I went back to the docs after posting this and realized I got that mixed up. I had thought that the only interpreter that supported HTML TADS the rich text/multimedia capability of TADS was HTML TADS the interpreter.
I’m getting an idea here, though… since you can compile Qt desktop applications to WebAssembly, I guess it would theoretically be possible to compile QTads like that. Then you could run any TADS game in your browser with full rich-text and multimedia support!
(Again, theoretically. I’ve never actually tried this. Also, it would definitely be a separate thing and not integrated into Parchment. Also also, the download size would probably be kinda impractical.)
(Tbh I’m half expecting someone to tell me that this has already been attempted…)
Before WebUI, Mike Roberts had actually started work on a Javascript TADS compiler. It would have been a new compiler back-end. Instead of compiling a game to a t3 file containing T3VM bytecode, it would output Javascript.
He abandoned the project and never finished it, and started working on WebUI. I don’t remember anymore why the Javascript compiler was abandoned.
He also thought about writing a Javascript interpreter instead that would run standard, unmodified TADS games, but back then mobile devices were too slow to run TADS 3 games at acceptable speeds. (TADS 3 games need a faster CPU compared to Glulx or Z-Code.) Of course nowadays this isn’t an issue anymore.
