Inform 7 Concepts and Strategies
Inform is a programming language for creating interactive fiction (in the classic Infocom-esque parser-based format). It was created by Graham Nelson, and has a number of characteristics that make it different from other programming languages, and uniquely suited to the task of writing interactive fiction. Inform 7 is the most recent iteration of the language, and differs dramatically from previous versions, which is why you’ll see so many tutorials and documents specifically referencing “Inform 7.” However, previous versions of the language are now infrequently used. In this document, I’ll use “Inform” to refer to Inform 7 specifically.
Inform: What and why
Inform is freely available for download, with IDEs for multiple programming languages. At points, this tutorial assumes that you’re working with the macOS IDE, but the general principles apply regardless of the version you’re using.
The goal of this tutorial is to show you some of the basic concepts that underlie how Inform works, along with some simple examples, so that you can quickly jump into the task of making your own interactive fiction works. But this tutorial is not comprehensive! It’s just a whirlwind tour of features that I think are important and interesting. See the Inform website’s documentation page for more resources, including the manuals, which give in-depth descriptions of the language along with helpful copy-and-paste-able snippets. (This documentation is also available inside the desktop application, in the “Documentation” tab.)
The most notable thing about Inform is its resemblance to “natural language.” One of the design goals of the project was to make a language that is easy for people without a programming background to read and write, and one tack taken to achieve this goal was to make the language “read” more like natural language, and, when writing code, allow for phrasings that (when everything is working the way it should) closely resemble idiomatic assertions and descriptions of what the programmer wants.
It would be reasonable, after looking at some Inform code, to reach the conclusion that “programming” in Inform consists of simply opening up the IDE and typing out what you want to happen. But don’t be fooled! Although it looks very different from other programming languages, Inform still has strict syntax and strong expectations about how your code is written and arranged.
See the manual chapter on punctuation for dramatic examples of how Inform bends over backwards to retain the quality and conventions of printed text in its source code. You end up with programs that are beautiful and clear to read. But writing the programs, or figuring out exactly what a program does without digging through the manual, can sometimes be a challenge.
The basic loop
A typical Inform program has more or less the following logic as its core “loop”:
- The user types in a command, usually consisting of a short imperative sentence (“open the wardrobe”).
- Inform’s parser translates what the user typed into an action, and
attempts to match that action against actions defined in the source code.
(There is a many-to-one relationship between what the user types and the
actions thereby matched. For example, as we’ll see below,
boogiemight all be commands that map to the dance action.)
- Rules associated with each action can make changes to the state of the game. For example, an open action might update the state of a cupboard from being “closed” to “open”; an eat action might increment a variable associated with the player’s hunger level. The objects and values that form the game’s state are defined in the source code along with the actions and the rules.
- In addition to updating the game state, the rules cause a representation of the game’s state to be displayed to the user. (I.e., after typing in a command, the game will show you the results of that command.) Inform itself takes care of this for you for the most part, but as the programmer you can write code that takes over the process at various points and in various ways.
- Repeat from 1.
In most (imperative) programming languages, the main work of the programmer is to write a list of instructions that the computer carries out from beginning to end. In an Inform program, however, most of the programmer’s work goes into defining things: what the objects are like, what actions operate on them, and what should happen when those actions are triggered, either directly by user input, or indirectly from rules activating other rules. It’s a very different style of programming.
Interactive fiction and narrative structure
Why learn how to make interactive fiction games as part of a course about computational approaches to narrative? The first reason is simply that many works of interactive fiction are themselves well-known and useful examples of computational narrative, and learning how to make games in that style will help you understand how those games work and how they successfully produce the effects that they produce. (Examples of well-known interactive fiction works that are often included in discussions about the history of new media art and literature include Zork, Trinity, Mindwheel, and Galatea).
Another reason is the particular parts of narrative that the medium of interactive fiction draws its authors toward. Hypertext works concern themselves primarily with how snippets of narrative discourse related to one another, and usually don’t have a formal model of setting, objects or character, aside from what emerges in the text of the narration. Interactive fiction, on the other hand, starts with formal definitions of setting, objects and character, and the narration emerges from the rules associated with those models.
As a (traditionally) entirely text-based medium, interactive fiction serves both as a testbed for generating textual narrative discourse from abstract representations of events, and as a potential prototyping environment for simulation-oriented computational storytelling in other media.
Actions, verbs, properties, kinds and relations
The purpose of this section is to show you how to make it so you can make a program that accepts a command from the user, changes the state of the game in response, and displays a response to the user.
Let’s get started. The following is a very minimal Inform program. The first
line is a header that gives the title of the work along with the name of its
author. Anything between square brackets (
]) is a comment (unless the
square brackets are inside of double quotes; see below). The last line creates
two objects, one called “Studio” and another called “piano.” Note that
definitions of this kind end with periods (
.). For now, don’t
worry about what a room is, or what it means for the piano to be in the
room. We’ll talk about those later.
Note on how this tutorial works: You’ll find Inform code samples above a box with a button labelled “Play.” The “play” button will activate an in-browser Inform interpreter allowing you to interact with the program whose source code is listed. If you want to make modifications to the code, copy and paste it into the Inform IDE and hit the “Go!” button in the IDE.
"The Studio" by Allison Parrish [This is a comment.] The Studio is a room. A piano is in the studio.
When you start an Inform program, Inform automatically creates a player object
and puts it into the room mentioned. Right now this game doesn’t do much. If
you try to type a command, like
play the piano, you’ll get
something like this:
>sing That's not a verb I recognise. >play the piano That's not a verb I recognise.
The game is telling you that it doesn’t have any actions associated with the
commands you’ve typed. You’ll have to define those actions yourself. (If you’ve
played interactive fiction before, you might know about some commands that
every Inform game already supports, like
take. We’ll talk
about those later, but for now we’re going to focus on writing code to
implement our own verbs and actions.)
Your first verbs
To make the game do something in response to the user typing a command like,
dance, you need to do the following things:
- Define the action
- Define the text that causes the action to happen
- Define a rule that specifies what should happen when the action is triggered
For now, we’ll focus on verbs that don’t take a direct object.
In Inform, an action (with no direct object) is defined with the following syntax:
Verbing is an action applying to nothing.
The text is an action applying to nothing is the actual Inform syntax. (It
probably doesn’t look much like a other programming languages you know about!
But yep, that’s the actual syntax.) You need to replace
Verbing with the -ing
form of the verb of your choice (e.g., dancing, coughing, sighing, etc.).
An action definition on its own doesn’t do anything. If you want the player’s input to trigger this action, you need to include a line that looks like this:
Understand "verb" as verbing.
(Keeping the quotes intact.) Replace
verb with the command you want the user
to be able to type, and
verbing with the same verb that you used to define
the action above. This creates a “verb” command that triggers the corresponding
The following example creates an action dancing and associates it with the
dance. Try typing
dance at the prompt.
"Dancing in the studio" by Allison Parrish The Studio is a room. A piano is in the studio. Dancing is an action applying to nothing. Understand "dance" as dancing. Report dancing: say "You dance a spritely jig."
The last two lines of this program create a rule that specifies what should happen after the dancing action is activated. In this case, the only thing that happens is say, which is an Inform phrase that simply displays the text between the quotation marks to the screen. In Inform, the term “phrase” corresponds to what we would call statements and control structures in other programming languages, including if (which we’ll use extensively below) and repeat (for programming loops).
The understand construction can take multiple “synonyms” or alternative commands that will all trigger the same action:
"More dancing in the studio" by Allison Parrish The Studio is a room. A piano is in the studio. Dancing is an action applying to nothing. Understand "dance" or "boogie" or "jitterbug" as dancing. Report dancing: say "You dance a spritely jig."
Now all of the following will report a jig being danced:
>dance You dance a spritely jig. >boogie You dance a spritely jig. >jitterbug You dance a spritely jig.
It’s important to distinguish between the work that is an action applying to does, and the work that Understand … as … does. The former defines the action; the latter defines what the user has to type to create the action. (In some works of IF, there are actions that are never triggered directly by the user, but only by other actions. Those actions don’t need an Understand … as … construction.)
The Understand… construction can be used to define synonyms for names of things as well. See Section 17.8 in Writing with Inform for more details.
Verbs with direct objects
To make a command that allows the user to take action on something in the world, there’s another version of the is an action applying to syntax. It looks like this:
Verbing is an action applying to one touchable thing.
Verbing with the verb of your choice. The one touchable
thing notation is a little bit weird; you can ignore it for now, except to say
that Inform keeps track of which objects can be “touched” by the player (i.e.,
are in the same place, aren’t inside a closed container). Specifying
touchable here here guarantees that the action won’t apply to (e.g.)
something in a distant place. More on touchable and its
In this case, the Understand … as … construction needs a pair of square brackets between the double quotes defining the command, to tell Inform where it should look for the name of the direct object of the verb. Something like:
Understand "verb [something]" as verbing.
verb is what you want the user to type and
what you called the action in the is an action applying to construction.
The following example creates a verb
play, which takes a direct object:
"Piano lessons" by Allison Parrish The Studio is a room. A piano is in the studio. Playing is an action applying to one touchable thing. Understand "play [something]" as playing. Report playing: say "You play a tune on [the noun]. It sounds lovely."
Note that Inform takes care of the particulars for you, and shows an error if the user attempts to play something that isn’t there:
>play piano You play a tune on the piano. It sounds lovely. >play marimba You can't see any such thing.
The Report rule works as in the previous example, but with a twist: inside
the double quotes of say, you can type
[the noun], which Inform will
replace with the direct object of the noun that was played. Handy! (This is an
example of Inform’s extensive text substitution
The actions we implemented above aren’t very interesting, because they don’t actually change anything in the game state. That’s partially because we haven’t defined anything in the game state yet that can be changed.
So let’s do just that. Inform allows you to define properties on objects. For simplicity, we’ll focus on Boolean properties in this tutorial, but properties can have other types of value as well. A Boolean property has two different values, only one of which can be assigned to the property at any one time. (Like “heads” and “tails,” or “true” and “false,” except you can give other names to them.)
To define a Boolean property, use the following construction:
X can be either Y or Z. X is Y.
The … can be either … or … and is is the Inform syntax for defining a
X with the object whose property you’re defining, and
Z with the name of the properties. The is construction specifies the
value of the property for the object in question when the game begins.
This can look a little bit tricky. Let’s break down the example from the code below.
The piano can be either tuned or out of tune. The piano is out of tune.
Pick out … can be either … or … from the code above. The things in each of the “slots” of the command are: The piano (the object whose properties we’re defining), tuned (first possible property) and out of tune (second possible property). This will look really strange to programmers familiar with other languages: the names of the properties have multiple words but aren’t separated from the rest of the code with quotes, or joined by underscores, or whatever! And yes, it’s true: in Inform, any identifier can have spaces in it, whether properties or actions or names of objects.
Here’s an example, showing a piano that is out of tune:
"Just awful" by Allison Parrish The Studio is a room. A piano is in the studio. The piano can be either tuned or out of tune. The piano is out of tune. Playing is an action applying to one touchable thing. Understand "play [something]" as playing. Report playing: say "You play a tune on [the noun]. It sounds [if tuned]lovely[else]awful[end if]."
This example has another new bit of syntax:
[if property]text A[else]text B[end if]
This construction (only usable inside of double quotes) is replaced with
property is the current value of the given property for the direct
object of the verb, and
text B otherwise. It’s handy for modifying what the
output shows based on the current state of the object.
Changing a property
We’ve assigned a property to the piano at this point, and specified what should happen if the piano has one or the other value for that property. But right now, there’s no possibility for that property to change. To change the property, we need to add a few more tools to our toolkit. In the following example, we define a new action and command, tune (“tune [something]”). The idea of this verb is that user can type it to change the boolean property we defined on the piano from out of tune to tuned.
For play and dance above, we only used a rule called Report …:, which Inform triggers after the action has taken place. For this rule, we need to use two new rules: Check …:, which is triggered before the action takes place, and Carry out… which should contain the actual instructions of how to update the game state based on the action of the verb.
Here’s how it works. Try playing the game and typing
tune piano. (Then try
typing it again.) The example also includes the
play command; try
the piano before and after you tune it:
"Tuning the piano" by Allison Parrish The Studio is a room. A piano is in the studio. A piano can be either tuned or out of tune. The piano is out of tune. Tuning is an action applying to one touchable thing. Understand "tune [something]" as tuning. Check tuning: if the noun is tuned: say "It's already perfectly in tune."; stop the action. Carry out tuning: now the noun is tuned. Report tuning: say "You meticulously tune [the noun]." Playing is an action applying to one touchable thing. Understand "play [something]" as playing. Report playing: say "You play a tune on [the noun]. It sounds [if tuned]lovely[else]awful[end if]."
There are two other new bits of syntax to discuss here.
The first bit of syntax is “now the noun is tuned.” The now phrase
updates the state of the object, setting the Boolean property to the given
value (“tuned”). See Chapter 8 in
Writing with Inform for more examples of what you can do with
The second new bit of syntax is that “if” in the “Check tuning” rule:
if the noun is tuned: say "It's already perfectly in tune."; stop the action.
This is an example of an Inform if phrase. Schematically, an if phrase looks like this:
if condition: phrase; phrase.
What follows the word “if” is a condition, or a “sentence, formed by putting nouns on either side of a verb.” For our purposes, the sentence whose truth we’re checking is the same one we used to set the piano’s boolean attribute to “tuned” (i.e., “now the noun is tuned”).
Following the if … : preamble, you can write as many Inform phrases as
you want, separated by semicolons on separate lines, with the final phrase
followed by a period. Usually these will be say (to output text) or now (to
change game state). The phrase
stop the action tells Inform that the action
should not continue; in this case, it means that the instructions in the
out rule will not, in fact, be carried out.
There’s a shorter way of writing this, which looks like this:
if the noun is tuned, say "It's already perfectly in tune." instead.
This form has almost the same syntax, except that a comma follows the
condition, and the resulting phrase follows directly after (instead of being on
the same line). The word instead in this format has the same effect as “stop
the action” in the example above: the action is stopped and the Carry out
rule is not carried out. (A disadvantage of this form is that it can’t easily
be used with
otherwise; see below.)
New kinds of things
So far so good. What should we add next? One possibility would be to add other kinds of instruments to our studio, other than the piano that’s already there. At this point, however, if you wanted to add another instrument, you’d also have to add the can be either tuned or out of tune property to each additional instrument, which would be inconvenient.
To address this potential inconvenience, Inform provides the ability to define kinds of thing. For now, you can think of a kind as a class of objects that share the same property definitions. Once you do this, you can create new objects of that kind that will automatically have all of the properties from that kind associated with them.
The syntax for making a new kind looks like this:
X is a kind of thing.
You can pick
X, and like any other identifier, it can consist of multiple
words. (You can actually swap out thing for any other kind, and thing
itself is actually a kind that Inform itself defines. But let’s leave that
aside for now.)
Once you’ve defined the kind, you can associate properties with it, using a syntax similar to the syntax you used for associating properties with an individual object:
X is a kind of thing. X can be either Y or Z. Xs are usually Y.
The main difference here is the use of the word usually: this sets a default value for the property. Any object of this kind will have this boolean property set to this value when it’s created. (But you can write an action to change it later.)
Finally, creating an object of a particular kind looks like this:
A is a X.
A is the name of the object, and
X is the kind of thing you want it
The example below creates a new kind, musical instrument, which has the ability to be tuned or out of tune (a Boolean property). The tuning action changes the property from out of tune to tuned for any musical instrument. Otherwise, the code in the example is exactly the same as the previous example.
"Tuning anything" by Allison Parrish The Studio is a room. A musical instrument is a kind of thing. A musical instrument can be either tuned or out of tune. Musical instruments are usually out of tune. The piano is a musical instrument. The piano is in the studio. The french horn is a musical instrument. The french horn is in the studio. Tuning is an action applying to one touchable thing. Understand "tune [something]" as tuning. Check tuning: if the noun is tuned, say "It's already perfectly in tune." instead. Carry out tuning: now the noun is tuned. Report tuning: say "You meticulously tune [the noun]." Playing is an action applying to one touchable thing. Understand "play [something]" as playing. Report playing: say "You play a tune on [the noun]. It sounds [if tuned]lovely[else]awful[end if]."
Checking for kinds and “otherwise”
We may find ourselves in a situation in which some objects in our world are not musical instruments. In this case, it might be useful to restrict our playing and tuning actions such that these non-instrument objects can be neither played nor tuned. An easy way to do this is in the Check tuning: rule, making use of the word not in the condition:
if the noun is not a musical instrument: say "You can't tune that!"; stop the action.
“Not” here negates the condition (i.e. “the noun is not a musical instrument” evaluates to the opposite of “the noun is a musical instrument”). The phrases below this print out an explanation to the player and stop the action from continuing. Of course, we still want the instrument to be untunable if it has already been tuned, so we need to include both of these if phrases in the rule. The “otherwise” clause (which can also be written as “else”) lets us combine the two conditions:
if the noun is not a musical instrument: say "You can't tune that!"; stop the action; otherwise if the noun is tuned: say "[The noun] is already perfectly in tune."; stop the action.
(Note that only the final phrase in the rule ends with a period!)
Here’s the entire example again, written so that only musical instruments are
playable and tunable. I’ve also added a coat rack, which is not a musical
instrument, so you can test these new limitations out. (Try typing
"Tune only instruments" by Allison Parrish The Studio is a room. A musical instrument is a kind of thing. A musical instrument can be either tuned or out of tune. Musical instruments are usually out of tune. The piano is a musical instrument. The piano is in the studio. The french horn is a musical instrument. The french horn is in the studio. A coat rack is in the studio. Tuning is an action applying to one touchable thing. Understand "tune [something]" as tuning. Check tuning: if the noun is not a musical instrument: say "You can't tune that!"; stop the action; otherwise if the noun is tuned: say "[The noun] is already perfectly in tune."; stop the action. Carry out tuning: now the noun is tuned. Report tuning: say "You meticulously tune [the noun]." Playing is an action applying to one touchable thing. Understand "play [something]" as playing. Check playing: if the noun is not a musical instrument, say "You extract strange sounds from [the noun]." instead. Report playing: say "You play a tune on [the noun]. It sounds [if tuned]lovely[else]awful[end if]."
Relations are an important part of Inform, but most other programming languages don’t have a construction that is similar. A relation is a way of keeping track of how two (or more) objects are related to one another.
An example of an everyday situation that could be modeled with relations is people wearing clothes. Wearing is something that requires two different things: a person and a piece of clothing. When a person puts on a piece of clothing, that person is then said to be wearing it, and the piece of clothing is said to be being worn by the person. A person can wear multiple pieces of clothing, but (usually) a piece of clothing can only be worn by one person at a time.
You could keep track of these relationships using a two-dimensional table, where people are rows and piece of clothing columns:
|scarf||trousers||skirt||top hat||sweater||oxford shirt|
This table shows a hypothetical relation between people and clothes. Where there’s a 1 in a cell, it means that the person in the corresponding row is wearing the piece of clothing in the corresponding column. Relations in Inform are a way of defining these tables, keeping track of the data in them, and changing that data. (In fact, Inform’s built-in verbs “put on” and “take off” make use of a relation very similar to the one I just described.)
A relation holds between two objects; you define a relationship as being between two kinds. Defining a relation looks like this:
X relates one Y to one Z. The verb to V means the X relation.
… where X is an identifier that names the relation, Y is a kind of thing, Z is a kind of thing, and V is a verb that will be used to write code about the relation later in the program. Typing one … one creates a one-to-one relationship and one … various a one-to-many relationship.
Inside of a rule (like Carry out …), you can use the following phrase:
now A Vs B
… to associate object
A with object
B using the relation you associated
V with (using the present-tense third person singular form of the
The following example shows a relation called skill, which relates people
(like the player) to musical instruments. A new command,
learn, causes the
player and the specified musical instrument to be related by this relation.
This is a minimal example; relations can be much more sophisticated (and useful!) than this. See sections 13.3+ in the Inform manual for more explanations about relations.
"Learn to play" by Allison Parrish The Studio is a room. A musical instrument is a kind of thing. A piano is a musical instrument in the studio. A french horn is a musical instrument in the studio. Skill relates one person to various musical instruments. The verb to be skilled in means the skill relation. Learning is an action applying to one touchable thing. Understand "learn [something]" as learning. Check learning: if the actor is skilled in the noun, say "There is such a thing as too much practice." instead. Carry out learning: now the actor is skilled in the noun. Report learning: say "It takes mere hours to master [the noun]." Playing is an action applying to one touchable thing. Understand "play [something]" as playing. Report playing: say "You play a tune on [the noun]. It sounds [if player is skilled in the noun]lovely[else]awful[end if]."
relations; it’s a built-in command that gives you a list of all
relations that hold between objects in your game (except for built-in
relations, which we’ll talk more about below).
In the previous section, I showed you how to define your own commands and have them operate (via actions and rules) on objects whose properties and relations you defined yourself. But part of what makes Inform an ideal language for writing interactive fiction is the rich library of commands, objects, kinds, and relations and so forth that are already defined in the language. Together, this is called the Inform “world model” or “standard rules.” This includes properties, relations and actions for giving textual descriptions to objects, putting objects in rooms, putting rooms in spatial relations with each other, picking up objects, dropping objects, etc.
In point of fact, everything we’ve made so far has been using some of these
“freebies” from the Inform standard rules. For example, try typing
piano in any of the examples above; you’ll find that the game already knows
how to let the player
take things! (And, somewhat absurdly, that the game
will allow the player to pick up a piano and carry it with them. More on how to
prevent this below.)
So show me
showme command is a way to see the properties and relations defined for
objects in your story, including those that come for free with the Inform
standard rules. On its own,
showme displays rooms and their contents; used
with the name of an object, it shows that object’s type, properties, and
relations. For example,
showme piano, if typed in the example story above,
displays the following:
>showme piano piano - musical instrument location: in the Studio singular-named, improper-named; unlit, inedible, portable list grouping key: none printed name: "piano" printed plural name: "musical instruments" indefinite article: none description: none initial appearance: none
musical instrument part is something we created, but the rest of these
are properties and relations added to objects automatically on creation, in
order to make them play more nicely with the rest of the standard rules.
(It’s important to remember, though, that a property like portable, however
evocative its name, is quite similar to the tuned/out of tune property we
programmed above. It’s just something that Graham Nelson defined in the
standard rules that goes along with rules and actions that modify the game
state in response to user input. Likewise, the
location relation, even though
it’s so central to how a work of interactive fiction functions, is defined in a
way very similar to the way we defined the “skill” relation above!)
Another indispensible way to see all of the goodies that the standard rules give you (along with an overview of what you yourself have defined) is the Index. You can reach this in the Inform IDE with the tab labelled “Index” on the side of either of the editing panels. Here are some highlights from the Index:
- The “Actions” tab shows all of the actions that are defined; selecting “Commands” in the header shows what the user can type to trigger those actions.
- The “Kinds” tab shows the kinds of things that have been defined in a hierarchical view. Scrolling down a bit shows the description of those kinds along with their properties and default (“usually”) values.
- In the “Phrases” tab, selecting “Relations” shows all of the defined relations (along with the kinds that they relate to), and the “Verbs” tab shows the verbs that enact those relations. (Note how these are distinct from commands and actions!)
- The “World” tab shows you a map of the rooms you’ve added to the game.
In any of the Index tabs, items that you’ve defined (as opposed to items that are defined as part of the standard rules) have an orange arrow next to them.
The remainder of this section will explore and explain some of the most common kinds, actions, verbs, relations and properties from the standard rules that you’re likely to use when making things with Inform. The Inform Recipe Book is a great place to learn more about what the world model covers (helpfully ordered thematically, rather than as a gradually unfolding tutorial like this one).
An object’s description property is displayed in response to the
command. You can set the value of
description using the syntax
The description of X is "..."
X is the object whose description you want to supply, and
the text of the description (making sure to retain the quotes). If a
description is applied to a room, that description is displayed when the player
first enters the room, or when the player issues the command
look (with no
direct object). In the following example, the Studio’s description of the room
is displayed immediately, and the piano’s description is shown if you type
"The Studio, described" by Allison Parrish The Studio is a room. The description of the Studio is "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts." A piano is in the Studio. The description of the piano is "A baby grand with a shiny finish."
A string that follows directly the construction that brings an object into
existence (i.e., X is a Y) are displayed in the room description. In the
example below, “You see the Studio’s trusty piano” is displayed in the room
description (and when the player types
look). For rooms, a string written
this way is simply treated as the room’s description. For more information on
how to customize room descriptions to your need, see section 3.1 in the Inform
Recipe Book on Room Descriptions.
"The Studio, described, with shortcuts" by Allison Parrish The Studio is a room. "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts." A piano is here. "You see the Studio's trusty piano." The description is "A baby grand with a shiny finish." A coat rack is here. "A sturdy coat rack in the corner beckons to your heavy outerwear." The description is "A free-standing coat rack, made of solid dark lacquered wood."
One other new thing in the example above: stating that X is here is equivalent to typing X is in Y, where Y is the room whose definition is closest and also earlier (i.e., above).
Relations between objects
Inform has many built-in object relations that facilitate player actions that are often associated with interactive fiction games, like picking things up, setting them down, putting things inside other things, etc. Let’s review a few of them.
Taking things and fixing them in place
First of all, objects can be picked up; once so taken, they end up in the
player’s inventory. This is implemented using Inform’s built-in carrying
relation, which means you can move something to the player’s inventory (say,
before the game has begun) using is carrying, e.g. The player is carrying an
apple. Objects are portable by default, meaning they can be picked up and
carried; but you can also set them to be fixed in place, which prevents the
player from picking them up. The following example shows these attributes in
action, including a new command
nail down that fixes things in place that had
not previously been so fixed, and
pry up to make them portable again after
having been nailed down. The player starts with a stuffed animal in their
possession, which must be dropped before it can be nailed down:
"Nailing things down" by Allison Parrish The Studio is a room. A chair is here. A pizza is here. The player is carrying a stuffed animal. Nailing down is an action applying to one thing. Understand "nail down [something]" or "nail [something] down" as nailing down. Check nailing down: if the player is carrying the noun, say "You can't nail [the noun] down if you're carrying it." instead. Carry out nailing down: now the noun is fixed in place. Report nailing down: say "You nail [the noun] to the floor." Prying up is an action applying to one thing. Understand "pry [something] up" or "pry up [something]" as prying up. Check prying up: if the noun is portable, say "[The noun] is not currently nailed down." instead. Carry out prying up: now the noun is portable. Report prying up: say "[The noun] is now free."
Scenery and descriptions
You can describe an object as scenery in order to (a) make it fixed in place
and (b) suppress showing the object’s description when the player visits the
location in which the object is found. This is useful for situations in which
you want to add evocative flourishes to your room descriptions that include
mentions of things that the player might want to examine (with the
command) but that should otherwise be ignored.
The following example shows scenery in action. Try
examine floor and
"The Studio, with floors" by Allison Parrish The Studio is a room. "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts. Light streams in through the window onto a beautifully worn hardwood floor." The window is here. The window is scenery. "Glass panes let sunlight stream through." The floor is here. The floor is scenery. "An expansive oak floor, lovingly worn by years of use."
Supporters and containers
There are two other relations between objects that Inform includes in its
built-in world model that work in similar ways: supporters and containers. A
supporter is an object that another object can sit on top of, like a table. A
container is an object that can contain other objects, like a cabinet or a
drawer. Inform automatically describes objects with these relations in the
room description. You can use the command
put on to put an object on a
put in to put an object inside a container.
Objects are not normally supporters. You can explicitly make an object a
supporter by describing it with is a supporter, as in the following example.
take pizza and
put pizza on piano, then
look to see the resulting
"The Studio, with supporters" by Allison Parrish The Studio is a room. "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts. There are beautifully worn hardwood floors." A piano is here. "You see the Studio's trusty piano." The description is "A baby grand with a shiny finish." The piano is a supporter. A pizza is here.
If you use is on to assert that one object is on top of another, as in the
example below, Inform automatically intuits that the object with the thing on
top of it should be a supporter. Note also in this example that supporters are
automatically fixed in place (trying
"The Studio, with implicit supporters" by Allison Parrish The Studio is a room. "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts. There are beautifully worn hardwood floors." A piano is here. "You see the Studio's trusty piano." The description is "A baby grand with a shiny finish." The piano is a supporter. A pizza is on the piano.
Containers operate much like supporters, except that you use is in to assert
that one object is inside of another object. The
put in command puts an
object inside the container. Here’s a simple example (try “put french horn in
"The Studio, with containers" by Allison Parrish The Studio is a room. A french horn is here. A case is here. The case is a container.
When you create a container, you can specify one or more
adjectives in the definition that
control what you can do with the container. A container can be openable, in
which case it can also be open or closed, and the player can open and close
the container with the
close commands. A container can also be
transparent, in which case the player can see what’s inside it, even if it’s
closed (like, e.g., a bird cage). A container can also be enterable, in which
case the player can get into it (using the “enter” command). The following
example illustrates the possibilities:
"The Studio, with nuanced containers" by Allison Parrish The Studio is a room. A pizza is here. [Could also write "The box is an openable open container."] A box is here. The box is a container. The box is openable. The box is open. A snowglobe is here. The snowglobe is an unopenable transparent container. A tiny snowman is inside the snowglobe. A wardrobe is here. The wardrobe is a closed openable enterable container.
There are lots of things to try here: put things in the box (like the pizza);
open and close the box; try (and fail) to open the snowglobe; open the
wardrobe, put things inside it, close the wardrobe (and notice that the objects
inside the wardrobe no longer appear in the room description, because it is not
transparent). Get into the wardrobe (
enter wardrobe) and exit from it
Descriptions of containers and supporters can reference what is on them or
contained in them. Here’s an example that changes the description of the box
examine box) depending on whether it’s open or closed, and if the pizza is
in the box:
"The Studio, with containers" by Allison Parrish The Studio is a room. A pizza is here. A box is here. The box is an openable open container. The description is "[if open]The shallow, square cardboard box is open wide.[else]An illustration of a proud chef adorns the top of the shallow, square cardboard box.[end if] [if the box is closed and pizza is in the box]You catch a whiff of bread, cheese, and zesty sauce.[end if]"
The interesting stuff here is happening in the text substitutions. The condition open is true if the box is open. The condition the box is closed is equivalent to closed in the description. Note here the conditions with and: the box is closed and pizza is in the box is true if the box is closed and the pizza is in there. In this case, the description gives a bit of supplementary olfactory information.
Finally, objects can be worn. This is represented with the wearing relation. You can assert that the player is wearing an object with is wearing (and ask whether the player is wearing something with the same assertion). Asserting that the player is wearing another object automatically makes that object wearable, or you can specifically assert this about an object when you declare it. (Otherwise, attempts to wear the object will be met with a “You can’t wear that!” error message.)
The following example demonstrates. Try
wear hat and
take off shoes:
"The Studio, with hats" by Allison Parrish The Studio is a room. A floppy straw hat is here. The floppy straw hat is wearable. The description is "A marvelous oversized floppy straw hat." The player is wearing tap shoes. The description of the tap shoes is "A new pair of patent leather tap shoes."
Putting it all together
Here’s a version of the studio that has many of the built-in relations we’ve discussed so far, plus a few more:
"The Studio, with more stuff" by Allison Parrish The Studio is a room. "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts. There are beautifully worn hardwood floors." The floor is here. The floor is scenery. "Oak floors, lovingly worn by years of use." A piano is here. "You see the Studio's trusty piano." The description is "A baby grand with a shiny finish." A metronome is on the piano. The description is "A wind-up metronome, made from wood and steel." The player is carrying a student ID card. The description of the student ID card is "Your student ID card, with an unflattering picture of you as a freshman." The player is carrying an apple. The apple is edible. The description of the apple is "A Granny Smith apple from the bodega across the street." The player is wearing tap shoes. The description of the tap shoes is "A new pair of patent leather tap shoes." The mahogany wardrobe is here. The wardrobe is an openable container. "In the corner, you see a mahogany wardrobe." The wardrobe is fixed in place. The description of the wardrobe is "The doors are [if open]wide open[else]shut[end if]."
Inform assumes that if X “is on” Y, then Y is a kind of thing called a supporter. Supporters are normally fixed in place.
Interactive fiction games often model space as a graph, where each node is a room, and those rooms are connected by edges labelled as cardinal directions. We’ve already seen how to create a single room, i.e., by stating X is a room. To create a graph of rooms that the player can move between, first create more than one room, then relate them like so:
X is DIR of Y
where X and Y are names of rooms and
[DIR] is a
direction. The built-in directions are:
north, northeast, east, southeast, south, southwest, west, northwest, up, down, inside, outside
These relations are reciprocal, meaning that if you state one room is north of another, the second room is also south of the first. You can override this behavior, however.
If your game only has one room, then the player begins in that room. If your game has more than one room, you can place the player in a particular room by asserting that the player is in that room.
The following example demonstrates a simple map. Try moving around in it
"The Studio and surrounding rooms" by Allison Parrish The Studio is a room. "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts. A door leads south to the Laboratory." The Laboratory is south of the Studio. "The laboratory is full of mysterious devices. A time machine stands in the middle of the room, beckoning you to enter. A doorway north will take you to the Studio, and steps lead down to the basement." The devices is scenery. The description of the devices is "Blinking LEDs, scrolling LCDs, beakers and tubes full of fluorescent fluids. Bleeping, blooping, glorping, glooping." The Time Machine is inside from the Laboratory. "For such a sophisticated device, the interior of this time machine has a surprisingly clean design. You see no recognizable controls. You can step out back into the Laboratory." The Basement is down from the Laboratory. "A dark room with low ceilings. Steps lead back up to the laboratory." The player is in the Basement.
Interfering with Graham’s actions
In the first part of this tutorial, we defined our own actions. In those actions, we were able to use the Check, Carry out and Report rules to stop actions, change game state, and print out the result of the action. It would be nice to be able to do those same things with built-in actions. For example, we might want to only allow the player to wear a particular object under certain circumstances, or to make a new room available only if a particular object is in the player’s inventory.
Generally, you shouldn’t try to modify the Check, Carry out and Report rules of the built-in actions directly. Instead, it’s best to use a different set of rules, which allow you to specify particular checks to perform before a built-in action takes place, or certain steps to perform after the action has succeeded. You do this with the Instead of …: and After …: rules.
The Instead of … is used to prevent an action from taking place. How it works: after Instead of …, specify an action. The action can consist of (e.g.) the action’s verb alone, or the verb plus a direct object (in the form of a single object, a kind, or “something” described with an adjective). When an action matching this description happens during the course of the game, the phrases in the rule will be executed, and the action will be stopped.
The following example demonstrates many of the possibilities. Try
attack piano or taking anything. (Attacking is a built-in action
that normally has no behavior other than displaying a “violence isn’t the
"Forbidden actions in the studio" by Allison Parrish The Studio is a room. A musical instrument is a kind of thing. The piano is a musical instrument. The piano is in the studio. The french horn is a musical instrument. The french horn is in the studio. Instead of eating the french horn: say "Alas, the french horn is a musical instrument, not a pastry." Instead of attacking a musical instrument: say "You resist the urge to damage the instrument." Instead of taking: say "Better not to remove anything from the premises without permission."
The After …: rule works the same way, but is triggered after the action has already taken place. This is a great way to print additional description of the action, or to update the state of the world with results of the action that aren’t a part of the default rules. In the following example, eating the apple makes a piano appear:
"Magic piano-apparating apples in the studio" by Allison Parrish The Studio is a room. An apple is here. "An apple is here, glowing eerily with edible magic." The apple is edible. The piano is nowhere. After eating the apple: say "The apple's flesh has magical effects!"; now the piano is in the Studio.
(“The piano is nowhere” is how you create an object without adding it to a room.)
An example that combines both Instead of and After:
"Tap shoe blues" by Allison Parrish The Studio is a room. "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts." The player is wearing tap shoes. The description of the tap shoes is "A new pair of patent leather tap shoes." The player is carrying an apple. The apple is edible. The description of the apple is "A Granny Smith apple from the bodega across the street." Instead of taking off the tap shoes: say "But they're so comfortable! And besides, your class will start any minute." After eating the apple: say "The tart flavor of the apple recalls the tart criticism of your dance instructor."
Making progress and winning the game
Making progress in an interactive fiction game often consists of having certain sections of the game available only when the game is in a certain state. The player, in performing certain actions that change the state of the game, attempts to unlock those previously unavailable portions of the game. The primary ways that Inform games keep track of state are object properties and relations between objects, such as the player’s location, the location of objects, etc.
The following example shows a complete game with a puzzle (of sorts) that depends on the player changing the game state in a particular way. It also introduces the end the story finally action which causes the game to end.
"Time Machine of the Performing Arts" by Allison Parrish The Studio is a room. "The studio is a well-appointed, spacious chamber for learning all manner of expressive performing arts. A door leads south to the Laboratory." The mahogany wardrobe is here. The wardrobe is an openable container. "In the corner, you see a [if open]open[else]closed[end if] mahogany wardrobe." The wardrobe is fixed in place. The wardrobe is closed. The description of the wardrobe is "Seemingly ancient beyond imagining, covered in eldritch designs that resemble sigils of a forgotten civilization." A pair of tap shoes are in the wardrobe. The description of the pair of tap shoes is "The shoes, made of an unidentifiable substance in a color you can't quite name, seem to glow and quiver of their own accord." The tap shoes are wearable. After wearing the shoes, say "You feel strangely powerful." The Laboratory is south of the Studio. "The laboratory is full of mysterious devices. A time machine stands in the middle of the room, beckoning you to enter. A doorway north will take you to the Studio." The devices is scenery. The description of the devices is "Blinking LEDs, scrolling LCDs, beakers and tubes full of fluorescent fluids. Bleeping, blooping, glorping, glooping." [this makes it possible to type "enter time machine"] The Time Machine is scenery in the Laboratory. Instead of entering the Time Machine, try going inside. Time Machine Interior is inside from the Laboratory. "For such a sophisticated device, the interior of this time machine has a surprisingly clean design. You see no recognizable controls. You can step out back into the Laboratory." Instead of going inside from the Laboratory: if the player is wearing the pair of tap shoes: say "As you enter the Time Machine, the strange tap shoes begin to hum. The walls of the Time Machine fade to darkness and an infinite field of stars appears around you. You hear a voice: 'Where in time would you like to go, Tap Shoe Captain?'"; end the story finally; otherwise: say "Your feet twitch, as though you've missed an opportunity."; continue the action.
Other things to learn about
This tutorial has barely put a dent in all of the features of the Inform 7 programming language, and even less of a dent in the richness of the built-in world model. But hopefully you understand enough to feel more comfortable diving into Inform’s rich documentation. (The documentation is also available in the IDE. Click on the “Documentation” tab.) Here are some topics you might explore next:
- All and every in conditions
- The Change chapter from Writing With Inform shows other ways of keeping track of game state in addition to relations
- Text with random alternatives is a fun and easy way to add variation to descriptions
- Sections 14.10 through 14.12 in Writing with Inform describe how to override built-in parser responses (like “You can’t go that way.”)
- Releasing your game (short version: Put “Release along with an interpreter and the source text.” in your source code, hit “Release” in the Inform IDE, then upload to, say, Itch or Neocities)
- Inform 7 for Programmers is indispensable.
- The Inform 7 syntax crib sheet, when “the author has seen a phrase that does what they want, but cannot remember exactly what it was” or “the author knows roughly what they want to do and cannot figure out where to look it up.”
- For more information about designing new commands, chapter 6 of the Inform Recipe Book is essential.
- Lea Albaugh’s Strange Loop 2014 workshop notes are fantastic and were a huge inspiration for this tutorial.
- Welcome To Adventure: A Quick-Start Guide to Inform 7 takes a more bottom-up approach than this tutorial, and is great for making something game-like fast.
- Advice: Always keep Mark-Oliver Reiser’s Inform 7 Cheat Sheet open in a window while you’re writing Inform code.
- From Emily Short, on generating text with Inform: Exercises in generated prose and Procedural text generation in IF.
- If you’re interested in learning more about the philosophy and implementation of Inform 7, I highly recommend Graham Nelson’s 2019 Narrascope talk and 2020 Narrascope talk.