Let's Play/Read: Inform 7 manuals (Done for now)

I wish I could just completely disable the skein! Is it possible to do that in Inform 10? I haven’t tried Inform 10 yet as I’m bound to the previous version for now.

Anyway, the skein can cause lag. If you don’t use it, it just sits there building up complexity. I’ve seen lag per move get up to 1-2 seconds after months of not cleaning. This happened to me again the other day. I thought my graphic automap was at fault, but as soon as I deleted all threads in the skein, it was back to going as fast as it could go in the IDE again.

Someone told me if you actually deleted the skein file on your computer, Inform wouldn’t recreate it, but that turned out not to be true for me. So I have to periodically go to the top knot and delete all threads. Sigh.

PS Don’t delete the Skein file with Inform open. You’ll probably get a crash as soon as you hit GO if you do.




How did I not know this!?

Had absolutely no idea until just now. It feels like finding out @mathbrush and @HanonO are cousins.


Oh yeah, they’re one of the three main IF power couples. The others are Jacqueline (Lott) Ashwell and Sam Kabo Ashwell, and me and my ego.

Oh man, I love the skein! I know it’s a bit unwieldy and requires regular pruning (I wish there was a way to indicate that I don’t want to track a particular session in the skein – actually, maybe there is?) but it’s really common for me to want to jump around to arbitrary points in my games, and the skein saves me from having to write like a dozen different shortcut verbs for testing (and then having to update them as things shift).


The “historical preface” in Graham Nelson’s I6 version of Adventure addresses this. It’s so interesting I can’t resist quoting part of it here (spoilered for length):


See also this thread:


OMG. Let’s Play Inform Examples I am so on board.

If there’s good stuff we can snippet from Borogove!


Chapter 2: The Source Text

Part 1

Now we get into the meat of things!

Mostly this thread was tongue in cheek about reading the manual being like doing a let’s play, but yeah I do want to actually check out the example too!

In section 2.1: Creating the World, we get our first taste of actual content creation!

This section deals with the difference between ‘things’ and ‘rules’. As the author states:

A new Inform project is void and without form, so to speak, with nothing created: but it starts with hundreds of standard rules already in place.

This to me is one of the reasons I strongly prefer Inform over languages that are less strongly rule-based, like Adrift or Adventuron or even Twine. In Inform, if I make the assertions he gives as an example:

The wood-slatted crate is in the Gazebo. The crate is a container.

Mr Jones wears a top hat. The crate contains a croquet mallet.

Then I instantly can do all sorts of interactions: remove the hat, put it in the crate, etc. I realize that some of this is baked into those language I mentioned earlier, but as games get more complex, Inform and its related powerful languages like Dialog, Hugo, and TADS have an upper hand because they’re all about creating rules and less about creating objects.

(Feel free to disagree!)

I’d like to point out that I’ve never used or even known that you can assert things the way he does in the second line:
Mr Jones wears a top hat. The crate contains a croquet mallet.

I’ve always written it the other way around:

Mr Jones is a man. A top hat is worn by mister jones. 

The crate is a container. A croquet mallet is contained by the crate.

So I’m already learning here!

And just to be clear about what I meant earlier about inform, typing these sentences above sets a lot of machinery in motion. For instance, I learned (as detailed in another thread) that saying something ‘wears’ something else automatically makes the first object a person and assigns them the male gender.

In section 2.2, we meet the first rule, the Ur-rule of the Inform manual:

Instead of taking the crate, say "It's far too heavy to lift."

This is appropriate for the first rule, since as John Ziegler recently pointed out, having custom messages for objects you can’t take is an important part of creating a sense of immersion.

The manual goes on:

We never see the complexity behind the scenes because the whole aim is to provide a basic, penny-plain, vanilla flavoured sort of realism. It would be surprising if one could put the crate inside itself, so a rule exists to forbid this. It would be surprising if one could drop something which was already on the ground, and so on. These basic rules of realism are the ones which every new Inform project starts with.

This is why I’ve often found it easier in Inform to start with a class of object that already exists in the game and modify it instead of making new rules for something out of scratch. For instance, staircases can be made as special doors that are always open and go up and down.

The steps to follow here are called “phrases”. Inform knows about 400 built-in phrases, but most of them are needed only occasionally. These three are used over and over again:

if tells Inform to do something only if some “condition” holds, here “the player is wearing the hat”;
now tells Inform to change the situation, here so that the hat moves to the crate; and
say tells Inform to say something, that is, to write some text for the player to read.

I’ve never thought of those as being all the same type of thing, but it makes sense now. Dialog does the same kind of thing, except instead of phrases it uses ‘predicates’, which are formed by placing two things inside of parentheses next to each other, which in context can be an if statement or a variable assignment.

Learning how to create my own phrases really helped over the years, and we’ll cover that later. For those familiar with programming, phrases essentially act like functions.

Phrase definitions are all linked to in the Phrases page of a project’s Index.

Really? That’s neat. I just checked it out, and it’s there! That’s so helpful. I wish I had seen this index years ago; there’s stuff in there I’ve searched intfiction or past source code so much for to get the phrasing right. Reading this manual is already paying off!

Section 2.3 is Punctuation. Here he mentions things like how full stops can go inside quotations without needing a stop outside:

The description is "Shiny." It is valuable.

is read as equivalent to

The description is "Shiny.". It is valuable.

I’ve noticed that, that I tend to get more errors about run on sentences when I don’t end in punctuation.

More specifically:

Sentence breaks like this occur only when the final character of the quoted text is a full stop, question mark or exclamation mark (or one of these three followed by a close bracket) and the next word begins, in the source code, with a capital letter. A paragraph break also divides sentences, behaving as if it were a full stop.

Then he mentions how brackets [ ] are used as comments when not inside of double-quotations and as ‘text substitutions’ when inside.

Single quotation marks at the edges of words are printed as double. So:

"Simon says, 'It's far too heavy to lift.'"


Simon says, "It's far too heavy to lift."

This is a useful tool (and has led me to permanently struggle with whether to use single or double quotes when putting a word in quotations in written text). But of courses it causes lots of problems with plural possessives like
"the millers' tales"
which gets rendered as

the millers" tales

Okay, I’m going to do a big quote now about this next part:

  1. Texts which end with sentence-ending punctuation - full stop, question mark, exclamation mark - are printed with a line break after them. So:
 say "i don't know how this ends";
 say "I know just how this ends!";

would come out quite differently - this doesn’t affect the appearance of the text, but only the position where the next text will appear. Something to be careful about is that this only applies when the punctuation occurs at the end of a “say”, as in these examples. (It doesn’t apply when a varying textual value is printed, using some text substitution, because then the pattern of where line breaks occur would be unpredictable - sometimes the value might end in a punctuation mark, sometimes not.)

These three punctuation rules for texts feel very natural with practice, and Inform users sometimes don’t realise the third rule is even there, because it just seems the right thing to happen.


and Inform users sometimes don’t realise the third rule is even there, because it just seems the right thing to happen.


Anyway, moving on…

(Actually, before moving on, Inform is my favorite IF language, but this is the one thing I’ve struggled the most with. I’ve probably spent > 15-20 hours over all my projects combined dealing with weird whitespace issues. When I tried the Dialog language, I found I preferred Inform over it in most areas, but one of its major selling points to me is its perfect handling of whitespace. I never had to debug line breaks even once).

Anyway, back to the text! We have this mysterious comment which I don’t quite understand:

It also has the more exotic “|” (not a capital I, a vertical stroke) for paragraph breaks outside of quoted text, but people hardly ever need this.

If anyone can give me an example of this, I’d love to see one!

Section 2.4 is about ‘problems’, not in the general sense, but as the little helpful things that pop up when you compile. My style of programming usually results in 3-10 ‘problems’ every time I compile. Here is the example ‘problem’ given:

Problem. You wrote ‘A starting pistol is in the cup’ Reveal.png, but in another sentence ‘A Panama hat is on the cup’ Reveal.png: the trophy cup cannot both contain things and support things, which is what you’re implying here. If you need both, the easiest way is to make it either a supporter with a container attached or vice versa. For instance: ‘A desk is here. On the desk is a newspaper. An openable container called the drawer is part of the desk. In the drawer is a stapler.’

I know sometimes these problems can be unhelpful, but I find that they almost always resolve my problem quickly.

Next is one of my favorite sections: Headings!

Firstly, we can put the title at the top. If the first paragraph consists only of a single quoted piece of text, then that’s the title; and an author can also be given, as follows:

"Spellbreaker" by Dave Lebling

But this isn’t the type of heading I’m talking about. I’m talking about this:

A sentence which is the only one in its paragraph and which begins with any of the words “volume”, “book”, “part”, “chapter” or “section” is considered to be a heading or a sub-heading. It must not contain a typed line break, and in order to stand alone in its paragraph there should be a skipped line both before and after it. For instance:

Section 2 - Flamsteed's Balloon

I find this incredibly useful for organizing my code. It makes it easy to hop back and forth and also serves as an outline that I can sketch out and then fill in. My current project is filled with a bunch of empty Volumes and Books and such to represent different areas of the game, where Chapters are for individual rooms and Sections for individual NPCs or important objects.

Section 2.6 explains why section headings are important:
*They’re used in ‘problem’ reporting when compiling
*They’re used in the ‘index’ to allow quick travel (and I should mention they also create separate webpages when releasing your source as an html file)
*Inform allows you to refer to objects by part of their name (like ‘the yellow dog’ can be called just ‘dog’). When compiling ambiguous code (perhaps you refer to ‘dog’ when there is also a ‘red dog’), instead of throwing an error, the compiler assumes by default that you meant the object of that name in the heading nearest your current code.

In section 2.7 we’re getting to the debug commands. I don’t use these very often, so this will be useful!

This sections introduces SHOWME, a ‘godlike’ command that only shows up in the IDE, and not when hitting ‘release’.

The testing command SHOWME prints out a brief summary about a room or thing, and any contents or parts it may have. Typing SHOWME on its own shows the current room, but any item or room in the story, however distant, can be named instead. For instance:

Boudoir - room
four-poster bed - supporter
yourself - person

>showme diamonds
diamonds - thing
location: in the strongbox on the dresser in the Drawing Room
unlit; inedible; opaque; portable; singular-named; improper-named
description: The diamonds glitter dangerously.
printed name: diamonds

I almost never use that.
In 2.8, though, we get the TEST command, one I use all the time. This is ‘unit testing’ (I think, I’ve never actually figured out what that means), but it lets you check that a certain set of actions in your code works. I use it to make sure the game is still winnable after making changes.

It is an alternative to the skein:

All the same, most works of interactive fiction contain occasional vignettes, either in terms of short scenes of narrative, or in the behaviour of particular things or rooms, which we would like to test without the fuss of using the full story-level Skein tool. The examples in the documentation are like this: in almost every example, typing TEST ME puts the story through its paces.

Testing commands show up in all of the inform examples. I first used them when I created an Inform extension for the first time.

You create testing sequences like this:
Test balloon with "get balloon / blow balloon / drop balloon".

This has no effect on the design itself, but ensures that when the story is played, typing “test balloon” will run through the given three commands in sequence, as if we had typed “get balloon” and then “blow balloon” and then “drop balloon”.

You can also nest testing scripts:
Test all with "test balloon / test door".

I have dozens of testing commands. For each puzzle I have one, and if a room has multiple puzzles, I have a bigger one for each room, then a bigger one for each area, and then one mega one.

Finally, there’s a little cheaty command:

Sometimes when testing it’s convenient to get hold of something not easily available at the moment. The testing command “PURLOIN” does this:

The jewelled Turkish clockwork hat is in the sealed glass box.

Section 2.9 is brief. It basically gives you a way to add more cheater code for debugging.

If you add the words ‘not for release’ after a section, it makes that section’s code disappear when ‘releasing’. Here is an example:

Section 10 - Open sesame - Not for release

Universal opening is an action applying to nothing.
Understand "open sesame" as universal opening.
Carry out universal opening: now all doors are open.
Report universal opening: say "Open Sesame!"

I haven’t really used this before, and I do have some cool meta-testing commands (like printing every description in the game). But leaving that in might be fun to find as an easter egg…IDK.

2.10 is about extensions. I’ll be honest, I almost always avoid extensions. I just don’t like them. I’d rather code the thing myself. The only times I use them are when they’re something that essentially should or could be core Inform functionality (like Emily Short’s Locksmith or the Numbered Disambiguation extension by Aaron Reed).

I have written my own extension for conversation, since I was copying it from game to game anyway, but I don’t think anyone else has ever used it.

Extensions are in a weird spot. There is an official extension website, official github, and official way to download directly from Inform IDE, but if I recall some of those or obsolete, nonexistent, or give outdated extensions, and I’m not sure which is which.

For those not aware of what extensions are, it’s just a way of splitting up code into separate files. You could just as well copy the extension’s code directly into your text, but using extensions allows you to keep it neat and tidy.

2.11 says how to include extensions, which is fairly easy once they’re in the right folder:

Include Locksmith by Emily Short.

Next, in 2.12, are the ‘Use’ options. I first learned about these when I was copying Emily Short’s Glass code for my first game.

These are global options for the game that you invoke at the beginning. Here are some options highlighted here:
Use American dialect.
Use the serial comma.
Use scoring.

Use full-length room descriptions.
Use abbreviated room descriptions.
Use VERBOSE room descriptions.
Use BRIEF room descriptions.
Use SUPERBRIEF room descriptions.

Use undo prevention.

Some of these overlap (VERBOSE and full-length are two ways of saying the same thing).

He mentions about UNDO prevention (and I have to agree):

(Many players consider UNDO to be their birthright, and that any work using this option is an abomination: indeed, it has even been suggested that this section of the Inform documentation be censored. To use the option is to court controversy if not outright hostility.)

Fortunately for me as a player, even if someone codes in UNDO prevention, there are special interpreters that have their own built-in UNDO, and it’s impossible to fully remove UNDO from an inform game.

(I was going to split this update over two posts but a lot of these sections are short).

2.13 is ostensibly about administering classroom use. But it really comes down to two small things.

The first is that you can add a text file called ‘options.txt’ in the Inform home folder that will run code in every single game file you compile on that computer. It only works for use options, test commands, and release instructions.

The second thing is that you can add ‘use telemetry recordings’ at the top of a game file (or in options.txt) to send all of its outcome and problem messages to a txt file in the folder. He adds:

Telemetry only records the contents of the “Problems” panel - notes of success or failure, and problem messages - and nothing is transmitted via any network, so it isn’t really surveillance. The user can deliberately add a note to the current telemetry file by writing something like this in source text:

> * "I don't get it! What's a kind? Why can't the lamp be lighted?"

(This is a way to make a note for the benefit of someone who will read the telemetry file - for instance, to comment on a problem message that has just appeared. Note the double-quotes. Otherwise, it’s meant to look like the standard way that beta-testers mark up IF transcripts.)

Has anyone used this before? That would be interesting. Apparently they’re due to requests from teachers using Inform in the classroom.

Section 2.14 is formats: glulx versus z-machine. Here are the two described:

Newly created projects are set up with the Glulx format. This has largely taken over from an earlier format called the Z-machine, but Inform can still generate a version 8 Z-machine file (a so-called “z8”) if required. The Z-machine is of historic importance, and may continue to be useful for certain tasks where Glulx support is not yet available, but most users will want to keep the Glulx format set all of the time.

Of course, right now there is a big retro movement (as seen in the PunyJam), where the z-machine has seen increased emphasis.

The z-machine has inherent memory limits that cannot be overcome.

Section 2.15 is about bug reporting, for which instructions are given here:

The final section in this chapter is 2.16: Does Inform really understand English?

The answer is, of course, no.

Here is an example of understood code vs not unerstood code:

For instance, Inform understands

something which is carried by the player

but not (at present, anyway)

something which the player carries

He also gives:

an example which genuinely arose in beta-testing:

The life support unit fits the egg.

in which Inform construed the verb as support and not fits, and then created items called “the life” (plural) and “unit fits the egg”.

And that’s it for Chapter 2!

This chapter was both fun and disappointing. Fun, because I learned about the phrases index, and disappointing, because there were a ton of technical details, very technical ones in fact, and we haven’t reached a single example yet! This style seems more suited to math textbooks (which I love to read), that start out with the precise foundations of things at very theoretical level before outlining the individual steps. Perhaps the recipe book will be more friendly for starting off a game.

Next time we’ll pick up with the chapter on Things!


Dialog is awesome for many reasons; this is definitely one of them.

1 Like

Barring the handful that are Z-machine only or whose point is dealing with external resources like the generated map, all of the 10.1 examples are already playable/editable Borogove snippets.

And for anyone following along with reading the docs, one of the motivations behind my 10.1 docs web remix was to offer them on a page per chapter instead of page per section basis, which I generally prefer, e.g., WI Chapter 2: Creating the World.


WI 2.3: Punctuation

I had forgotten that you don’t need to bracket a single-quote to avoid it turning into a double-quote if said single-quote is in the middle of the word.

Doh. This feature is long-gone and my pull request to strike the vertical stroke was accepted shortly before 10.1’s release, but it seems to have reverted.

[Edited: oops, I remembered it wrong: I submitted it just before 10.1.2 but after 10.1.1, so there was no reversion; it just hasn’t been in a released version yet.]


I find it very handy as a game’s playthrough gets longer. Of course there are always “purloin” and “gonear”, but sometimes you need to make sure that the accumulated state of a series of commands starting at the beginning remains consistent.

When I get to the end of a long series of turns where I run into a bug or something missing or whatever, it’s nice to have the skein to replay what I’ve done once I’ve fixed the problem.


WI 2.5 Headings

"Spellbreaker" by Dave Lebling

This is identical in effect to:

The story title is "Spellbreaker".
The story author is "Dave Lebling".

It’s just a different syntax.

“volume”, “book”, “part”, “chapter” or “section”

Ryan Veeder’s “Very Bad People Choose Sin” has stuck with me as a mnemonic to keep the order straight.

WI 2.6: Why using headings is a good idea

Finally, headings are used when working out what a name refers to.

I read this as a warning, not a feature: refer to your objects unambiguously in your source, or reordering things in a way you expected to be harmless can suddenly change your code’s meaning.

WI 2.7: The Showme Command

There’s an interesting thing going on in the attribute reporting that doesn’t call a lot of attention to itself. We see for a container, for instance:

singular-named, proper-named; unlit, inedible, portable; opaque, open, unopenable, unlocked

Let’s put line-breaks after those semi-colons:

singular-named, proper-named;
unlit, inedible, portable;
opaque, open, unopenable, unlocked

They’re grouped by the kind of origin: singular-named and proper-named are attributes of objects; unlit, inedible, and portable are attributes of things; finally come the attributes particular to containers. (If a kind in the middle didn’t add any attributes it would be simply skipped without any indication that anything was being skipped.)

A small disappointment is that we’re only told about attribute states in the negative if the negative state is named, e.g., unlocked, unlit, inedible, but not not scenery, not wearable. So there’s no indication of what attributes a thing could have but happens not to have right now if those attributes only have specific names in the positive.

There are two either-or properties Showme omits: described and mentioned. It’s just as well that it doesn’t mention mentioned: its value is only of interest during certain operations (and, besides, the first thing Showme does is print an object’s name, so everything would be mentioned). But I think it’d be nice if we had described. So what the heck, let’s add it.

Section pretty-printing (not for release)

pretty-printing is an action applying to one visible thing.
understand "pp [any object]" as pretty-printing.
Carry out pretty-printing: pp noun.
To pp (o - object): (- SafeShowMe({o}); -).

Include (-
[ SafeShowMe obj x;
@push noun;
noun = obj;
print "described: ";
if (obj has concealed) print "no";
else print "yes";
print "^";
@pull noun;

[ Edited: @OtisTDog pointed out a cleaner way to include described, just by omitting its suppression. ]

Include (-
[ SafeShowMe obj x;
@push noun;
noun = obj;
@pull noun;

[ AllowInShowme pr;
	if (pr == workflag or mentioned) rfalse; ! MODIFIED
-) replacing "AllowInShowme".

Oh that’s neat - I’ve had the same thought re described but nowhere near the chops to do anything about it!


WI 2.8: The Test command

The only way to thoroughly test a work of IF is to run a complete solution through it, and carefully check the resulting transcript of dialogue.

I have vaguely gotten the impression from multiple sources that once upon a time having a complete walkthrough script that demonstrated that there existed a successful path through the game constituted some ne plus ultra of quality assurance, as opposed to runners-up that were straight up unfinishably buggy. If I had come to this cold, without that impression, I would just be puzzled, 'cause this sounds like an extremely minimal standard, not a thorough one.

I can’t recall having ever seen the in <location> or holding <thing> parameters to a test statement outside of the docs.

WI 2.12: Use options

American convention for spelling out numbers (thus, “one hundred seventeen” not “one hundred and seventeen”)

I am a native speaker of American English and in most contexts leaving out the “and” would sound weird to me.

It is a disappointment to me that the serial comma isn’t the default, but I’ll keep going somehow.

I was playing IF in the '80’s. I get why Brief and Verbose existed. But the '80’s were a long time ago, and it seems weird to me that Brief and even Superbrief modes persist as these easily selected options. Or that scoring was originally the default.

WI 2.13: Administering classroom use

Options.txt still works… but with all its restrictions you’re not likely to find it useful for personal use.

This must be used only to set use options, specify test commands, and give release instructions.

And I’d avoid it just because it’d be too easy to forget you have something there affecting every project you compile.

WI 2.14: Limits and the Settings Panel

I’ll just get this out of the way and not dwell on it going forward: Inform 7’s continued Z-machine support is a feature I’m indifferent to.

WI 2.15: What to do about a bug?

Knowing how to search for known bugs and how to report bugs are important skills for I7 programmers; I’d encourage everyone to create a Jira account.

And in conclusion: there’s no darn way I’m going to continue to keep up with Brian.


I definitely think Superbrief is now pointless. Brief can be useful to reduce transcripts, or give you more scrollback if it’s limited, or to speed up playing with a screen reader. That said, I think people are so unaware of it – both authors, and people who could benefit from it as players – that it doesn’t get supported properly in the first place. And when it’s not been supported by the author, it’s dangerous to let players turn it on.



…and so many people advicing others not to create a parser…

Let’s do it! Love is in the air!


Chapter 3: Things (3.1-3.7)

Chapter 3 let’s gooooooo!!!

Okay, so here I think we’ll get into actual game coding.

Appropriately, the very first example of real game code in this chapter is drawn from a port of Adventure (and the inform port of adventure is one of my favorite games of all time):

The Cobble Crawl is a room. "You are crawling over cobbles in a low passage. There is a dim light at the east end of the passage."

A wicker cage is here. "There is a small wicker cage discarded nearby."

The Debris Room is west of the Crawl. "You are in a debris room filled with stuff washed in from the surface. A low wide passage with cobbles becomes plugged with mud and debris here, but an awkward canyon leads upward and west. A note on the wall says, 'Magic word XYZZY'."

The black rod is here. "A three foot black rod with a rusty star on one end lies nearby."

Above the Debris Room is the Sloping E/W Canyon. West of the Canyon is the Orange River Chamber.

(I actually tried running this through a Borogove snippet but it said it took too long to respond, so my computer must be wonky again).

This is a perfect example to start off with because it shows how powerful Inform is for beginners and how hard it is to master for experts.

It’s good for beginners because it automatically makes rooms with two-way connections, objects that can be understood with both the adjective part and noun part independently, objects with a special message about them before they are picked up and a standard message after they are dropped again, etc.

So it makes an adequate game really easily. But not a GREAT game. Why not?

If we play this story, we find that we can type TAKE CAGE or TAKE WICKER CAGE, for instance, but not TAKE SMALL CAGE. Inform saw that we called this “a wicker cage” when it first appeared in the source text, and assumed that the player would call it that, too. (Whereas it didn’t look inside the descriptive text to allow for TAKE SMALL CAGE or TAKE DISCARDED CAGE or TAKE NEARBY CAGE.)

So a ton of IF programming is about this part here: making objects do everything they claim to do in the description, and adding all the synonyms.

I think the most synonyms I have for one thing in my current game is a haunted house:
The scenery-mansion is scenery in the front-room. The printed name of the scenery-mansion is "mansion". Understand "gorgeous" or "well-preserved" or "well" or "tidy-looking" or "tidy" or "asymmetrical" or "haunted" or "house" or "looking" or "house" or "mansion" or "queen" or "anne" or "preserved" or "victorian" or "tall" or "stately" or "handsome" or "old" or "parlor" as the scenery-mansion. The description of the scenery-mansion is "This is a tall and stately old Victorian mansion in the Queen Anne style. It is asymmetrical, with a tower on one side and some steps leading up to a tall wooden door on the other."

Back in Section 3.1, he points out:

A small limitation here is that probably only the first 9 letters of each word are read from the player’s command. This is plenty for handling the wicker cage and the black rod, but it might be embarrassing at a meeting of the Justice League to find that KISS SUPERHERO and KISS SUPERHEROINE read as if they are the same command.

I ran into problems with this myself in my first published game Ether, where I had 3d directions like NORTHEASTUP and SOUTHWESTDOWN. I thought I had found a way or been told a way to change this limit, but I looked through my source code and didn’t see anything, and just now trying it it can’t distinguish between NORTHEASTUP and NORTHEASTDOWN, so that’s odd. Fortunately I implemented shortcuts like NEU and NED.

Back to the text:

[T]he player begins in the Cobble Crawl because it was the first room created in the source text, but we could instead have written text like:

The player is in the Cobble Crawl.

This is one of those things that is a great convenience for new authors but mildly frustrating for experienced ones. Whatever room is listed first in the code is the one you get placed in unless you specify otherwise. In the past I remember mentioning a room once, many lines away from the rest of its code, so it’d be the first room.

Now let’s look at the examples! Sample programs 2 through 4. Since there are 400 examples in the text, I will only point out interesting features as they come.

The very first example includes some code ‘not for release’:

When play begins (this is the run property checks at the start of play rule):
    repeat with item running through things:
        if description of the item is "":
            say "[item] has no description."

I use something like this a lot, but I print out everything:
Alldescriptioning is an action out of world. Understand “alldesc” as alldescriptioning.

Carry out alldescriptioning:
	repeat with current running through things:
		if current is not nothing:
			say "[current]: [description of current][paragraph break]"

I run this through spellcheckers some times (although heaven knows they don’t catch everything).

Example 2 is just two rooms with long descriptions, with the game having the ‘brief room descriptions’ setting to try out.

Example 3 is interesting to me, as it has a way of changing the description of a room after the first time it’s seen that’s different than what I usually use (this is a partial snippet):

Slightly Wrong Chamber is south of the Awning. "[if unvisited]When you first step into the room, you are bothered by the sense that something is not quite right: perhaps the lighting, perhaps the angle of the walls. [end if]A mural on the far wall depicts a woman with a staff, tipped with a pine-cone. She appears to be watching you."

I always use [first time]…[only] for this instead of [if unvisited], but recently I’ve been wanting a way to ‘restart’ the first time only thing, so I wonder if this would work better, as I’m pretty sure you can say stuff like ‘now ThisRoom is unvisited’ or something. Could be worth a shot.

Some further fine print: we might write our condition as “if unvisited”, “if the location is unvisited”, or “if the Chamber is unvisited” – all of these constructions would be acceptable, but in the absence of more specifics, the condition is understood to apply to the object whose description it is.

This is something I never realized until recently. I have been struggling so much with how to refer to the current noun being referenced inside of its description; apparently you just don’t use any noun at all. Here’s an example from my code (that I got help with):

A climbing-rock has a nato-code. Understand the nato-code property as describing a climbing-rock. A climbing-rock is usually alfa. After printing the name of a climbing-rock: say " labelled '[nato-code]'". The description of a climbing-rock (called currentrock) is usually "This is a rock labelled [nato-code], attached to the climbing wall."

So I thought I’d have to type ‘nato-code of the noun’ or ‘nato-code of the noun described’ but you just say ‘nato-code’ and it understands automatically that it’s nato-code of the current thing.

Anyway, that was a big section. On to 3.2, Rooms and the Map!

Here we list all the directions: compass directions (N,NE,E,SE,S,SW,W,NW), UP and DOWN, and:

Two more directions are provided by Inform: “inside” and “outside”. These are best used when one location is, say, a meadow and the other is a woodcutter’s hut in the middle of it; we might then say

Inside from the Meadow is the woodcutter's hut.

The “from” is important, as it clarifies that we intend to link two different locations, not to create an item - the hut - in a single location - the meadow.

I struggled with inside and outside when writing 77 Verbs because typing OUT in inform can mean both exiting a supporter/container and going outside. I thought the inform names for the directions were just IN and OUT for a while.

A problem which sometimes arises when laying out maps is that Inform allows short forms of room names to be used as abbreviations. This is usually a good idea, but has unfortunate results if we write:

The Airport Road is west of the Fish Packing Plant. The Airport is west of the Airport Road.

…because “Airport” is taken as a reference to “Airport Road”, so Inform makes only two locations, one of which supernaturally leads to itself. We can avoid this by writing:
The Airport Road is west of the Fish Packing Plant. A room called the Airport is west of the Airport Road.

In small games I avoid this by just not naming things with names I’ve already used, but in my giant game, I have everything private-named. For instance, I have ten different ‘buttons’ in my game in wildly different circumstances (from an organ stop in Dracula’s library to a Sphinx’s nose to an evidence machine in a futuristic police department). So I have them all named stuff like ‘soda-button’ and just change their printed name and what their synonyms are.

He does offer an intriguing option which I might actually use (could be a good time to use the options.txt mentioned in the last chapter?)

If we really want to get rid of this issue once and for all, starting the source text with the use option “Use unabbreviated object names.” will do it, but the effect is drastic. This instructs Inform not to recognise names other than in full. For example:

West of the Kitchen is the Roaring Range. South of the Range is the Pantry.

is ordinarily read by Inform as constructing three rooms (Kitchen, Roaring Range, Pantry); but with this use option set, it makes four (Kitchen, Roaring Range, Range, Pantry), in two disconnected pieces of map. Handle with care.)

The first example in this section is Port Royal, a recurring example that is usually used to tack on very small changes that don’t merit a full game. This is its first appearance, though, so it has a little more substance, describing several streets, alleys, and a tavern.

Looking at the World tab of the Index, we can also see a schematic map of the simulation as it currently stands.

This is true, and I use my map in the Index a lot, especially since I have a lot of rules that only function in certain regions and the Index map color-codes regions.

Next is Up and Up, which adds a nice way to add a transition between rooms:

Before going to the Endless Tower:
    say "You climb... and climb... and climb... The sun sets. The moon rises. The wind begins to blow. You continue to climb..."

I’d caution that players often won’t see this if the next room is big, as it prints before the bold heading and the new room description. You can fix this by making it very noticeable (I’ve used lines of asterisks) or by adding a ‘wait for any key’ type feature.

Last is our first 3-star example, Starry Void. This has a ‘room’ you can see from the outside. I usually just make a scenery object for the room and put a door in it or allow a command for entering, but they suggest making the object itself be a door:

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]".

Section 3.3 is ‘One-way Connections’. This just points out that Inform automatically makes two-way connections, but that we can override that by describing each connection separately:

The Debris Room is west of the Crawl.
The Hidden Alcove is east of the Debris Room.

and even make a ‘blank’ connection one way:
East of the Debris Room is nowhere.

I’ve used that recently to make a ‘boneyard’ area like Spellbreaker where you end up after dying. You can leave it but can’t come back without dying again.

Bizarrely, being more specific can actually remove connections:
Finally, note that Inform’s assumptions about two-way directions are only applied to simple sentences. When the source text seems to be saying something complicated, Inform takes it as a precise description of what’s wanted. So, for example, in:

The Attic is above the Parlour.
The Attic is a dark room above the Parlour.

Inform makes guesses about the first sentence, and makes a two-way connection; but it accepts the second sentence more precisely, with just a one-way connection.

The first example here is Port Royal again, but with asymmetrical connections, which I detest on principle (but is important in a recipe book since authors often want them).

Next is a simple elevator that changes what exit it is every time you enter it (this is a pretty slick method):

After going to the Secret Elevator:
    say "The doors automatically close, there is a rush of motion, and they open again.";
    if UNCLE Headquarters is mapped west of the Secret Elevator, now Del Floria's Tailor Shop is mapped west of the Secret Elevator;
    otherwise now UNCLE Headquarters is mapped west of the Secret Elevator;
    continue the action.

Section 3.4 is Regions and the Index Map.

Regions are a nice way to clump things together. For instance:

The Arboretum is east of the Botanical Gardens. Northwest of the Gardens is the Tropical Greenhouse.

The Public Area is a region. The Arboretum and Gardens are in the Public Area.

This is mostly just a preview for future things. Important to note, though, that:

Regions can be put inside each other:

The University Parks is a region. The Public Area is in the University Parks.

but they are not allowed to overlap other than by one being entirely inside the other.

This is very useful if you have areas with very different responses from others (for instance, an underwater region where actions like jumping and swimming should all have similar responses in a cluster of rooms).

Port Royal is given another example where it is divided into regions.

Now we’re getting good. Section 3.5 is about Kinds, which I’ve found very useful, and is an example of the rule-based programming that makes Inform work better (to me) than interaction-based languages like Adrift and Adventuron.

Kinds are categories of objects with similar sets of interactions. He lists some examples:

Garden, Gazebo, Treehouse - room
billiards table - supporter
cup - container
starting pistol - thing
East, up (implied by “above”) - direction

Not mentioned here is the best thing about kinds, that you can make your own.

For some bizarre reason, the first example game in this section doesn’t have anything to do with kinds, but instead shows how you can provide synonyms for nouns:

Understand "tv" and "telly" as the television.

Perhaps it’s because this example also includes a device, which is a kind? But devices weren’t listed in the text, so…

Example 12 just shows how you can make Inform implicitly assume the kind of thing by the way you describe it:
East of the Garden is the Gazebo. Above is the Treehouse. A billiards table is in the Gazebo. On it is a trophy cup. A starting pistol is in the cup. In the Treehouse is a container called a cardboard box.

Section 3.6, either/or properties, lists the following useful properties:
fixed in place/portable

I use these all the time. My current game has a lot of open unopenable transparent containers in it.

Hanon Ondricek used these to good effect in his IFComp 2014 blurb for Transparent (which sadly is not reproduced in its IFDB page):

There is a house. There is a room in the house. There is a door in the room. The door is locked. Some people are in the room. Some people are transparent.

Example 13 is in this section: ‘Tamed’. It describes a lion’s cage:
The Center Ring is a room. The cage is in the Center Ring. A lion is an animal in the cage. The cage is enterable, openable, transparent, and closed.

and a pedestal:
The pedestal is in the Center Ring. It is enterable. The player is on a pedestal.

and a magician’s booth:
The magician's booth is a container in Center Ring. "Off to one side is a magician's booth, used in disappearing acts. The exterior is covered with painted gilt stars." The booth is enterable, open, not openable, and fixed in place.

Section 3.7 is Properties Depending on Kind. It just says that some things are automatically assumed about kinds, like that all supporters like tables are not able to be picked up, but this can be changed by saying ‘The table is portable’.

This section has the first example of Disenchantment Bay, a running example. Similar to last section, it uses properties like ‘transparent’ and ‘openable’ for a glass case, but also introduces plural indefinite articles:

The bench is in the cabin. On the bench are some blue vinyl cushions.

Using “some” rather than “a” or “the” tells Inform that the cushions are to be referred to as a plural object in the future

Since this update is close to 3000 words, I’ll stop here (I think that’ll be my goal). I might do another one later today or not, but next up will be scenery!


Both true! An end-to-end walkthrough is an extremely minimal standard, and if you don’t have one, your game may be unfinishably buggy. The whole point is to verify that your game is finishable!

But you’re correct that the manual says “thorough” when it really means “at the very least”.

The unspoken part is that the Skein feature is a tree, so you can use it to test lots of game sequences, not just the victory path. So it can be the basis of an actually thorough testing process, where you verify significant responses for every puzzle and verb.


Continuing to really enjoy this!

Oh, interesting - I always use the slash syntax for stuff like this, but this is more readable in some cases.

I ran into this in my first game too - I had lots of big words! You do:


To increase the limit - pretty sure it’s mentioned in the docs though obviously not here.

Oh, an other clever idea - I should do that too.

I always use [one of]…[stopping] - it’s neat to see the different styles!

I had a similar confusion - also took me a while to understand that “putting it on” and “inserting it into” are entirely different actions.


Im my current game there’s a part where the PC is supposedly crouched, in a room where ‘exit’ is used to mean ‘go outside’. So one of my testers says ‘stand up’ and unintentionally leaves the room!


There’s a good argument to be made for purging the IN and OUT directions and instead letting the entering and exiting actions handle it. But a lot of Inform’s design is for reasons of historical inertia; precedent is a difficult force to overcome.