Affordances: Diary and Status commands

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.

Affordances: GO TO

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.

Affordances: GO BACK

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.

Affordances: Doors and Keys

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.

Intro to my JSON datafile

This post will be about my IF datafile, now in glorious JSON format. The top level of my datafile looks like this:

{
  "languages":[ ... ],
  "urlabbrs":[ ... ],
  "lists":[ ... ],
  "tags-info":{ ... },
  "authsystems":{ ... },
  "extensions":{ ... },
  "events":{ ... },
  "people":{ ... },
  "games":{ ... }
}

And here’s a brief description of each of these top-level sections:

• The languages section is very simple and is mostly there to remind me what each 2-letter language code means, e.g. "en" means English, "fr" means French, and so on. Sometimes I forget what the code for Swedish is, y’know?
• The urlabbrs section is for my list of URL abbreviations, for example, I’ll use [A] at the beginning of an URL to mean "mirror.ifarchive.org/if-archive/". I was still worried about file size when I creating my datafile, and I thought the use of these abbreviations might reduce bloat. I’m now thinking that this is an added complexity I ought to do away with someday, if I ever want to make my datafile public in any way.
• The lists section is for describing lists of works of IF, such as Holiday-themed works (where I want to subdivide into particular holidays), or works that take place in the United States (where I want to subdivide into individual States).
• The tags-info section is more comments to myself, reminding me what tags I use in my data, in what contexts I use them, and what do they mean.
• The authsystems section is for recording info about authoring systems. But it’s a very new section and doesn’t have much info in it yet.
• The extensions section is for recording info about library extensions, particularly used by Inform 6 or Inform 7 authors. It’s also a new section.
• The events section is for recording info about events, mostly competitions. It’s… okay, but it could be better.
• The people section is for recording info about people, mostly authors of IF. This is a mostly threadbare section where I can record a link that I want to associate with someone, like their blog.
• The games section is for recording info about works of IF, and it’s easily the largest and most complex section of all of them. When I have time to update my datafile, I’m mostly adding to this section, and sometimes the events section, and not much else. I want to rename this section to works; I just haven’t done that yet since I’d have to update all my programs that read the datafile as well.

I’ll assume if you’ve read this far, you’re mostly interested in the games section, so here’s the structure of a game entry:

"game-id":{
  "titles":[ ... ], "ifwiki":"",
  "authors":[ ... ], "publishers":[ ... ],
  "contribs":[ ... ], "testers":[ ... ],
  "genres":[ ... ], "license":"",
  "color":"", "graphics":"", "sound":"", "cruelty":"",
  "versions":[ ... ],
  "sline":{ ... }, "exts":[ ... ], "lists":[ ... ],
  "seealso":[ ... ], "reviews":[ ... ], "spoilers":[ ... ],
  "notes":[ ... ],
  "year":"", "xayear":"",
  "series":"", "seriesplace":integer,
  "baf":"", "tuid":"", "ifratings":"", "ifro":"", "tags":[ ... ]
}

Fortunately, few of these fields are required; at minimum, I want the game-id, the title, and the year. Here’s what these fields are for:

• The game-id is a unique short ID that I make up for each game. The full rules are complicated, but it’s usually the first five letters of the game’s title (not counting words like “the”, “a”, “an”) put into lowercase followed by the last two digits of the game’s original publication year.
• The titles field is a list of the game’s titles, where the main title is first. What counts as the “main” title can be a bit of a judgment call.
• The ifwiki field simply tells me what the game’s article name is on IFWiki, if different than the main title.
• The authors field is a list of the game’s authors (including writers and programmers). These are not simple strings of the authors’ names, but name-records.
• The publishers field is a list of the game’s publishers (including distributors). Again, more name-records.
• The contribs field is a list of the game’s contributors (including illustrators, musicians, voice actors, etc.)
• The testers field is a list of the game’s testers, usually beta-testers.
• The genres field is a list of the game’s genres, which I try to standardize even though the genre info is coming from Baf’s Guide, IFWiki, and IFDB, each of which handles genres different ways.
• The license field is a simple string naming the game’s license.
• The color field attempts to answer the question, “Is text-colour usage in the game significant?”
• The graphics field attempts to answer the question, “Are there graphics in this game, and does a player need to be able to see them?”
• The sound field attempts to answer the question, “Is there music or sound effects in this game, and does a player need to be able to hear them?”
• The cruelty field records where the game is rated under the Cruelty Scale.
• The versions field is complicated; there’s a version-record for each version of the game. That’s where authoring system, platform, language, IFID, etc. is recorded.
• The sline field describes the status line layout.
• The exts field lists any library extensions that the game is known to use.
• The lists field lists which game lists the game belongs to and how.
• The seealso field lists links to webpages about the game, not including reviews or spoilers. I don’t know if I can justify why it isn’t called links.
• The reviews field lists links to reviews of the game.
• The spoilers field lists links to spoilers about the game (e.g.: walkthroughs, hints, maps, transcripts).
• The notes field lists other things I want to note about the game that aren’t covered in other fields. There’s a wide variety of note types.
• The year field states for the game’s original publication year.
• The xayear field states for which year this game is eligible for an XYZZY Award.
• The series field states which game series this game belongs to. I’m badly assuming a game can only belong to one series, so this needs to change.
• The seriesplace field is an integer stating where in the series this game is; for example: 2 means it’s the second game in the series.
• The baf field is the Baf’s Guide number that the game had on that site.
• The tuid field is the TUID of the game that IFDB uses. Er, for the main version of the game.
• The ifratings field is old IF Ratings number that the game had on that site.
• The ifro field is the IF Review Organization number that the game has on that site.
• The tags field is a list of tags like "cover" (meaning that the game has cover art) or "no-testers" (meaning that the game doesn’t credit any testers).

That’s probably enough to chew on for one post. Someday, I really need to make a webpage documenting the whole thing.

Oh, and why am I collecting all this info in the first place? Originally, it was to showcase my walkthroughs, but as I helping out with the XYZZY Awards and administrating IFWiki, I really did need at least some of this info collected somewhere. And I sensed that no one else was recording quite everything that I felt needed to be recorded. And I felt a more detailed approach would be more helpful down the line.

Unfortunately, I can’t claim my datafile is in any way superior; my records are quite spotty in places because I’ve been doing this mostly manually to date. Automating the process is something I  <em>really</em> want to do — if I can find the time for it.

Reviving this blog

I’m thinking I ought to revive this blog and try again to post things about interactive fiction, or at least, things related to interactive fiction and/or my participation in it. I’ve been away from WordPress for so long, though, that I’ve quite forgotten how to post. So this post is a test just to figure out the controls again.

Topics I’m thinking of covering include:

• My collected datafile about IF, the JSON format I ended up using, and some of its quirks and uses.
• My Patreon project where I create walkthroughs and maps for various IF games.
• My map-making aesthetic and the Zinnia code I use to describe the maps.
• My @IFClueBot account on Twitter, a bot that uses info from various IF games.
• My work on IFWiki, and what I achieved there (or hoped to).
• Games I’d like to write someday.
• How I play IF games.
• Affordances in IF games that I like seeing (or would like to).
• Why I prefer parser-based IF over choice-based IF.
• Odd features or trends of IF that I’ve noticed.
• Promoting other people’s IF work that caught my fancy.

I don’t write too often about anything, so trying to create blog posts is going to be a challenge for me. And I’m hoping I actually have something interesting to say. Wish me luck.

Another type of text adventure: data management

My last post was when? Never mind. Today I want to talk about data management.

Until now, I’ve been managing my private collection of interactive fiction data as a plain text file with the scintillating name “gamedata.txt”. I originally created it to help me generate HTML pages for what is now called my Key & Compass website. And, not having the newest of computers (nor all that much hard drive space, nor fancy software), a text file was really the way for me to go. The basic design was one record per game, and a list of key:value pairs delimited by or-bars. Cheap and simple.  For example, this was (until recently) what the record for one of my games looked like:

gid:kraka02|g:Krakatoa Tuna Melt|fn:David|ln:Welbourn|yr:2002|sys:z5|evg:Speed-IF|ev:SpeedIF 10^−|vers:r2|ifid:ZCODE-2-021215-1E6E|tuid:b6fz0awms527hja0|b:2071|r:2007|wc:W+m|w:sp/sp_10-9.html#davidw|x0:b2071|rline:Release 2 / Serial number 021215 / Inform v6.21 Library 6/10

Over time, my needs evolved—I started assembling the games list for the XYZZY Awards, then became the de facto admin of IFWiki—and gamedata.txt had to evolve too.

During January, I gave some thought to the name fields: fn (firstname), ln (lastname), and sfx (suffix). About the only advantage I had from them was I could sort by a single author’s surname, but it was very poor if I wanted to record multiple authors, publishers, or porters. So I thought and thought and I kinda liked how IFDB used curly braces after author names to record their TUIDs, so if I wanted to say “Nick Montfort {as:porter}” or ‘Marius M&uuml;ller {as:”Taleslinger”}’, I could.

So I abolished the (fn,ln,sfx) fields and started replacing them with (na,mult,pub,test,adap) fields for authors, multimedia contributors, publishers, testers, and adaptors respectively. (By adaptors, I mean porters and translators). Names would be delimited by semicolons, subfields would be delimited by commas, and the curly braces would enclose the subfields.

Choosing semicolons as delimiters meant that I could no longer use them in HTML-entity style sequences, so I borrowed Inform 7’s square brackets for substitutions, and so “M&uuml;ller” became “M[uuml]ller”. And I had to invent [c] to mean comma in one case where it was needed in a subfield value:

na:Jonathon Rosebaugh {as:"His Imperial Majesty[c] Shortwinker the Fifth"}

Oh, and I also invented ^ to mean a non-breaking space in names where the “surname” is two or more words. “Surname” can also mean a pseudonym in its entirety, not counting leading articles.

About a third of way through editing gamedata.txt via Notepad, I got disenchanted with the curly braces. Although they were fine for readablility, I worried about parsing the darn things when all I wanted was a delimited between name-proper and name-details. So I chose a pair of plus-signs for the honour. A bit uglier, perhaps, but I thought I could live with it.

na:Ryan Stevens++as:"Rybread Celsius";Cody Sandifer

And then I realized that I had all but re-invented the ?key=value&key=value format at the ends of URLs except I’d chosen different delimiters. So that gave me a little confidence that I wasn’t completely mad.

You may be wondering what subfields I’m recording per name. Well, lessee…

• as:  For the name they chose to write as.
• aka: For another name the person is also known as, especially for ADRIFT authors where the real names aren’t as well known.
• role: For noting how the person contributed. For example, in the authors field, I might want to specify writer or programmer. In the adaptors field, I want to know if s/he’s a porter or translator.
• wna: His/her article name at IFWiki, if needed.
• pre: A bit of notation to display before the list of names.
• sfx: A bit of notation to display after the list of names.

So, all well and good. Except then I decide to chat a little about this on ifmud, and after the usual queries about why this isn’t in a database, someone told me about JSON (see json.org).

So I thought about it, and how ugly my gamedata.txt file is with respect to competitions and versions of different games and links to other sites, etc. … and so I’m moving all my IF data into a file with the scintillating name of gamejson.txt.

And when it’s all ready, I’ll let you all have a look at it, eh? And maybe I’ll make another post too.

IFWiki raw scribbles

Recently, I’ve been scribbling down notes on overlarge index cards to remind me of things to do. In case people are curious, here’s what my IFWiki cardset currently looks like (and I wish there was a  &check; character — hm, I suppose I can use &radic;):

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!