Multiple options for advanced UI features?

So what I want to do is include some extra UI bits for player convenience, similar to the location banner. Like, for example, a list of thing’s in the player’s inventory, or the room description. Or if I get about 500% better at programming out of nowhere, a map would be cool too, but that’s really unlikely. Anyway, from what I can tell from documentation, I have three-ish options. Some TADS interpreters will allow for some basic HTML built directly into TADS. I could make a web UI game, which would give me access to full HTML, CSS, and javascript. But if I did that, I would apparently need a server to host the game. Or I could use something called the banner API? Don’t really know what that is.

I’m using the adv3lite library if that changes anything. So, any recommendations for what I can do? Any information or documentation? (HTML TADS documentation seems slightly outdated.) I need some opinions from the TADS community on what techniques, formats, and compromises will allow the game to be easy to use and highly compatible and still allow me to use some advanced features. This is all very confusing, so please excuse me if I got something wrong.

You’re right – it’s confusing, and not well documented. My suggestion would be, write a very simple test game for the WebUI, and then experiment by adding and debugging one feature at a time. I’ve never used the WebUI, so I can’t help with details, but Eric, Nikos, and Tomas can surely help you if you post specific questions about how to get certain effects with it.

The banner API is for non-WebUI TADS. It does NOT work work with WebUI:

So I’d say that since you’re not using WebUI, you’re all set. Just use the banner API to open new banners (the status line is a banner too.) If however later on you decide to also have a WebUI version of your game, your banner code will not work.

Here’s how you can use banners:

At this point my decision pretty much comes down to which one has better documentation and is more stable: WebUI or the adv3lite version (which seems to be slightly different from the regular TADS version, based on some missing/changed classes and functions) of banners. I also need to know if one or the other is like, completely unusable for the player, like it’s really hard to get working properly in your browser/interpreter or something.

I tried looking through the WebUI code (html, css, javascript, and apparently a flash file for some reason?) and my brain just turned to fudge. Tried changing the height and width of the status banner and TADS (including the workbench somehow) crashed. If I really have to I guess I’ll spend some more time poking at it, but some WebUI documentation (more than a small section on a single page) would be really nice.

I remember something saying the banner API wasn’t very widely used and not all TADS interpreters support it.

The banner API is supported by HTML/Multimedia interpreters, and also by console/terminal text-mode interpreters. It’s not supported by text-only interpreters.

HTML Tads: Yes
QTads: Yes
t3run: Yes
FrobTADS: Yes
Gargoyle: No

Banners aren’t widely used because most games don’t have a need for them. The only exception being the status line; text-only interpreters without banner API support have a fixed status line that lacks the information displayed by interpreters that do support banners. The status line is a banner on interpreters that support banners.

You seem to do have a need for banners. Your choices are basically:

  • Use banners and require that people use one of the above interpreters, except Gargoyle.
  • Use banners but make them optional, so that the game is playable in Gargoyle too.
  • Use WebUI and implement banners in HTML and Javascript, and require people to play the game in Windows HTML Tads (the only interpreter that supports WebUI), or through the internet.
  • Don’t use banners.

Gargoyle does support the banner API. What it doesn’t support is HTML TADS, or any game compiled with a recent version of TADS 3 - 3.1 onwards to be precise.

Oops, I missed that part.

Chris Spiegel has added support for TADS 3.1.3. I don’t know when a new release is going to happen though.

So since all major interpreters support the banner API, I’d say it’s safe to use it, unless you also want a webui version of your game. In that case, you would need to write your own, web-specific banner routines.

Really? I don’t see anything in the github commits. Are you talking about this thread?

When garglk was on Google Code I had the project commits in my feedreader and I’d compile the latest version of the code for myself whenever someone made a major new commit. Haven’t bothered with that in quite a while, but I’d jump on it if Chris added support for TADS 3.1.X, regardless of when the official release might or might not come out.

It’s in the “tads3” branch, NOT the “master” branch. It was announced on the garglk-dev list: … garglk-dev

Aha, thanks! Didn’t see the tads3 branch there. That’s great news.

Can someone point me to a story that has banner API usage so I can test it? Thank you.

It still boggles my mind that current architecture themes like “separation of concerns” (separate UI development from story development) haven’t pervaded IF.

I agree that beyond legacy rich-text (bold, italics, colors of the 1970’s terminals / Zork-like tradition) it benefits from being much more independent. I think you have done a great job making the case and showing design choices. Given the highly repetitive nature of IF narrative, I also suggest there should be a split of text out of the code. So that stories can be translated by independent writers - without accessing (or even compilation) the source code. I know some language parsing can’t be the same - but the main formatted prose and images just be exchangeable resource identifiers. With fyrevm-web I really like knowing “this is a story title”, “this is a room name” at the presentation level - instead of just stream of formatted characters. I’d like to see standards for this that all interpreters can interface with - and not just Inform 7 specific extensions.

A fundamental change in IF platforms would be required to do a better job with text-separation.

Instead of actually emitting text, the platform would emit named placeholders. So instead of emitting a paraphrase like (getting the key first) when typing > UNLOCK DOOR WITH KEY, the platform would emit a value (PARAPHRASE_GETTING_OBJECT,the golden key) or something like that.

There’d have to be a separate sub-system to manage text emissions.

And then you’re correct, all of the text would be in a separately contained space for translations.

This would get more complicated for general room and event descriptions, but I think there’s some paradigm that would work.