Vorple: Interpreter feature feedback

Technical Development Interpreters
1

As you might already know, I’m building a web user interface library called Vorple that includes, among other things, new features for Parchment. It would be nice to get some feedback regarding these features before making it available to the public.

Below there are direct links to versions that demonstrate the features discussed, but you can also build your own set here with a bit more options. If you have an idea that’s not covered here and if it can be easily implemented, I can add it to the demo so you can see how it looks like live.

If you could look at the given options and tell which of them (if any) seem like the best ones, that would be great. Ideally the story author could tweak the features if needed, so for each feature try to think what would be the best default setting.

[size=150]Parser errors[/size]

To keep the transcript clean of anything that’s not actual gameplay, parser errors are “folded” away: the error message is hidden from the screen the next turn. Another option is that the error messages are not displayed in the story text at all, but shown as tooltips or notifications.

A rather interesting option would be to hide the errors only after they’ve scrolled off screen. The player would never see them folding away but they would be hidden in the scrollback. My intuition says that this would be more confusing than useful, but it’s included here as a demo anyway.

When the errors have been folded, the player’s command is left in the scrollback. Hovering the mouse over the command shows the error message as a tooltip and clicking the command returns the error message to the scrollback. Having both seems redundant, so it should be either of them (or some third option). The tooltip could also be displayed not on hover but on click. All the demos below use both methods.

Demos:

[size=150]Meta commands[/size]

Similarly to keep the transcript clean meta commands are displayed in a separate notification outside the story text. No traces of meta commands are left in the story text.

Demos (try commands VERSION or BRIEF, for example):

[size=150]Undo[/size]

Undoing hides the action that it undoes. The action’s command is left in the transcript and the word “i[/i]” is added to it. Again, the hidden action should be somehow recoverable, and it’s done either by clicking or showing a tooltip just like with error messages. All the demos above have both options.

(Remember to give a valid command before undoing. The demo isn’t yet smart enough to understand that the intro text is not something you can undo, so if you undo the first turn it will clear the intro text…)

[size=150]Dialogs[/size]

Some meta commands can be displayed as dialogs, popup screens that have to be dismissed manually. No actions or commands default to dialogs, so it’s up to the author to decide when to use a dialog to display the command and how the dialog behaves. Typically you’d use dialogs to display information like the ABOUT text, as opposed to just confirming that the player’s meta action was acknowledged like with SAVE or VERBOSE. Try CREDITS, ABOUT or TIPS in any of the demos to display a dialog.

[size=150]Other[/size]

There could be a default “how to play” link that would display PR-IF’s How to play IF card. Authors could replace the link with their own story-specific help or remove it completely. Does this sound like a good idea?

Other comments about the layout? Font, text size and line spacing? Margins and page width? Should the text be fully justified? Do you prefer Parchment’s all-white background or Vorple’s white block on gray background?

Note that there are some glitches in the demo like extra line breaks and twitchy auto-scrolling in some browsers. They’ll be ironed out in the final version.

Thank you for your comments!

2

I liked the tooltip version of the parser error surprisingly well. It helps distinguish the game voice from the parser voice. The notifications on the edges were a bit too far out of band, though; not easy to see when playing unless I anticipated the error.

I think I would prefer that the error interactions get purged from the transcript entirely, both input and response. I have a slightly negative reaction to seeing my input (however wrong-headed) struck through with a line. It’s like the game is grading my term paper.

It also sets the player up for confusion when using UNDO, since UNDO skips over the error command and takes back the previous one. (Maybe this is the way Inform has handled UNDO all along and I never realized?)

A shorter line length would be nice - for me the first line would ideally break something like this:

A ray of sunlight wakens you from your nap. You get up from the sofa, shake off
the remaining traces of sleep and take a look around.

Ragged right text wouldn’t matter to me if the line length were a bit more restrained.

The gray background does a nice job of keeping the eye focused on the middle. I like the font and the size; it’s very easy to read without coming off like the Large Print edition of a bestseller.

3

I agree that having the erroneous input switched to strikethrough is a bit rude. Having it disappear would be better.

I’m attaching a couple of .png files. In the first, the ‘restart’ command causes a black dialog box on the upper left, which has no text in it. The second appears to be a text formatting error.
vorple02..png
vorple01.png

4

Juhana, I’ve posted a list of jQuery API functions that I’d like to ban, could you have a look to see whether Vorple could be implemented without them?
https://intfiction.org/t/glk-stylesheets-the-plan/3513/30

5

Thanks, those are good points. I’m not sure about removing input completely from parser errors, because the player might want to keep track of what they’ve already tried (the errors are not necessarily typos).

Try this version where there’s no strikethrough and the error message is moved to after the prompt. To me this looks like it would not scold the player for giving invalid input and would also not lose any information.

I also changed the text panel width from 800 pixels to 600 pixels. It does look a bit easier to read.

Now that I took a closer look at the undo thing, you’re right: parser errors aren’t skipped when undoing. I was confused by the bug that makes the game say “you can’t undo what hasn’t been done” if you try to undo an invalid turn given during the first turn.

Dannii, would there be any side effects if the page would just reload when the player restarts the game? It would be the cleanest way to reset the UI.

6

I don’t think I’ve used any of those so far except maybe $.off(), so the list looks good.

7

Refreshing the page could work, but it would be good to make it clean itself up.

With the stylesheets Glk each paragraph will have a unique ID, so the undo info would store the last one, and you could delete back to that.

.off would be allowed, it was $.fx.off that wouldn’t be. I was considering banning all event handlers other than the generic on/off, what do you think of that? And no .html is probably the most significant to be banned - you’ll be able to make new elements, attach classnames, styles and handlers, and then put them places, but not random properties. I think we’ll need some direct property access however, so that is tricky.

8

Whoops, didn’t notice the .html there. Yeah, that’s a bit of a problem, but if you have a clever solution then great :slight_smile:

9

Sorry to be fussy, but I’m trying to figure out my own reaction to the parser error handling (“You can’t see any such thing”). First off, I don’t know whether other errors would be handled by Vorple in exactly the same way, and if so, what errors. And I think that may make a difference.

With respect to “You can’t see any such thing,” the difficulty is that that error can be produced in at least three ways, perhaps more, that are different with respect to the story:

  1. The player has made a typo. The object the player was trying to refer to is actually in scope.

  2. The player is trying a command, such as ‘look through window’, that the parser is misinterpreting. In this example, there is a window, and it is in scope, but ‘look through’ is not implemented as a command, so the parser is trying to find an object called “through window”.

  3. The object exists in the game, but has moved out of scope. For example, Bob has just left the room, so ‘x bob’ is now producing “You can’t see any such thing.”

In the first situation, removing the erroneous input and the response would be best. Just fade them out – they’re useless. In the second situation, either strikethrough (in conjunction with removing the parser’s reply) or moving the reply up to the command line makes sense, as the player may want to be reminded that that command doesn’t work. Personally, I think I like strikethrough better, but for subtle reasons. Perhaps both methods could be included in the extension, and the author could choose one.

In the third situation, however, the parser’s error message is a coherent in-story response to the command, and should arguably remain in the transcript without any reformatting at all. That is, it makes sense to assume that the PC, not the player, is the one who wanted to look at Bob, and couldn’t.

10

I like the 600 width better than the 800, BTW. The TV graphic now violates the right-side border, but I think that’s the author’s responsibility. The author might want to do that.

11

That sounds like a feature request for Inform 7 itself, or a separate extension. It’s unlikely that the core Vorple will separate parser errors on that level.

12

Oh, I agree, it’s not a Vorple issue. (Feature request – good idea.) All I’m saying is, whatever Vorple does with parser errors needs to produce the most sensible possible display in all of those different cases.

Undum simply folds up text that is no longer relevant, and gets rid of it. This produces a smoother flow of story text if the player scrolls back and re-reads, and I quite like that. What I believe you’re doing is leaving the most recent input and output (whatever they are) on the screen in the traditional manner until the next command is entered. At that point, we can perhaps presume (or hope) that the player has absorbed whatever is to be gained by staring at the last command and its result, and that’s also very good. So I guess I’d favor doing it Undum-style, and getting rid of the non-useful text entirely, but only after the next command is entered.

Or, since 2/3 of the code already exists in your beta, give the author a choice. At the I7 level, when the Vorple extension has been included:

Use error message hiding.

…or…

Use error message streamlining.

…or…

Use error message retention.