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

I’ve never actually read through the Inform manuals Writing with Inform or the Inform Recipe Book. I use them all the time, but I mostly just started by copying the source code from other games (notably Emily Short’s Glass, which was the only open source code I could find at the time) and looking up things in the documentation search or forums when I get stuck. I’ve really enjoyed the fact there is extensive documentation and the numerous examples; when using languages such as Adventuron and Dialog, the lack of coded examples was rough, and I had to message the creators of both languages to discover some undocumented secrets.

Inspired by the other great Let’s Plays in the Let’s Play category, I’ve decided to go through Writing with Inform (and probably the second book too). I’ll post snippets of it here, and my thoughts. Feel free to play along!


Speaking as the guy who did the Cragne Manor Let’s Play, I admire your courage! Really looking forward to this.


Chapter 1: Welcome to Inform

Boy, this is one I’ve never seen at all. I thought I had tried reading through this before, but it must have been the other book that I tried to consume all at once.

Right away I see things I’m not sure are accurate:

Writing with Inform is one of two interlinked books included with Inform: a concise but complete guide to the system. The other book is The Inform Recipe Book, a comprehensive collection of examples, showing its practical use. If you are reading this within the Inform application, you will see that the Writing with Inform pages are on “white paper”, while the Recipe Book is on “yellow paper”. [emphasis mine]

Really?? I go to look. Sure enough:

It is hard to see, but there is in fact a subtle difference between the two when viewed from inside the IDE. Subtle, but neat.

The rest of section 1.1 is pretty standard stuff, the kind of text you see at the beginning of most textbooks. Most notable are this quote:

Programming is best regarded as the process of creating works of literature, which are meant to be read… so we ought to address them to people, not to machines. (Donald Knuth, “Literate Programming”, 1981)

And our very first Example game (I’ve never seen the first one in the wild; I always see examples with high numbers, so this is kind of exciting).

Rather than code itself, this has an explanation of the examples:

The same examples are included in both of the books of documentation, but in a different order: in Writing with Inform, they appear near the techniques used to make them work; in The Inform Recipe Book, they are grouped by the effects they provide. For instance, an example called “Do Pass Go”, about the throwing of a pair of dice, appears in the “Randomness” section of Writing with Inform and also in the “Dice and Playing Cards” section of The Inform Recipe Book. Clicking the italicised WI and RB buttons at the right-hand side of an example’s heading switches between its position in each book.

I never realized that RB and WI stood for Recipe Book and Writing with Inform!

I did know that the little blue icon meant it would copy your code in (as is mentioned in this section). The star system is also explained:

asterisk.png - A simple example, fairly easily guessed.
asterisk.png asterisk.png - A complicated or surprising example.
asterisk.png asterisk.png asterisk.png - An example needing detailed knowledge of many aspects of the system.
asterisk.png asterisk.png asterisk.png asterisk.png - A complete scenario, containing material not necessarily relevant to the topic being demonstrated.

This example, example 1, is itself a 1-star example.

Section 1.2, Acknowledgments, brings a lot of familiar faces. I think this has been updated quite recently, as the Github version is different from the version in my downloaded IDE. This newer version contains references to the IFTF, for instance, and even one for me, which I found disconcerting (but I think it’s because I helped [very ineptly] with bugs last year).

The main attributions are right at the top for Emily Short and Zarf:

Inform 7 is dedicated to Emily Short and Andrew Plotkin, whose shrewd and sceptical suggestions made a contribution which can hardly be overstated. A long email correspondence with Andrew entirely subverted my original thoughts about natural-language IF, as he convinced me that the “new model” of rule-based IF was a truer foundation; while Emily’s wry, witty analysis and how-about-this? cheered me at low moments, besides providing the impetus and often the specifics for a lot of the best ideas.

I know Emily Short was involved a lot in the creation of these books, so I looked for sources. Emily Short says in a comment from 2009 on her blog that:

I wrote almost all of the examples themselves, and the bulk of the text in the “Recipe Book.” Graham Nelson wrote the bulk of the text in “Writing with Inform.”

Later, in a 2018 Medium story, she expanded on the interaction:

So I got Inform and I got the designer’s manual [for the older version of Inform] that explained how to use it. I taught myself to program in it and I got involved in the online community around Inform and published a few games. Then Graham Nelson, the creator of Inform, approached me for help with the new version, Inform 7, which was meant to be much easier to use for non-technical people. The result was that I got very involved helping with Inform 7’s design, documentation, and community management and that I also married Graham and moved to the UK.

There are numerous other acknowledgments, but the most striking to me is the acknowledgment of other IF system creators:

Special mentions to[…]my fellow authors of IF design systems - Mike Roberts (of the Text Adventure Development System); Kent Tessman (of Hugo); and Campbell Wild (of ADRIFT).

The next few sections are about making the IDE itself work. Section 1.3 on ‘Facing Pages’ reveals a little about the thought process behind the design:

On most computers, Inform runs in a single main window which is an opened book showing two facing pages.

Interesting that he conceives of the IDE itself as a book.

Section 1.4, the Go! button, includes the snippet that:

The keyboard shortcut Command-R (on Mac OS X), F5 (on Windows), or Ctrl-R (on Linux GNOME) has the same effect as clicking Go.

It also mentions that:

[Inform] needs at least one name of a location where the drama can unfold. For reasons of tradition, such locations are normally called “rooms”, though people have used them to represent anything from grassy fields to states of mind and other metaphorical places.

If I remember right, the term ‘rooms’ comes from Colossal Cave Adventure. That game used ‘rooms’ since that is the phrase that cavers use for a specific location in the cave (feel free to correct me!)

Section 1.5, The Replay button, offers no special insights.

Section 1.6, The Index and Results Panel, offers some helpful interpretation of the icons in the error messages:

The icon Reveal.png always denotes a reference to a particular line in the Source text, that is, to something written in the source: clicking it opens the Source panel and jumps to that position.

The icon Below.png indicates that more detailed information can be read further down the text in the same panel: clicking it jumps down to this more detailed report.

Lastly, the icon help.png hints that there is a relevant page of this manual: clicking this opens the Documentation panel and switches to it.

I’ve used the top icon quite a bit, but have never used the others. The ‘hints’ definitely sounds useful.

It also mentions the Index:

On the other hand, if the text was fully understood then another new panel will become available: the “Index”. This is a cross-referenced index of the source, or rather, of the interactive fiction which has been generated. The Index is only an optional convenience, but becomes more and more helpful as the fiction grows larger. Its exact format does not matter for now.

I didn’t use this much at the beginning, but now it’s invaluable. I use it because it auto-generates a map of the whole game, and because it lists every command that can be interpreted as an action, as well as every object and where they are located, among many other things.

The next section is pretty gnarly: 1.7 The Skein.

Inform’s Skein panel is just such a table, built automatically. If we think of the list of typed commands as a thread, then the skein is (as the name suggests) braided together from all these threads. In the display, time begins at the top, with the start knot, and the threads of different play-throughs hang downwards from it.

Double-clicking on a command translates the source afresh and replays the story from start down to that command, and then stops. We are then free to continue play by typing commands into the Story panel, of course, and these commands will automatically be recorded in the Skein as a new variation of play, diverging from the previous threads.

The skein is something I don’t always use, but it is useful. For a large game, the skein can become so complex as to be totally unmanageable, and I resort to testing commands. For smaller games, though, it works well.

For me, the worst thing about the skein (and replays) is when I save in the middle of it; then every replay opens the save window. Fortunately, in Windows, you can right click it and edit it.

But I suppose I’m not the only one who gets confused. The chapter ends with this note:

The user interface for the Skein looks slightly different on different versions of the Inform apps (that is, the MacOS version is not quite the same as the Windows version, and so on), so this manual is not the best place to describe it. In any case, the best way to find out about it is probably to experiment.

And that’s the end of Chapter 1. Hopefully we’ll get on to the fun programming part next!


I’ve thought of doing something like this if I need a year’s worth of material for Inform7Tips. (I’ve even rewritten some of the examples, cheeky bastard that I am.)


In the last few months, I keep finding things in the manual I never knew that would have helped me a lot. So I want to read it but find it difficult to wade through. Doing it publicly provides more motivation!

The thing that got me to do this was you and Hanon (I think) talking about using ‘has’ and ‘had’ for actions, like ‘if the box had been open…’.


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!