After reading the long thread on how to make IF more approachable (mainly by adapting the UI so as to downplay the old-school command prompt), I’m trying to figure out how close one might be able to get to a modern UI by using HTML TADS.
In looking at the docs, I find a feature called “banners,” which I gather can be positioned around the edges of the window so as to provide non-scrolling display panes. That’s one piece of the puzzle, but other pieces are not so obviously available. I’m hoping someone who knows the system will be able to enlighten me as to what the possibilities and limitations are.
Can a banner include the input text area (command prompt)?
Can the author choose what to send or not send to the main text output window? That is, could parser error messages be routed to a separate banner window?
Just out of curiosity – not saying it’s a good idea, necessarily – can the main text output window be altered and updated without scrolling upward, teletype-style, and without blanking out existing text?
Are pop-up tooltips possible within the HTML TADS UI?
Thanks in advance for any insight on these points.
No. The prompt is always displayed in the main window and it’s not possible to move it or have another one elsewhere.
Yes, since messages are generated by the T3 library and thus can be altered. I don’t know whether there are any utility functions that would make that easier though.
No. The behavior of the main text window is fixed. It can be hidden, however (like the hint system does.)
I wish I was a real programmer. Tonight I was reading through the T3 VM spec, and while I understand a lot of it in a vague, general way, I would be at a complete loss to implement anything that used it.
What would be ideal, I think, would be a device that embodied the T3 VM but provided a more robust, modern I/O system. The VM, the parser, the library – all of that seems absolutely rock-solid to me. But the I/O layer is still tied far too solidly to 1970s-era command line interfaces.
We can debate about whether the CLI is a good or a bad thing, and different authors can have different opinions (or a single author can have different opinions while writing different games). The point is, an authoring system ought ideally to give the author those choices. It ought not to enforce one particular (and, in this case, very dated) I/O model.
Well, you can do fancy stuff with HTML TADS in its current state. It seems your main concern is the main window. You can hide it completely and implement your own input prompt in a banner window. This is not optimal, however. The input prompt is implemented by the interpreter, not by the game code, so it’s impossible to provide the exact same behavior using game code. The best solution for this would be for TADS to provide a way to place the input prompt inside banners.
For what it’s worth though, I don’t think that separating input from output is a good idea. Having a dedicated “box” where you type commands doesn’t make any sense to me. I don’t remember when, but I did come across a few text adventures that did this. It totally sucked; that system didn’t try to solve a problem. It was just providing an “input box” for no apparent reason. This is in contrast with graphical adventures that had such an input box (early Sierra games, I think); they needed this because the game was purely graphical.
One issue is, if the user tries six or eight things that don’t lead to any useful output, the room description or whatever was the most recent relevant text will scroll up off the screen. This is very bad – not for experienced IF players, but for newcomers. And it loses the immersion factor even for experienced players. In a graphic game, the vision of the current landscape doesn’t dissolve when you try stuff that doesn’t work!
It seems to me (and I haven’t tested it, because I don’t have a system that will allow it) that a hybrid I/O structure would work well. If the player types something sensible (such as ‘N’) it’s copied to the main window, and the main window text scrolls upward. The main window text will then include both the input and the output, exactly as if the command prompt were in that window. However, if the player types ‘please tell me what to do next’, the error message (which might be either “I don’t know the word ‘please’” or “For instructions, type ‘help’”) does NOT appear in the main text window – it shows up in an Error Message window, thus leaving the relevant game text visible.
In other words, there’s a differentiation between interacting with the parser and interacting with the model world. Error messages such as, “Briefly you consider setting fire to the orangutan, but on further reflection that seems needlessly cruel,” would go in the main window, even though nothing has happened, because the parser is responding to the PC without breaking the immersion. On the other hand, a default “You can’t set fire to that” might (depending on the author’s preference) go into an Error Message window.
I have to butt it at this point and mention - because I’d never realized it until you just described it - that Infocom’s “Arthur” does exactly that same thing. Lots of “that doesn’t work” messages, and parser errors, are shown in a pop-up box, while more relevant commands take place in the main window. Also, that game also a split-window where the upper half could show any number of things - including a graphical OR textual description of the current location.
Is that the sort of thing you’re trying to achieve? Because I have to say, if it is, it’s a) not new at all, b) slick, c) practical, and d) might well enhance the gaming experience, indeed. And it’s always a bit easier to end your comments with “You know, like ‘Arthur’ did”. Makes it easier to visualize.
I believe this is fully possible in I7. I know nothing of TADS, but what I’ve read so far in this thread makes me wonder… what if you have a banner occupy the top half of the screen, and let the bottom half keep the main window and prompt? Then you wouldn’t need having to fake a prompt in a banner, and changing the text of the banner should be possible, right? Then, if TADS allows banners to pop up and to be removed the next turn, the other half of what you’re trying to achieve - reserving error messages for a pop-up box - could also be solved by popping up a banner with the error message, and then removing it the next turn.
I wish it would. I’ve been meaning to ask Mike to add this, but never quite got around to it. It would open up a lot of new possibilities - not just the interface Jim suggests, with error messages hidden after they’ve been read, but things like My Angel’s “Novel Mode”. I’m not sure Novel Mode worked very well in My Angel, but it was an interesting idea and I’d love to see more authors explore its possibilities.
Real-time text-based games really need to separate the input from the output. When the game is not turns-based, new messages may appear while you are typing, and if the commands are typed at the bottom of the same window as the output messages, your input will be cut off by the incoming game message. This why MUD clients have a separate input box/window for typing commands, even though the MUD itself may print a prompt in the output window.
I haven’t been following the recent discussion about the parser. Sorry if I’m derailing this thread by posting comments that have probably already been discussed to death elsewhere, but this is the first I’ve heard of such and idea. And it is a great idea!
