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 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
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.
- 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? https://intfiction.org/t/upgrading-gargoyle-to-use-recent-tads-sources/9141/1
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:
groups.google.com/forum/?hl=en_ … 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.