yes, and people unware of its meaning in geek cultures as a command prompt will ask themselves why does the “game” ends abruptly in a math sign…
I’m not trying to sound too demeaning here, but if that is the conclusion that somebody would come to, then perhaps reading based activities are not really what they are best suited for?
I feel this conversation has gone from the productive to the surreal.
If I understand this correctly, Peter and Andrew both stated that changing the prompt is a trivial matter for anybody wanting to write their own game?
Therefore, the only rational conclusion is that it is at the sole discretion of the author for how they want to present their game, and for what audience they want to present it to.
Everything else is moot.
I think you’re all talking past each other. As I understand it, namekuseijin is talking about behavior specific to Parchment and Quixe, which is not something that a game author can easily change (certainly not from an I7 story file). And I wholeheartedly agree that the text input interface on an IF game web page ought to look like text input boxes do on other modern web pages, perhaps Bootstrap style, and maybe with placeholder text saying “Enter command here” or something along those lines.
The prompt is printed by the story file, not the interpreter. Then the story file calls a VM opcode requesting user input, and it’s up to the interpreter to gather that input (any way that it likes – possibly from a fancy text input UI component, or from a preexisting file of test commands) and return it to the game.
Here’s an example from Zork I, courtesy of the txd tool:
PRINT ">"
READ G6d,G6e
So, the stuff that namekuseijin is talking about (prompting and text input) involves both the story file and the interpreter.
what they mean is that it’s easy to change the text for the prompt itself - like from “>” to “what next?” - not to replace the text prompt for a GUI text input.
1 Like
and I’m sure the interpreter can drop the last line of output if it knows it’s a command prompt, just as it can scan the text to highlight directions, both of which are showcased in this screen from TextFiction:
I don’t like the baloons or color scheme, but it’s still a worthwhile idea that cleanly demonstrates the constant dialogue between game and player. Text input is always down there. Ironically enough, there’s no blinking cursor, but it doesn’t matter because this is a recognizable and widespread interface for chat and it’s certainly more well-known among laymen than a 70’s style command prompt.
But having caused quite an uproar among older IF folks, I rest my case. If it’s too cumbersome and not worthwhile, so be it.
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.
1 Like
you guys are too much obsessed with the character “>”
I don’t mean it replaced for the stupid “what next?” used in TextFiction, but just that the 70’s command prompt it represents should be replaced with a text input GUI component, as illustrated by TextFiction or any chat program: a large panel for the text of the game and output to player actions and a small panel down there for player input.
That doesn’t need any “type here” or “>” text because it’s been a universally used interface for more than 2 decades by mainstream people, while only techheads know a command prompt today.
yes, I understand some games do alter the text in meaningful and dramatic ways. So, instead of getting rid of it, just put it next to the text input. I’m not worried at all about the “>” per se, I’m worried that it’s a single thing: game text and command prompt in a single screen and if there’s no blinking cursor or a standard, instantly recognizable metaphor for “type here to go on”, a new user just stands there, clueless about why I would call text ending abruptly in “>” a game.
In a word, I think dougo was right: it really bothers me more regarding web interpreters like parchment. It is easy to try to promote IF with links, but that kind of reception I just described is even worse than the old Infocom tale of a guy typing “where am I” and leaving, because the user may not even realize typing is required to go on… quixe, on the other hand, at least got a blinking cursor.
anyway, perhaps I’m overreacting and this is no big deal at all. I guess as long as some geekheads play around with command prompts instead of large-scale IDEs, IF will always get a steady readership of IF players of fantasy text-adventures…
hmm, I wonder if this issue, if a true issue it is, would be a laudable goal for:
Measuring and improving IF accessibility as described in:
This sounds like a Parchment bug. I think it’d help just to make sure the text input is initially focused (so the cursor always blinks), and show a popup hint if the player sits at the initial prompt too long without typing anything.
1 Like
But I think the criticism is mostly right on. The “>” prompt is a tradition, but not an integral part of parser IF. The integral part is the concept of entering commands and getting responses.
An inline prompt makes sense for that on some platforms, but not all. And although there are some technical challenges regarding the way the prompt and input line are printed (“Just a tremendous pain in my butt” – Andrew Plotkin; “the most unfortunate feature of the Z-machine design” – Stefan Jokisch), I’m glad some interpreters are trying to work around them.
1 Like
The difficulty being, not all games now follow the “read and parse a line of text” model exclusively.
What about menus (navigated with single key presses)? Cutscenes (press ENTER without typing anything)? Press-any-key pauses? What happens if you start typing while the game is still processing, or in the middle of printing text?
My objection is, if that input field is always sitting there, I expect to always be able to use it. Without any prompt, I don’t know if the game is listening or not. For an old-school analogy, it’s like removing the “over” signals from a two-way radio.
Here’s a thought - what if that field isn’t always sitting there?
I mean, I still prefer to have the commands and the main text in the same panel, unlike vaporware, but if this were to be seriously approached, what if the command panel - and this is something I’ve NOT seen done in Quest, Adrift or any other engines - was simply not there until it was time for input? Or, possibly, fake input, for effect?
In this scenario, there would be a difference between keypresses (like for menu navigation or other fancy stuff) and actual command typing. When waiting for keypresses, it’s not necessary for the input panel to be visible.
It’s not something that can be done on an existing interpreter overnight and expect to work properly with existing games, I would think. Then again, I would have said the same of Text Fiction and it’s happily being used. So, I don’t know.
Come to think of it, isn’t this exactly what Sierra’s early AGI games did? As proof of concept goes, it’s not bad - the prompt would simply not be there unless it was time for you to actually do something. Then with SCI you got to a point where the command line only appeared when you started typing, and occasionally there WAS confusion over whether you were supposed to do something, sometimes.
EDIT - Well, actually, that’s what ALREADY happens. 
The prompt is there when you need to act, and not when you don’t. If we remove the command line and put it separately, it only stands to reason that maybe it should not be there at all when you’re not supposed to act. It sounds logic and straightforward and I can’t quite fathom why it hasn’t been done before…
EDIT 2 -
@vlaviano, would it be possible, do you know, for an interpreter to, say, every turn (after every command, maybe) disable the input panel by default and then enable it when that opcode gets called? So that by default the panel is off unless when input is required, using the existing mechanism?
Sure. The interpreter could enable the input panel when the story file calls @read (or the glk equivalent) and disable it after the user’s input has been collected, before moving on to the next instruction. Given the core interpreter / glk separation that’s in place in most modern interpreters, it’s the glk library that would probably be doing this (when line input is requested) instead of the interpreter proper.
“Relic.”
“70s.”
Despite many practical benefits listed by various contributors, the thesis presented here is quite simply “But it’s old! Old stuff sucks!”
Novelty is not inherently desirable. New things may sometimes be better than old things, but the quality of “newness” is never among the sound reasons why the former should be so judged.
What vacuous youths of today can or cannot readily comprehend is not any concern of mine. Instead of dumbing down what already works perfectly fine, let the kiddies turn over a brain cell for once in their lives and learn something.
1 Like
well, writing and chatting are very much older than 70’s terminal command prompts, but unlike these are used everyday by everyone.
Yes, that’s precisely the point.
I don’t think it’s bad because it’s old. I think it’s bad, on some platforms, because it violates the expectations people have of how to interact with text on those platforms.
On the Amiga GUI, the menu bar wasn’t visible all the time. It only appeared when the right mouse button was held down. If you were releasing a new version of Deluxe Paint on modern platforms in 2016, you probably wouldn’t want to copy that behavior, because that isn’t how your potential users expect menus to work.
That’s certainly a reasonable argument. However, the crux of the matter would then be the nature of “potential users.” Peter and vlaviano earlier raised some important considerations on the latter point.
(Let’s have fun instead of being like the dour people at some other forums)
Cobra Commander’s pollsters may have data indicating I may “potentially” vote for Hisss Hignesssss, but if I’ve already made up my mind to categorically support Baroness,
then their attempts to buy my vote are doomed to failure.
But it doesn’t, really, because after the prompt you have the blinking cursor or the whatever that is used on the modern interpreter. And when it’s not a blinking cursor, it’s something else that is different from the main text and makes it clear that something different will start. The “on different platforms” thing is more to do with interpreters, and they do take that into consideration, don’t they?
@vaporware, I’d like to understand your point better. What is it about the prompt that violates expectations, considering that the usual text-editing signal usually appears after the prompt anyway? Do you envision IF without a prompt and command lines in a separate panel? Are there technical or accessibility advantages to this (again, considering that after the prompt people usually have the blinking cursor anyway - and they also have it on press any key prompts, so it’s not enough to diferentiate)?
It’s also worth noting that in most interpreters usual text-editing functions (copy/paste sometimes, but especially ctrl+arrow key to jump to the beginning of a word) work well, so this is not quite like sticking to old behaviour just-because. It has seen modernization.
Let me ask the obvious question myself: then why hasn’t the inline prompt been modernised as well? AFAIK, removing it would mean retouching the paradigm a bit, making it a bit more complex, with an extra panel. Possibly no one thought of it.
Hey, we can throw down the gauntlet. Maybe any of the existing interpreter authors would like to take the challenge and fork their interpreters, just for testing and to see how it works, to have a separate input panel and show that instead of the prompt; to have it only turn on when input is required; and to have it display placeholder text that changes according to the text of the command prompt. We may possibly never really get anywhere until we see it in action, anyway.
But if someone were to do this… what would we gain by this change? Is it worth fixing - is it even broken?