A Penny Saved

I’ve hit a really annoying pothole in my 95%-finished game. This is my first try at using the Inform 7 programming language. If you’ve just joined the party, Inform 7 is a radical new design tool for writing text-based games, also known as interactive fiction (“IF” for short).

Not to bore you with all the gory details, but in my game the player can find three pennies. The three pennies have to be given to a shopkeeper in exchange for another object. The command I want players to be able to use is ‘give pennies to shopkeeper’. But by default, I7 does not allow multiple objects to be used with the ‘give’ action.

The resident I7 guru on the interactive fiction newsgroup, Emily Short, is going above and beyond the call of duty trying to help me get it running — but after literally hours of trying different things, I’m still tearing my hair out.

It would be easy to throw up my hands and say, “Inform 7 sucks!” (I’ve said that several times in the past three days, believe me.) But the reality is more complex, and the truth is, I7 doesn’t suck.

The first layer of the underlying problem is that I7 doesn’t model multiple indistinguishable objects (my three pennies) in a very felicitous way. But there are lots of things that are difficult to model in any IF authoring system, not just in I7 — liquids, rope, conversation, and so forth.

The second layer of the problem is that I7 models certain actions, notably giving and showing objects to other characters, in a restrictive way. Basically, this makes sense. The actions of giving and showing tend to produce blocks of text. If you can imagine the result of ‘show recently fired pistol to detective’, you may have an idea what can happen in the story as a result of a giving or showing action. So showing two or three things to a character with a single command could easily cause a jumbled, incoherent output.

That said, I can conceive of actions like ‘show garlic and crucifix to vampire’, where it might be useful to refer to two separate and distinguishable objects in a single show/give action.

The deepest layer of the underlying problem is that in writing interactive fiction we’re trying both to model real-world actions in a computer and to provide sensible text outputs for them, but the actions that can occur in a story are arbitrary and potentially infinite in variety. Inevitably, an IF development system must make some rather definite assumptions about the model world that will be provided to the author. One assumption, for instance, is that the world is divided into rooms. This is a convention of the medium.

These assumptions are often acceptable, but at any given moment in a story, any of them may prove unacceptable. How, for instance, would we model an open space such as a golf course as a series of discrete rooms?

When an assumption that’s built into the world model fails to mesh with the needs of a particular story — and that’s exactly what I’ve been grappling with — the question that arises is, how easy or difficult does the authoring system make it to alter the default behavior of the world model? The answer to this question depends almost entirely on a set of decisions and assumptions (implicit or explicit) made by the designer(s) of the system.

At one extreme, a designer might hardwire everything, leaving the author little or no ability to alter the defaults. This might happen because the designer assumes his world model is complete, or because he assumes that his users won’t notice or care about its rigidity. Naming no names, but I believe there are a couple of ultra-simplified IF authoring systems that work somewhat along these lines.

Or the designer may allow alterations to be made in the world model but assume that they’ll seldom be necessary; in this case the tools with which one would do so may be poorly documented or awkward to use. One might, to take an extreme example, imagine a system in which the only way to produce non-default actions and outputs would be to scan the player’s input one word at a time, look the input up in a fixed list of multi-word inputs, and so on — essentially, writing one’s own primitive parser and action processing code in parallel to the system’s own library. The fact that most IF systems are designed to allow this sort of thing as a last resort is disheartening but obviously necessary. One is grateful to see the tools, and one hopes never to have to use them.

At the other extreme, the designer of the story programming system may assume that the author will often need to customize the operation of the model world, and accordingly provide robust and well-documented hooks with which to do so. For an example of how this can work, you might want to take a look at Eric Eve’s code in “Mrs. Pepper’s Nasty Secret” (it was far more sophisticated than the contributions that I made to the game!) for reporting what happens when the player plays the ocarina. This was done, I believe, using existing classes and objects, which illustrates the fact that TADS 3 was developed by Mike Roberts with an eye toward allowing authors to do extensive customization.

The issue of customizability (if there is such a word) is orthogonal to the question of whether the model world found in the library is feature-rich or sparse. A feature-rich world will, up to a point, need less customization. But oddly enough, it can also work the other way: A feature-rich world may stimulate the author to imagine all sorts of fuzzy, ad hoc things that will require customized code, while a sparse world model may encourage the author to envision a sparsely implemented but clearly delineated story.

Customizability is also orthogonal to the syntax and design of the language. Rules or objects, natural language or abstract code, it makes no difference. What we’re concerned with here is the way the authoring system models the world by default, and the hooks with which the world model can be customized.

All of which is a roundabout way of saying that Inform 7 isn’t actually bad. Its world model is simpler than the TADS 3 world model, and its ability to customize the world model seems, from what I’ve been able to gather up to now, more restricted. But for many authors, that may not matter — or these may be compromises that many authors are willing to make in the interest of, for instance, a nice IDE on the Macintosh and so forth.

My base-line principle, in case it isn’t obvious, is, “Anything should be possible. The author should be completely in control of every facet of the world model and the output text.” If an authoring system places any inalterable constraints on what I can do, then it’s not a system I want to use for creative work.

At this point, it’s not at all clear to me whether Inform 7 is in that category. I’d like to believe that with enough patience and tenacity, I can get ‘give pennies to shopkeeper’ to work. But at this point, the jury is still out.

This entry was posted in Interactive Fiction and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s