In 1993, Graham Nelson, a doctoral student in maths at Oxford, posted a couple of project announcements to USENET. On rec.games.int-fiction, Curses, a new game that could be played with any Z-code interpreter and on rec.arts.int-fiction, Inform, the language and compiler he’d created to make it.
Over the next couple of days, he was understandably disappointed by the overwhelming lack of response they received… and then he realized his USENET feed was broken.
It’s not clear that anyone had created a Z-code binary of any length subsequent to Infocom’s shutdown and now, suddenly here was this enormous, well-made game. And not just that, but also the means by which others could make their own. Jimmy Maher called it the start of an Interactive Fiction Renaissance.
And it wouldn’t be the last transformative surprise Graham had in store for the IF community.
On the foolishness of natural language programming
That original version of Inform would grow into Inform 6. In what follows, Inform means Inform 7 wherever a version isn’t specified.
In March 2005, the banner of Emily Short’s Mystery House Possessed said it had been made with Inform 7. This was the first public indication that such a project existed and no further information about it was forthcoming. People reasonably expected some incremental improvements on Inform 6, something comparable to the difference between Inform 5 and Inform 6.
A year later came three more Inform games, Short’s Damnatio Memoriae and Bronze and Graham’s Reliques of Tolti-Aph, along with one provocative hint about Inform 7: it would compile to Inform 6. That wouldn’t be warranted unless they were substantially dissimilar, so no one knew what to expect and not until its release two months later would they find out.
At this late date, it’s hard to convey just how big a surprise they were in for, how big a swing Graham was taking.
Natural language programming is an old idea. In the late 1950’s, Grace Hopper took inspiration from natural language in the development of FLOW-MATIC and its 1960 descendant, COBOL. And if you’ve ever seen COBOL code, you know its fidelity to English rivals that of a based-on-a-true-story Hollywood blockbuster to its inspiration.
Natural language is inconsistent, ambiguous, messy. And computers are literal. They’ll do what you say, but they can’t do what you mean unless you say exactly what you mean. That takes expressing it in a way that’s consistent, unambiguous, orderly. You’d need something as formally precise as symbolic logic… an artificial language.
Sure, conforming the round peg of human cognition to a square hole dictated by the computer’s needs created some obvious pain points, but everyone could agree it beat the alternative. Computer science giant Edgar Dijkstra’s 1978 summation of the conventional wisdom bears the matter-of-fact title On the foolishness of “natural language programming”.
Inform flouts this conventional wisdom.
In Natural Language, Semantic Analysis, and Interactive Fiction[1], a paper accompanying Inform’s release, Graham makes the case that:
The natural language in which to write interactive fiction is natural language
He describes Inform as a practical test of that hypothesis.
A player learns about the things that exist in a game as the game names or describes them. The game also has an idea of which words a player could use in commands to refer to given things. Both of these cases definitively require natural language.[2]
But there’s another involved party that needs a way to refer to the things in the game.
Its author.
What if all three cases of how the author refers to something, how the player refers to it, and how the game’s output refers to it could be specified at the same time by making them the same words by default?
To really show off the extraordinary expressivity on offer, I’ll throw another Inform fundamental, relations, into an example:
The bubbling beaker is on the workbench.
on indicates the (reversed) support relation and the support relation relates a supporter to various things. So this creates a workbench object whose kind is supporter and a bubbling beaker object whose kind is thing and notes their relation, that the workbench supports the beaker. It sets their printed name properties to “workbench” and “bubbling beaker”, respectively. And it adds “workbench”, “bubbling”, and “beaker” to the game’s dictionary as words that could refer to their namesake objects.
And all of that was just seven words. Now, counting brevity as a virtue is a seductive danger in programming: when it’s pursued to an extreme, brevity inevitably comes at the expense of comprehensibility.
What’s truly remarkable is that this code, in casual disregard of inevitability, is as clear and straightforward as can be and as concise as anyone could hope for at the same time.
@Draconis is fond of pointing out:
On the rulishness of Inform
Writing a program requires decisions about how to organize the concepts you’ll be dealing with. Your choices will end up determining how hard it’ll be later to modify your code to handle some new concept. And no matter how much flexibility you tried to build into it, no matter how much you tried to anticipate future desires, you’re going to end up wanting something that should be easy except it falls so completely outside your program’s model that it could only be accomplished with either a complete re-design or a pile of grotesque hacks[3].
Let’s take an interactive fiction commonplace: books that have some associated text to be output when a player issues a read command. Easy enough! Multiple fruitful approaches suggest themselves. For a procedural take on it, you’d make a subroutine for the reading action and pass the book’s data structure to it as an argument. An object-oriented approach would likely have a book class with a read method.
But what if it’s dark? What if the player character’s reading glasses are broken? What if the evil wizard’s cat is asleep on top of the book?
If you tried to somehow hang all of these special circumstances on the book object or the reading action subroutine, your program would very quickly become a maze of twisty little passages, all different, a surefire recipe for code that would quickly become hard to understand and work with. Trying to debug it would be like fighting a hydra, with three more heads sprouting for every one you cut one off.
The domain of interactive fiction is especially fertile ground for the seeds of exceptions that would grow into weeds threatening to shatter your design’s foundation[4].
So how should one approach it?
Inform’s answer is rules. A rule is a chunk of code that’s in most ways similar to what other languages call a subroutine or a function, along with (optionally) arbitrarily specific conditions for when it does or doesn’t apply. A rule can stand alone, but they’re usually organized into ordered lists of rules called rulebooks. For some rulebooks, the norm is to finish as soon as a single rule is applicable; for others, the norm is to keep going, following every rule whose criteria are met.
When a rule is added to a rulebook, there can be specific instructions about where in the order it should go. Without such instructions, the compiler automatically places rules with more specific criteria ahead of those with more general.
And that’s how Inform is organized. Other than at the very beginning and the very end, a running Inform story just follows the turn sequence rulebook over and over. The scheme sounds simplistic because its premises are simple.
Inform’s Standard Rules then combine simple elements to give rise to a rich and complex structure, a world model with built-in concepts of moving through places full of things to be examined or picked up, containers that can be opened or closed or locked, things inside other things, or atop other things, or that are parts of other things.
The result is a framework allowing one to compose new rules with tremendous power and expressivity. Consider this example suggested by @aaronius:
This fragment implies some things have already been specified, perhaps:
Ownership relates a person to various things.
The verb to own means the ownership relation.
Hatred relates various people to various people.
The verb to hate means the hatred relation.
A thing can be lethal.
A dog is a kind of animal.
and it alludes to other relations and adjectives from the Standard Rules:
The verb to hold means the holding relation.
Definition: a thing is held if the player is holding it.
The verb to be able to see means the visibility relation.
Definition: Something is visible rather than invisible if the player can see it.
Rules provide a way to express all those exceptions that IF are prone to while giving you a fighting chance to avoid making a maze of twisty little passages.
Aaron notes:
I’ve personally never really encountered a language that lets you express complex world simulation concepts like that so elegantly.
Graham attributes the primacy of rules to conversations he had with Andrew Plotkin; for @zarf’s own take on it, see Rule-Based Programming in Interactive Fiction.
On the cruelishness of barriers to entry
When Inform first appeared, creating interactive fiction had just one simple prerequisite: be a programmer. All of the options involved writing code that very much looked like… code. TADS had had an integrated development environment (IDE) for years, but it was still very much a tool aimed at programmers.
Writing With Inform begins (unchanged since 2006):
Interactive fiction is a literary form which involves programming a computer so that it presents a reader with a text which can be explored. Inform aims to make the burden of learning to program such texts as light as possible. It is a tool for writers intrigued by computing, and computer programmers intrigued by writing. Perhaps these are not so very different pursuits, in their rewards and pleasures.
Inform styles itself a design system for interactive fiction. Inform, the programming language, is just one part of that system. As he put it in NLSAIF, Graham wanted:
a radically humanizing interface for the writing of interactive fiction
Programs are stories and their creators authors. The interface takes as its guiding metaphor a literal open book, that most familiar form for interacting with text.
Approachability was always a priority. Graham’s announcement of Inform boldly proclaimed:
No knowledge of computer programming is initially required.
Let’s consider Starry Void, one of the earliest examples one encounters in Writing with Inform[5]:
The Center Ring is a room.
The magician's booth is a door. "[if the player is in Center Ring]A magician's booth stands in the corner, painted dark blue with glittering gold stars.[otherwise if the magician's booth is closed]A crack of light indicates the way back out to the center ring.[otherwise]The door stands open to the outside.[end if]".
Instead of examining the magician's booth in the Center Ring:
say "It is dark blue and glittering with gold stars. [if the booth is open]The door currently stands open[otherwise]It has been firmly shut[end if]."
Instead of examining the magician's booth in the Starry Void:
say "The booth door is [if the magician's booth is open]wide open[otherwise]shut, admitting only a thin crack of light[end if]."
The magician's booth is inside from Center Ring and outside from Starry Void.
Understand "door" or "of" or "the" or "light" or "crack" or "thin crack" as the booth.
Test me with "examine booth / open door of the booth / in / examine door / close door / look / examine crack of light".
That final Test me line hints at how much business is enabled with just these few lines.
Inform’s interface makes going from reading the documentation to seeing that example to copying its source into the story pane and compiling it to interacting with the resultant tiny game as easy can be.
But there’s more that would occur to a user after that progression. It’s also easy to change it. To add to it. And then one could immediately explore the consequences of those changes. And that would make something else obvious.
It’d also be easy to wipe the slate clean and create your own world.
@AmandaB describes:
Inform goes beyond approachable, it’s inviting. It makes you want to do the thing.
An early, persistent objection, unaltered across the two decades since Inform’s release, is that any claim of its natural language promoting ease of use is just smoke and mirrors, that it’s ultimately just another a programming language, with a compiler that’s as literal and unforgiving as any. One still has to figure out how to say things in the exactly right way that it’ll accept.
And truly the objection’s basis is indisputable. Writing with Inform includes a section titled Does Inform really understand English? It begins:
No.
As @dfabulich cannily notes:
On the ghoulishness of sticking to a bit that’s outlived its usefuless
Twenty IFComps have come and gone since Inform’s release in 2006, and games written in Inform have won fifteen of those. Of the IFDB Top 100 games that don’t predate Inform, vanishingly close to half are Inform games, in other words nearly as many as everything else put together.
Its presence has loomed so large that attempting a modern overview for this esteemed audience, many of whom no doubt already hold an opinion about Inform, was a daunting task.
But IronChIF is not for things that are easy!
@LPSmith, @Afterward, we look forward to seeing how you make Inform your own and the dishes you prepare with it.
For much, much more about Inform, see the Inform Documentation and Resources sticky post. In the context of overview, I especially recommend:
- Aaron Reed’s 50 Years of Text Games, 2008: Violet
- Allison Parrish’s Inform Concepts and Strategies
- Graham Nelson’s talks leading up to the release of Inform 10.1
NLSAIF can be found in the IF Theory Reader (PDF). ↩︎
…whichever you think stands a better chance of yielding results before you come to hate the project so much that you abandon it in disgust ↩︎
to say nothing of their risk of overextendedr metaphors ↩︎