IF User Interface Requirements for Parser-Based Stories

So let’s go ahead and enumerate the requirements of an Interactive Fiction user experience for parser-based stories. This is a brain dump, so there are no wrong answers (except blinking tags).

I’ll come up with 10. Maybe someone else can add new requirements or comment on my 10? – David C.

        • IF UI/UX Requirements * * * *
  1. As a new reader of an IF story, I need to learn how the parser works.

We need to identify “new reader” or “‘new to IF’ player” as a unique persona in the user experience. This means that we need to have a specific set of variations within the user experience dedicated to new users.

  1. As a generic IF player, I would like to manage all UI elements, including turning on and turning features, changing fonts, and changing fore and background colors.

NOTE: By generic, I mean all types of players, new, a little experience, seasoned.

We may wish to play the game in the standard format (status line, main text, command line). But if other options are available, we want to know about them and be able to manage them.

  1. As a generic player, I may or may not want a list of all available commands.

  2. As a generic player, I may or may not want to see a map of the story.

  3. As a generic player, I may or may not want a built-in walkthrough available at all times.

  4. As a generic player, I may or may not want built-in help available at all times.

  5. As a generic player, I may or may not want built-in hints available at all times.

  6. As a generic player, I may or may not want commands and directions embedded in text to be hyperlinked.

  7. As a generic player, I may or may not want to view inline images.

  8. As a generic player, I may or may not want my commands spell-checked and assumptions made about my intent.

Usability isn’t only an issue for new users. Options which are not widely used by players (e.g. long descriptions) are not properly tested or discussed.

Arbitrary zoom, focus (centreing on an element). Adapt to screen/window dimensions (landscape, portrait). Sound, music volume. Overall brightness. Speed of timed features (e.g. renpy auto-forward speed). Sharing my experience (e.g. social media, social play). Quoting. Snapshotting. Recording. Pause the work and resume at a later date (on another device). Archiving.

Reading assistance. Dictionaries. Thesauruses.

(The game just stops and blinks a line.) How do you get started?

What do you do when you’re stuck? How to finish the game? Hints for the specific game. Forums. Questions and answers.

What is a command? Idiomatic commands. Short forms. What can the parser understand? When/how will I know what commands the game accepts? Why doesn’t this game accept that command? If the game asks a question should I answer? If I should answer, how should I answer?

A usable walkthrough that tells me what to type now, like a game-length interactive tutorial.

Also clues to understand the world model: supporting, containment, discrete locations, compass directions, abstract space, discrete time, (non)determinism, rewinding time…

So not a lot of feedback to this idea, but I’ll dig deeper on #1:

“1. As a new reader of an IF story, I need to learn how the parser works.”

I know there have been discussions about this, but I want to codify it. What kind of UI elements or in-line story elements help reduce the learning curve?

From Blue Lacuna, by Aaron Reed: "The central concept of the emphasized keyword system devised for Lacuna is “type words that interest you to advance the story.” While standard IF commands use both a verb and a noun, Lacuna’s system assumes the verb in three common cases when omitted, and highlights words in the story that will be fruitful for interaction. While similar to a hypertext interface, the system uses different styles of emphasis to indicate different modes of interaction, and is also built on top of a coherent, simulated model world, giving players more agency and direct control over the layer character.

Lacuna uses three types of visually distinct emphasized keywords: nouns, locations, and conversation topics. Nouns which can fruitfully be interacted with are emphasized, and typing an emphasized noun alone is the same as using the standard IF examining action on it (to get more details about that object). Nearby locations which can be explored are highlighted in a second style, and typing these moves the player character in the appropriate direction. Finally, during conversation, available beats are emphasized in a third style; typing these maps to the IF command to ask that character about that topic."

This was very effective, but I still see this as a distinct implementation for this specific story. Aaron was experimenting. I’m not sure this is how I would want parser IF to be received, even though it was highly successful at the #1 requirement.

This begs the argument: Does each game need to implement its own user-friendly user experience or is there a user experience that meets the requirement ad well as being seen as reusable?

Obviously that’s subjective and as we say on the mud, your mileage may vary. For my interests, I seek the unicorn. The user experience that meets the #1 requirement and will adopted for many future parser-based IF stories.

So let’s codify Blue Lacuna:

a. key words based on nouns, locations, and conversation topics.

Let’s assume the author has implemented an interesting prologue. Some meaty piece of text that gives the user a reason to progress the story. Now we have to transition the new user from reader to protagonist. We need to them to put on the clothes and mindset of our protagonist. I’m not talking about writing skill here (although that certainly is a factor in usability). I’m talking about mechanically transitioning the player to typing on a keyboard in a confident manner without really thinking about it too much.

For Shadow in the Cathedral, I once implemented all of the “progress” commands as a sort of automatic play mechanic. You just had to do whatever the hint system said to do and it would move the story forward. You can do this without the hint narrator too by just auto-entering the next “best” command. The upside is the user sees how things work. The downside is they may interpret how things work too specifically to those automated commands. It would almost be beneficial to author the first 10 to 20 commands so that the user sees a wide variety of patterns.

Let’s codify this:

b. limited narrated walk-through

I had a work-in-progress many years ago called “Entropy”. The protagonist was a human-formed android named Chrysilia (identifying as female outwardly). The mechanic I had begun to use and I thought quite successfully was that the prompt was her internal systems, of which there were several. Each system would “talk” to Chrysilia. So instead of a “>” and a blinking cursor, one of her systems, usually her main system, would request a command. This lent to a sort of conversation with the parser that I found very interesting and seemingly unique (I have not played all IF games, so I have no idea if this has been done elsewhere).

Codifed:

c: narrator as prompt

                • To be continued * * * * * * * * *

Something to work on. Something to think about. Feedback is welcome…or I’ll just keep writing my own thoughts.

David C.
www.plover.net/~dave/blog