Must have features in a parser UI

What are your “must have” features in an interactive fiction parser user interface? I’m trying to zero in on the user interface experience and not the parser features such as undo, oops, etc.

Here is my short list.

  • Font / color / contrast at least in the form of “themes”, minimally a dark mode, light mode, and high contrast mode.
  • No requirement to touch a mouse once playing, but optional support for highlighting text and scrolling
  • arrow up and arrow down to repeat options
  • page up and page down to move forward and back in history
  • some simple copy paste keyboard capabilities
  • Accessibility for content that is not text

Some ideas I’m toying with:

  • “Easy mode” option which autocompletes words found in a story similar to a code editor, ideally context aware of room & inventory.
  • A tiny in browser LLM that can translate human speech to parser speech. This is way beyond my current skills to create. I’d like something where if a player typed “Using my sword I fight the dragon” it would translate to “attack dragon with sword”. or “Ok, I want to eat the apple” to “eat apple”.
4 Likes

Transcripting is a big one IMO.

11 Likes

I feel like “tiny LLM” is an oxymoron.

4 Likes

I don’t know about “must haves”, but possibly mobile friendly… and all that entails. Perhaps you might be able to design a better keyboard with features you mentioned, like auto complete.

I also kind of like the idea of full screen on desktop with the background colour filling the side gutters, but the story area remaining about the ratio of a piece of paper for readability. Maybe let the user control the width of the story area, independent of the font size setting.

1 Like

I think Frotz does what you’re describing, at least on iOS.

1 Like

For me, the must-haves in a parser interface are basically the same as the must-haves in a terminal. Line editing being a big one.

4 Likes

It’s by no means a must-have but C-p and C-n should work like arrow up and arrow down IMO.

3 Likes

Support for transcription to file is important to me, whether it be to a local file or else to an online repository.

As a related, non-must wish, I’d like transcripts that matched display (text formatting and Unicode characters)

6 Likes

Resize and reflow everything when the window changes size.

Getting More paging to feel right is a bit tricky.

Lots of scrollback, but make sure the UI doesn’t bog down or crash if there’s too much scrollback. (If someone plays Counterfeit Monkey for hours and hours, say.)

These days, autosave is a must. If the player quits your app, they should be right back in the same place next time they fire it up.

8 Likes

I think a modern parser system should automatically transcript everything that is played. Maybe it could have a buffer of remembering the last 20 play sessions (maybe adjustable in options) and any of those could be permanently saved out as a text file, or they save as text files that are well named with the game name and date/time.

Support for images and sound is also nice.

One other blue-sky option - the interpreter has a tab interface so you could have multiple games in progress - or different versions of the same game playing side-by-side. It’d be cool if it would remember your place in all of them, kind of like Notepad++

8 Likes

Great comments here. Thank you!

I had never thought of Transcripting as a must have so I appreciate the feedback. I’m curious how you all use your transcriptions.

1 Like

Transcripts are important but it’s EXCEEDINGLY easy when you sit down with a game you’re excited about to forget to type TRANSCRIPT ON and create a save file. If the interpreter just did this automatically any time you played it would be super convenient. There could be an option to not save transcripts so you could switch it off if necessary.

A transcript is the most useful thing to provide to an author for beta testing. Also when writing reviews you have quotes to cut out and refer to.

It’s better to have a transcript and not need it than to play for an hour and realize you forgot it.

13 Likes

Definitely! My WIPs offer to make one but it’d be nice to just do it

6 Likes

This sounds neat, how much of a hassle is it getting it to do the right thing across save/restore?

1 Like

Feedback for authors when testing their game, mostly. Also to keep a record of how many times I tried to LICK [thing] during one particular playsession.

4 Likes

I like it when exits are listed in the header, or wherever.

3 Likes

If I’m playing a game over multiple sessions (or even when I’m not), I often refer back the transcript to refresh my memory on plot elements, where I encountered a certain thing, how the map fits together, etc. I also refer back to old transcripts sometimes if I’m trying to remember something about a game.

4 Likes

Disclaimer: I’m a blind linux user who does 99% of what he doesn’t do in a web browser at the linux console(not to be confused with using a terminal emulator, my desktop is running on tty7, I switch to tty1-6 for non-GUI stuff unless I need a terminal emulator for somreason(such as copying a URL for batch downloading a youtube channel via yt-dlp).

That said, features I would like in a modern parser interface:

up/down to review command history.
Tab completion of commands and their arguments(and I confess, I didn’t realize Frotz includes this prior to it being mentioned above, though Glulxe doesn’t appear to have it).

automatic conversion of unicode characters to ascii.

Automatic transcript that’s on by default, ideally saved as a ascii encoded .txt in the same folder as the story file with the same base filename as the story file(e.g. play Zork I.z5 and the transcript is saved as Zork I.txt) with automatic append if a previous transcript is present.

Autosave, keeping multiple save files, default name being base filename a sequential number and .save, the transcript including markers along the line of <save ###> with a blank line before and after each marker, or some other mechanism to make it easy to tell which save corresponds to where in the transcript. perhaps also markers to indicate when a save was restored and perhaps an option to produce a shortened transcript that cuts out sections undone by a restore. Generally, automate “save early, save often”, prevent “I shouldn’t have overwritten that save” regrets, and make it easy for a player to figure out which save to restore when they get into an unwinnable situation.

The parser interface being smart enough to translate natural sentences into parserish for games with dumb or obtuse parsers would be nice, though I agree tiny llm is kind of oxymoronic, though it’s true that llms vary greatly in size and pretty much all size words are kind of arbitrary, vague and relative(which is why I hate clothes with small, medium, and large sizes instead of just listing the garment’s measurements or drink sizes of small, medium, and large instead of just listing the number of ounces or milliliters, plus what’s huge in terms of a precious gemstone that’s the centerpiece of a ring is a tiny pebble in terms of rocks in general).

An parser interface that’s connected to an AI-powered TTS engine and smart enough to apply different voices to different NPCs and the narrator would be nice, especially if it had voice sets for different aesthetic genres(e.g. giving the narrator a wise old wizard voice in a medieval fantasy game, but a sci-fi AI voice in a space opera game), but I’ll settle for continuing to use espeak-ng’s default British English voice for everything.

5 Likes

Could you expand on this point a bit more, please…? I’m not sure I understand the intent of this.

3 Likes

Simply put, unicode characters don’t always play nice with the linux console and/or text-mode screen readers. The smallest of offenses is curly quotes, single and double, left or right being pronounced “thorn” when reading character-by-character and treated as a th sound when reading words. Non-latin text is often completely indecipherable in the console(and even in the GUI, the handling of non-Latin text leavs much to be desire(Orca can identify many non-Latin characters, but can’t string them into words, and all it can do with Kana and Kanji is identify them as Japanese letter and Chinese letter respectively, in the console, most non-Latin characters get the thorn treatment or just aren’t read). I even wrote a bash script to transcribe plain text files from UTF-8 to ascii, though it fails on most non-English text( turning m-dashes into normal dashes and curly quotes into straight quotes and removing accents is easy enough, transliterating foreign character sets into the roman alphabet is much trickier, and the script jusut halts in the processing of a file the first time it encounters a character without a ASCII counterpart.

5 Likes