Similarly, it should be easy to change it from “>” to “”; i.e., a blank string. The blinking cursor becomes the responsibility of the interpreter. Since a number of interpreters HAVE adapted the blinking cursor (Windows Frotz hasn’t, but WinGit, WinGlulxe and even iFrotz have) this is viable; if you were to make an I7 game, you could change the prompt to a blank string (or possibly a " ", if “” were not allowed, it’d even give you a nice offset) and be reasonably certain that in most modern interpreters it’d show as the blinking cursor.
Interpreter-wise, that’s a possibility. It does not involve removing the prompt, it involves re-structuring a web interpreter to display it that way, like the screenshot namekusejin posted. Although I prefer offline play and am not particularly drawn to that way of doing things, if there remained a cue for the player to start typing - a prompt in another form, in fact, even if it’s just placeholder “Enter text here” - it’d be fine.
But this is not down to the story file. We’re now talking on the interpreter side. And it is cool to see varied forms in interpreters, I particularly like the book-style interface seen in Jack Toresal (Deluxe version) which Eric Eve also used for Nightfall, even if just as a test (I remember seeing screenies). The problem with this, of course, is that an interpreter made this way will be far less flexible in terms of media, and an author will have to think about how best to use this interpreter. Although that’s already true of the interpreters we do have, they all share a standard.
Let me be clear on one point. Getting rid of the prompt as a concept is, I think, a bad idea. Getting rid of the “>” sign specifically seems moot, because it’s such a good sign for its purpose. Keeping the prompt in another form, however, would be an interesting idea to experiment with.
Namekusejin, if this is what you were talking about all along, I do apologise and we have been talking at cross-purposes.
EDIT - TextFiction deviates from the standard and I can imagine a couple of problems that might arise. How does it deal with Shrapnel, Border Zone or any other game that uses realtime effects, like the intro in English Suburban Garden? What about the colour use of Photopia? What if the words “north” and “west” appear in the text but only to say there is, say, an impassable wall that way? Or if it says that there’s a door on the north side and a hallway on the opposite side, thus failing to capture all the exits? An interpreter author usually has to take all of these things into account. If TextFiction doesn’t, then it’s a cute toy, but broken as far as its main function goes. IMO (I’m a player, not a programmer).
EDIT 2 - I think Quest does the same thing. I stopped playing Quest games because the release page is an unutterable mess, and impossible to keep up with realistically, so I just gave up on Quest entirely (plus, most of the games were simply bad, and too many of them were gamebooks anyway). But I seem to remember it has no prompt, and instead a placeholder text input box. It didn’t phase me, it didn’t bother me. The prompt still existed as a concept, and it was there when I had to type and gone when I didn’t.
Mind you - in all these examples where there’s a placeholder prompt, we’re talking about a different design paradigm. In “ordinary” parser-IF, the main text and commands are in the same window, and it’s like a transcript. In all the placeholder prompt examples we’ve been talking about, the command line is on a different panel. FWIW. This may not be a big difference, but it is a difference. Personally I’ve always mildly disliked the command line being its separate entity (ADRIFT does this as well). But that’s just a personal preference.
EDIT 3 - Here’s another thought. Interpreters which do it like this, with the command line separate, lose that trick sometimes when a game presents a fake prompt and, when you start typing your command, it instead starts styping its own pre-set command (effectively a cutscene masquerading as a prompt). I can’t see how TextFiction would with with that.
Also, what if the game’s prompt is actually customised? I’ve seen a couple of games (it was a while ago, I don’t remember which!) where the prompt actually displayed some stats information. And there is a practice, sometimes, of using >> (double prompt) to indicate you’re in “talk” mode. An interpreter which wishes to do away with the prompt would have to take this into consideration - possibly use “Enter command here” as placeholder if the prompt were set to be “>”, and if it were set to be anything else then use that custom text instead.
So it’s not a trivial undertaking. It requires a lot of thought, otherwise it won’t be fully compatible with existing games and therefore fail as an interpreter.
EDIT 4 - The best thing about “>”, really, is that it’s always suitable. It works for horror and comedy and puzzly games. It doesn’t detract from immersion. “Enter your command here” always screams at me “You’re playing a game”, and that shatters the illusion that’s at the heart of parser IF, to me. You’re reading natural English and communicating in natural english; the fact that you’re typing disappears, as you continually try to express your intentions to see them carried out. It’s a dialog, as you say. The placeholder text is more akin to a walkie-talkie conversation - you’re in a dialog, but you have to wait until the other person says “Over” before you can get a word in. This is actually an accurate description, but it’s unsuitable for anything OTHER than walkie-talkie or radio communication (of course, the “>” prompt is no different, but it’s a lot more discreet. Less glaring). Similarly, the placeholder text would really detract, I feel, from Slouching Towards Bedlam, Anchorhead, or Babel. Not to mention Fail-Safe, which would totally destroy the author’s carefully crafted mimesis! “>” always works, in every situation, and that’s part of its strength over the placeholder text.
EDIT 5 - Some games have a “?” instead of “>”. Arguably that’d be the next best thing. “:” is also something I’ve seen.
EDIT 6 - Note to self: there shall not be an edit 7. See to it.