Key & Compass Blog

February 22, 2016

Affordances: Diary and Status commands

Filed under: Interactive Fiction — Tags: — davidwelbourn @ 12:02 am

This is the fourth in a series of planned posts about affordances in parser-based interactive fiction. Affordances are features that enhance the playing experience in some way, perhaps by making the work of IF less tedious, less frustrating, easier to play, more attractive, more interesting, or more fun. Affordances may be said to improve the play value of a game; reviewers will often point to these positive features as reasons why they liked a particular game.

I wish to talk today about another non-standardized affordance which I will call diary or status commands. I’m talking about commands like NOTES, DIARY, STATUS, GOALS, SPELLS, DIAGNOSE, STATS, MEMORY, WEALTH, HEALTH, MANUAL, RECORDINGS, HISTORY, etc. Some games might even have more than one such command; for example, Hadean Lands has FACTS, FORMULAE, RITUALS, and ROOMS. (There’s a lot to keep track of in that game.) Sometimes instead of a specialized command, there’s an in-game object such as a notebook, diary, journal, or to-do list which automatically updates itself and which the player can examine when they need to.

To my mind, these commands and notebooks are mostly the same sort of thing: an in-game affordance where the game is doing the note-taking so the player doesn’t have to. Which, of course, is wonderful. Now, I have to say that I’ve been playing IF since the seventies and I like making walkthroughs later on so I want my own notes regardless, but I realize that a lot of other players just don’t find note-taking all that fun. So why not have the computer do all that work?

I notice that except for DIAGNOSE, all of these specialized commands are nouns instead of verbs the way most commands are. Isn’t that interesting? All these notes are things that the player consults. If they were objects in your inventory, you’d just EXAMINE them like normal objects, I think. And a player wouldn’t have to learn these new commands by typing ABOUT; they could find out as soon as they typed “I” during normal play. So, I’m gonna ask: why aren’t these diary things in your inventory? Is it just because we think of these notes as meta, a feature of the game outside the game world, something for the player to look at but not the player character?

If we can get past the idea that diary and status information is meta, we can add these virtual notebooks to the PC’s inventory, effectively letting INVENTORY be the command that lists all our current resources, not just our current physical possessions. This almost already happens, sorta:

  • When DIAGNOSE, a standard command in early cave-crawls, went into decline, we started to see health information moved into one of three places: the response to INVENTORY, the response to EXAMINE ME, or the game’s status bar.
  • Sometimes the difference between INVENTORY and EXAMINE ME gets blurred; some games even treat them as the same command whose response combines info about the PC’s appearance, self-assessment, health, and possessions together into one report.
  • In the game Darkiss Chapter 1, the inventory response has three sections, “You are carrying:”, “You are wearing:”, and “You also have:”. This last section is used for intangibles: a magic formula that the male protagonist has learned, and a curse that he may also acquire. Neither of these are lists of notes, I admit, but they’re definitely status changes, and that’s pretty close to what I’m talking about.

So that’s my big idea: turn non-standard diary and status commands into standard (though intangible) inventory objects. If it bothers you to force the player to type X GOALS instead of GOALS, feel free to add another affordance: make the verb EXAMINE (X) the default optional verb for normal objects the same way that GO is the default optional verb for directions.

As always, please feel free to add your comments below.

February 16, 2016

Affordances: GO TO

Filed under: Interactive Fiction — Tags: — davidwelbourn @ 9:21 pm

This is the third in a series of planned posts about affordances in parser-based interactive fiction. Affordances are features that enhance the playing experience in some way, perhaps by making the work of IF less tedious, less frustrating, easier to play, more attractive, more interesting, or more fun. Affordances may be said to improve the play value of a game; reviewers will often point to these positive features as reasons why they liked a particular game.

Today’s affordance is the GO TO command which can come in three main flavours:

  • GO TO location, to move the player character quickly to the named location.
  • GO TO someone, to move the player character quickly to the named character’s location.
  • GO TO something, to move the player character quickly to the named thing’s location.

There are a few syntax variations you might come across, such as FIND as a synonym for GO TO, or just typing a location’s name as a command in itself to go there. The game On The Farm used the XYZZY command to display a numbered menu of location names, which the player could then enter a number to go directly to the associated location.

I think GO TO is a wonderful command to have available in a game, especially when the game’s geography is quite large, or even in a not-so-large game geography that the player is traversing quite often. I very much enjoyed being able to zip around the marcher in Hadean Lands which had the most powerful implementation of GO TO that I’ve ever seen, whose main limitation was that only “important” locations could be targeted, so something like GO TO LAB HALL NORTHWEST wasn’t supported. I also noticed that when a character or thing is targeted, the PC would attempt to go to the target’s last known location (instead of the target’s current location) because the target might’ve moved since they last saw it. But these are quite reasonable restrictions, and I hope other authors will be inspired by Hadean Lands to try providing GO TO in their own works.

As might be obvious, all this wonderfulness doesn’t come cheap; the author has to put a lot of effort into getting this affordance to work. And Hadean Lands had the advantage that the game was essentially without time: there was almost no every-turn machinery to worry about (what’s called daemons and fuses in earlier games), so the PC could be teleported across the map once the game had determined that the player knew how to remove any barriers between the two locations. Of course, the game still needs to carry out any necessary intermediate steps like obtaining the appropriate key for a locked door in the way, for example, so yes, it’s still complicated, but at least the game doesn’t need to invisibly march the PC like a puppet through every intermediate location to get it all done.

Unfortunately, the large-geography games where GO TO would be the most useful are also likely to be the same games where lots of things are happening every turn, whether it’s NPCs wandering around, ice melting, candles burning, or birdcages floating downriver. The game Nightfall tried to implement a GO TO command, but because so many other things were going on, the game would only move the PC just one location at a time en route to the destination, and then the player would have to type CONTINUE (or C) on subsequent turns to continue the journey. And that game ran slowly. I don’t know for sure what made the game run so slow, maybe it was the pathfinding, but it serves to show that GO TO has its problems.

Still, if you’re writing a game where the player is running around the place a lot and the NPCs don’t move much and game-time isn’t that important, say something like Koustrea’s Contentment, consider adding GO TO to your game. Unless the whole idea makes you want to curl up into a little ball and hide from the world, in which case, forget I said anything.

Do you have an anecdote to share about the GO TO command? Please tell me in the comments below. Thanks.

February 13, 2016

Affordances: GO BACK

Filed under: Interactive Fiction, Uncategorized — Tags: — davidwelbourn @ 3:56 am

This is the second in a series of planned posts about affordances in parser-based interactive fiction. Affordances are features that enhance the playing experience in some way, perhaps by making the work of IF less tedious, less frustrating, easier to play, more attractive, more interesting, or more fun. Affordances may be said to improve the play value of a game; reviewers will often point to these positive features as reasons why they liked a particular game.

Have you ever used the command “GO BACK” in a work of interactive fiction? Here’s what it can mean:

  • GO BACK can mean go back to your previous location, assuming the travel route you took from there to your current location isn’t one-way. This is the usage I wish to discuss.
  • GO BACK can also mean go back towards the beginning of the story, as opposed to GO FORWARD meaning to go towards the story’s conclusion. This is the usage in Gun Mute, for example, whose geography is topologically linear and whose story is strongly goal oriented.
  • GO BACK can also mean to go back relative to the way the player character is facing, so if the player is facing north, “GO BACK” means to turn around and go south. This usage is very very rare in IF; I can’t remember any works that use the relative directions FORWARD, LEFT, RIGHT, and BACK this way.

GO BACK in the first usage is an affordance because it gives the player an extra way to help them navigate through the game’s geography. But although it was used in the very earliest text adventures, the command has all but faded away into obscurity today. So I’m curious, what happened to this lost affordance? Why was it added in the first place, and why did it disappear? I have some guesses on the last question:

  • It was too much effort for the author for too little gain for the player. Although I don’t think it’s a difficult affordance to add, really. The game just has to remember whenever the player changes locations what the last location was and whether or not the mode of travel is reversible or not.
  • Players just didn’t use it. Once you start navigating with compass directions, you don’t suddenly start thinking of relative directions. “BACK” just isn’t part of the compass.
  • It was eclipsed by UNDO, a far more powerful tool for retracing one’s steps in a game.

I’m inclined to think it was a combination of all these factors, especially UNDO, that contributed to the demise of GO BACK as an affordance. And I’m not sure if that’s a good thing or not. Are we missing something by not having GO BACK? One early game, The Sound of One Hand Clapping, used GO BACK in a puzzle. A sign quoting MGM’s The Wizard of Oz told players: “I’D GO BACK IF I WERE YOU”, and if you typed GO BACK at that location, you’d end up somewhere you couldn’t reach any other way. Which was kinda cool to figure out, but probably isn’t enough to ask other authors to add GO BACK as an affordance in their games.

Hm. What about games where UNDO is disabled? Would GO BACK be a welcome addition then? Ummm… I don’t know. Maybe? You’d have to tell players that the command was there, and even if they knew, would they use it?

I have more questions than answers about this one. Players, would you use GO BACK in a game? (Assume you can abbreviate the command to BACK or B.) Or should the command remain in the dustbin of history? Please let me know what you think in the comments below.

February 11, 2016

Affordances: Doors and Keys

Filed under: Interactive Fiction — Tags: — davidwelbourn @ 4:12 pm

This is the first in a series of planned posts about affordances in parser-based interactive fiction. Affordances are features that enhance the playing experience in some way, perhaps by making the work of IF less tedious, less frustrating, easier to play, more attractive, more interesting, or more fun. Affordances may be said to improve the play value of a game; reviewers will often point to these positive features as reasons why they liked a particular game.

For my first article on affordances, I’m going to start with the obvious topic: doors and keys. Long-time players of IF are quite familiar with the tedium of “UNLOCK DOOR WITH KEY. OPEN DOOR. E.” in older games, and now expect “E.” to do all that busywork with the key automatically. It may be helpful to list how we want the game to behave in various circumstances when attempting to go through a door:

  1. If the door is closed and locked: Try using any and all available keys in a reasonable way to automatically unlock the door.
  2. If the door is still locked: Report that there’s a locked door in the way.
  3. If the door is unlocked but closed: Automatically try opening it.
  4. If the door is still closed: Report that there’s a closed door in the way. Perhaps it’s jammed or guarded.
  5. If the door is (now) open: Go right through.

That first step glosses over a lot of fussy details. We want to try keys known to open the door first, which means the game has to remember if the player-character has successfully used a key before. We will also want to consider keys in our inventory before considering visible keys in the PC’s location. We probably want to automatically try taking a key if it’s not in our inventory, even if the key’s in a piranha tank. If we do pick up a key, we probably want to automatically put it into any keyring we already have. And once the key is in our inventory, there’s the question of availability; a key in a keyring is available for our use, but a key held by an evil gremlin in the birdcage we’re carrying probably isn’t available. So, let’s try to itemize all that:

  1. If this door doesn’t even use keys, skip all this. Don’t bother trying keys.
  2. Select a key:
    1. If there’s a key in our inventory known to open the door, select that key.
    2. If there’s a visible key elsewhere in our location known to open the door, select that key.
    3. If there’s a key in our inventory that will open the door, select that key.
    4. If there’s a visible key elsewhere in our location, select that key.
    5. Otherwise, no key is selected: Report that you don’t have a key for this door.
  3. If the selected key isn’t in your inventory, try taking the key. If the taking was successful and if you have a keyring, put the key into the keyring.
  4. If the selected key isn’t available: Report that you can’t use that key because of reasons (e.g.: evil gremlin).
  5. Otherwise: Unlock the door with selected key.

Note that (IMHO) we should only generate an automatic take-action when the key is outside our inventory. We shouldn’t have to bother taking the key out of our
keyrings, picnic baskets, and Soft-N-Fresh bathrobe pockets in order to use a key. Test for availablilty/touchability instead of testing it being directly in our hot little kleptomaniac hands.

Further things to consider:

  • Understand keycards as a separate class of keys. Only automatically try keycards in doors with the appropriate slots, and only try cut keys in doors with keyholes, eh?
  • You can automate entering an elevator car too. Don’t force a player to type “PUSH CALL BUTTON. WAIT. E.” when “E.” could accomplish the same thing.
  • Car doors, too, can be friendly. Don’t force a player to type “UNLOCK CAR DOOR WITH CAR KEY. OPEN CAR DOOR. ENTER CAR.” when “ENTER CAR” is good enough.
  • Don’t forget about automatic closing and locking of doors. When the PC is leaving their own home or exiting their own car, it’s perfectly reasonable to have the game automatically close and lock the door behind them, as long as they have the key.
  • Report what door(s) a key is for when the PC examines the key, assuming they know that info. Likewise, report what door(s) a key is for when the PC takes inventory.

If you’re writing in Inform 7, you’ll want to lookup the Locksmith extension by Emily Short. I haven’t looked at it, since I’m more of a player than an author, but I expect that it handles most, perhaps all, of the above.

So how’d I do? Are there any other affordances regarding doors and keys you’d like to see that I missed? Please comment below.

Blog at WordPress.com.