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

The rules often make it sound like scenery is a kind, but it’s an either/or property on things. For a long time, I thought there was a special case that allowed saying scenery instead of scenery thing.

The truth is weirder. For this code:

The Lab is a room. 
The scarf is a wearable.
The scarf is in the Lab.
Instead of taking a wearable, say noun.
To say (w - wearable): say "w [w]".
Test me with "take scarf".

test me will output “w scarf”.

Scenery has two properties: it doesn’t move and it isn’t described.

I will cavil that it is described inasmuch as if you asked if the gnarled old oak tree is described, the condition would be true. But there are a bunch of things in common between the consequences of something being scenery and it being undescribed.

1 Like

Wait, what’s the connection between this and scenery? This seems like it’s doing exactly what it’s been told to do: instead of taking the scarf, printing the letter w and then the name of the wearable thing. It may be that I haven’t learned the thing yet that makes this weird…

I went a long time without knowing that an adjective alone was a valid description of objects. And longer before I knew we could simply assert that a previously unnamed thing is some named attribute and, if that attribute unambiguously means some given kind, Inform will infer that it’s that kind. (We’re told that assertions with verbs meaning relations work that way.)

Like I said, I had thought it was a special case that allowed Shrub is a scenery, not a general principle.

I guess it’s only weird if one had assumed we couldn’t do these things.


What’s weird here is that you can use adjectives as nouns. “Scenery” sounds like a noun (a kind) but it’s actually an adjective (a property). English usually doesn’t do this, with a few exceptions, but Inform’s perfectly content with it.


Oh, that makes a ton of sense. I was confused by the ‘to say’ part because it was so unusual I thought it was the main focus of the example!

3.17 Men, women, and animals

Some people say that Inform reinforces a gender binary, but nothing could be further from the truth.

  • male/neuter
  • male/not neuter
  • female/neuter
  • female/not neuter.

Inform reinforces a gender quaternity!

3.18 Articles and proper names

Finally, we can override these settings, if they still come out not as we intend, by explicitly changing the either/or properties “singular-named” (vs “plural-named”) and “proper-named” (vs “improper-named”).

I think this shouldn’t be a “finally”. Excluding mention of those properties makes this more complicated than necessary. It presents “this object-creation syntax results in this user-facing behavior” and I think it’d be simpler and clearer (as well as more accurate) to explain that those attributes result in the various behaviors, and these different kinds of assertions result in things starting out with these combinations of attributes.

3.19 Carrying Capacity

These restrictions only apply to the player (and other in-world characters): as the omnipotent creators, we are not restrained by them.

How little consistency-checking the World Model has outside the context of actions could stand to get more of a spotlight somewhere.

3.22 Food

the player can EAT them. This will usually only consume the foodstuff in question, effectively destroying it

This is the only place in the Standard Rules where something is notionally destroyed (also the only place where the Standard Rules move something off-stage).

3.23 Parts of Things

I’m not sure it’s worth it to even mention parts this soon. But if we are to mention them, it would be worth highlighting from the start that parts may exist, but by default there’s no indication that they do. This means there’s no way for the player to find out about them except one you probably don’t want: for things the player hasn’t heard to appear in disambiguation messages… but a scope discussion should come later.

3.24 Concealment

there are times when we cannot go along with Inform’s normal assumption that all of a person’s possessions are visible to everybody else

First we’ve heard of this.

(A rule which says neither “yes” nor “no” will decide yes, but it’s best to spell out exactly what’s wanted.)

This isn’t true of rules in general. A for persuasion rule which says neither “yes” nor “no” will decide yes, because deciding the concealed possessions of something is an activity, and that’s true of activities’ for rulebooks.

Concealment seems somewhat complicated to go into at this point. But certainly there should be a discussion somewhere that compares and contrasts scenery, undescribed, and concealed. (I think this is as much documentation as we ever get on described.)

3.25 The location of something

The “location of” a door is its front side

…until such time as the player visits the room that’s the back side of the door. Like the other side of a door, its location of result is subject to change. Once the player has visited the room on one side of a door, its location can be said to be whichever side the player visited most recently. Or, independent of what the player has visited, we can always say that the location of a door is always the side that’s not the other side of the door.

a backdrop has no location

Not even going to try. Take it away, @DrPeterBatesUK : Spatial Relations Addendum.

Objects which are not things at all, such as rooms and directions, also have no location.

location of does return a value for rooms: a room’s location is itself. For directions, location of really does return nothing.

The idea of indirect containment is useful enough to have a name: Inform calls it “enclosure”. A thing encloses whatever is a part of itself, or inside itself, or on top of itself, and it also encloses anything that they enclose.

or that it wears, or that it carries. Or, for short, all the things it holds and the things they hold. “indirect containment” is a holdover from Inform 6. “indirect holding” would be a lot more meaningful. But the docs never mention the holding relation.

(The definition of the holder of phrase, when we get to it, does mention wearing and carrying but leaves out incorporation, which makes it easier to explain the first thing held by and next thing held after phrases which really do omit incorporation. These phrases have nothing to do with the holding relation per se and there’s no reason for them to be consistent with each other other than avoiding confusing authors.)

3.26 Direction

Representing Discworld directions seems a little abstruse for Chapter 3.

New directions must always be created in opposing pairs

There’s nothing enforcing that “must”. You can go ahead and define a singleton direction. Its opposite will be the default direction, i.e., north, the first one defined in the Standard Rules. If you think it’s silly to have two directions whose opposite is north, you could do:

Foo is a direction. The opposite of foo is foo.


Welcome back to…

Chapter 4 (Part 1)

This is a shorter chapter, so let’s go all out!

Section 41 is new kinds.

Every value has a kind. The kind of 10 is “number”; the kind of 11:30 PM is “time”; the kind of “jinxed wizards pluck ivy from my quilt” is “text”; and so on. The Kinds index panel shows the kinds present in the current Inform project, which will always include a wide range of built-in kinds, and usually also some new ones created in that project.

We mentioned kinds in the last chapter. Kinds are great; they’re pretty much the only way to make indistinguishable objects, but they’re also useful if you don’t want to repeat a lot of work. I made a ‘kind of room’ yesterday to for a vast underground lake that was a bunch of identical rooms in a row (I could have just used an ‘instead of going rule’ and a counter but this seemed more fun). I’ve also used kinds for the wax figures in my wax museum, for climbing rocks, spell scrolls, books, spears, and dancing silks.

Kinds can be ‘nested’:

For example, if we write:

Growler is an animal in the Savannah.

then Growler is an “animal”, which is a kind of “thing”, which is a kind of “object”. When we talk about “the” kind of Growler, we mean “animal”, the most specific one, but actually he belongs to all of those kinds.

Kinds are declared like so:

A Bengal tiger is a kind of animal.

Given that, we can then write:

Growler is a Bengal tiger in the Savannah.

Apparently you can also insert other kinds in between preexisting kinds, which kind of seems like bad praxis, but I do this with regions a lot so oh well.

That’s easy enough. Adding “mammal” now looks awkward, though, because it seems to belong in between the two. All Bengal tigers are mammals, but not all animals are. But Inform can sort this out:

A mammal is a kind of animal. A Bengal tiger is a kind of mammal.

If we look at the Kinds index, we should indeed see a hierarchy:

object > person > animal > mammal > Bengal tiger

Inform doesn’t have hardcoded scientific reasoning, so the documentation points out that it doesn’t know that a ‘man’ and a ‘woman’ are an animal, and it makes sense from a coding perspective because kinds are about what actions result from interacting with the object and not about what they inherently mean.

(There was a heavy simulationist school in the early 2000s that saw IF as a stepping school to better computer simulation and really wanted the computer to actually understand things, but I’m of the school that fooling the player into thinking the computer knows what it’s doing is just as good as it actually knowing.)

You can make new kinds of things, but can’t make new numbers. Instead, you make a new thing called a ‘value’, which we’ll talk about later.

Example 43 is about adding synonyms for an entire kind, which is precisely the main thing I use kinds for.

A cask is a kind of thing. A cask is always fixed in place. Understand "cask" or "barrel" as a cask. Understand "casks" or "barrels" as the plural of cask.

This is the true power of Inform (and similar high-end languages), the ability to type a few words and broadly affect dozens of objects. I love it.

Section 4.2 is ‘Using new kinds’.

This sections makes a kind of room (this is the exact example I looked up last night for my own game).

It adds a little tip about Inform not being a mind reader:

Inform often doesn’t mind in what order it is told about the world, but it may need to know the name of a kind before that kind can be used. For example,

A coffer is a kind of container. In the Crypt is an open coffer.

makes sense to Inform and results in the creation of a new thing, just called “coffer” in the absence of any other name to give it, whose kind is “coffer” and which is initially open. Whereas if Inform reads:

In the Crypt is an open coffer.

without knowing that “coffer” is a kind, it simply makes a thing called “open coffer” (and which is not a container).

Section 4.3 is Degrees of certainty. We can use the phrases ‘usually’ and ‘always’ or ‘seldom’ or ‘never’ to make broad statements. I don’t like to use ‘always’ or ‘never’, but I believe their primary purpose is to keep the author from accidentally making bad mistakes.

These words let you define global attributes for a whole kind:

A dead end is usually dark.


A dead end is always dark.

Both of these make all dead ends dark by default, but the second one throws an error if you happen to make one dead end lit, while the first will not throw an error.

Example 44 has some commentary on trends in IF (probably written over 15 years ago):

In recent years there has been a strong trend towards providing unique descriptions for all implemented objects. Often this is a good idea, but there are also contexts in which we may want to discourage the player from looking too closely at some things and concentrate his attention on just a few interesting ones.

This is pretty much requisite for all IF games now except for those that specifically eschew deep implementation (such as Arthur Di Bianca’s restricted verbset games).

This example shows how to assign a default description to a whole kind (in this case, ‘things’):
The description of a thing is usually "You give [the noun] a glance, but it is plainly beneath your attention."

Example 45 is ‘Something Narsty’, which defines a whole ‘kind’ of staircase:
A staircase is a kind of door. A staircase is always open. A staircase is never openable.

I do stuff like this too. In my current game, portals that are rips or tears in space open up inside a blowing-up space ship:
A space-tear is a kind of door. A space-tear is usually unopenable. A space-tear is usually open. Understand "tear" or "space" or "tear in space" or "rip" as a space-tear.

Section 4.4 is Plural assertions, which is a section I have purposely never read because it always looks intimidating, the first three or four lines don’t make it clear to me what a plural assertion is, and what I don’t know can’t hurt me.

But I have to bite the bullet.

Oh, apparently it’s just doing multiple things at once. That’s not scary!

It’s saying you can type
The high shelf and the skylight window are high-up fixtures in the Lumber Room.

instead of
he high shelf is a high-up fixture. The skylight window is a high-up fixture. The high shelf is in the Lumber Room. The skylight window is in the Lumber Room.

This is logical and I think I’ve used it before, but it would be convenient. Part of this is a subtle lie, Inform dressing up in a human-suit, since you don’t actually need the ‘s’ for this to compile (you can just say 'are high-up fixture in Lumber Room).

I have way too much redundant code, like this snippet in my game:
There is a tango climbing-rock. There is a romeo climbing-rock. There is an oscar climbing-rock. There is a uniform climbing-rock. There is a bravo climbing-rock. There is a lima climbing-rock. There is an echo climbing-rock. There is an alfa climbing-rock. There is a hotel climbing-rock. There is an india climbing-rock. There is a yankee climbing-rock. There is a sierra climbing-rock.

(if the samples of my code do not contribute to the post, please let me know!)

The section ends with this nugget:

Inform constructs plurals by a form of Conway’s pluralisation algorithm, which is quite good - for example, it gets oxen, geese (but mongooses), sheep, wildebeest, bream, vertebrae, quartos, wharves, phenomena, jackanapes and smallpox correct. But English is a very irregular language, and multiple-word nouns sometimes pluralise in unexpected ways. So we sometimes need to intervene:

A brother in law is a kind of man. The plural of brother in law is brothers in law.

One of the things no one can agree on in my church is on the proper plural of Book of Mormon. Is it Books of Mormon? Book of Mormons? The leadership mostly closed ranks to use ‘copies of the Book of Mormon’, so that’s where we’re at now.

Example 46, Get me to the Church on Time (oh maybe I saw that out of the corner of my eye and it reminded me of church) uses kinds of clothing to prevent people from wearing more than one pair of pants.

Instead of wearing a pair of pants when the player is wearing a pair of pants (called the wrong trousers):
    say "You'll have to take off [the wrong trousers] first."

This ‘called the’ thing really confused me for a long time. I never know when Inform will accept it and throw it in all sorts of places.

Section 4.5 is ‘Kinds of Value’. This is for things like numbers and texts.

This is something I have rarely used, but is very powerful. Here is an exapmle:

Brightness is a kind of value. The brightnesses are guttering, weak, radiant and blazing.

“Brightness” is now a kind of value on a par with (for instance) “number” or “text”. There are only four possible values, named as above. Kinds of value like this, where there are just a few named possibilities, are extremely useful, as we’ll see.

I just started using values in my current game. Here is an examples:

Nato-code is a kind of value. The nato-codes are Tango, Romeo, Oscar, Uniform, Bravo, Lima, Echo, Alfa, Hotel, India, Yankee, Sierra.

A climbing-rock has a nato-code. Understand the nato-code property as describing a climbing-rock. A climbing-rock is usually alfa.

There are also quantitative values, which I don’t really understand using since it’s just a number:

Weight is a kind of value. 1kg specifies a weight.

I usually just use ‘weight is a number that varies’ for stuff like this. Here’s Graham’s explanation:

The difference here is not the way we create the kind, but the way we tell Inform what the possible values are. Instead of a list, we teach Inform some notation. As a result, “26kg” is now a value, for instance. Quantitative kinds like this are sometimes called “units”, because - as in this example - they’re often units in the sense of measuring things. Many Inform projects never need units, but they can still be very useful, and they’re described in detail in the chapter on “Numbers and Equations”.

4.6 is Properties Again. Although the first thing it does is talk about relations:

Relations are really the central organising idea of Inform, and we’ve seen them many times already:

Growler is in the Savannah.

expresses a relation called “containment” between Growler and the Savannah. Much more about this in the chapter on Relations: for now, let’s go back to the simpler idea of properties.

The only new thing in this section is that the Kinds index in Inform lists useful things. I didn’t even know this existed! Let’s look at my kinds tab:

This is very useful! I only captured part of the index. Here is another segment with every column included:


The columns with checks are labelled ‘repeat’ for things you can repeat through, ‘props’ for things that can have properties, and ‘under’ for things that can be used in an ‘understand’ message.

The reason some things can’t have properties is that there are infinitely many of them (like numbers).

Section 4.7 is new either/or properties. Boy, I love these and use them all the time.

[E]very property must be created in a way which lays out what values are allowed to have it. The Standard Rules built into Inform say that

A thing can be fixed in place or portable.

We can make our own such properties.

To go back to our example “dead end” kind:

A dead end is either secret or ordinary.

This creates just one new property, not two. The names are taken as the two states of a single either/or property: secret means not ordinary, ordinary means not secret. Alternatively, we could just say:

A dead end can be secret.

in which case the opposite of “secret” would be “not secret”.

Now I could have sworn that you can’t make these properties for specific kinds; I swear when I do that I get an error and have to go back and make it a property of all things, which is annoying but I do it.

But looking back, it seems that was caused by me having typos in my kinds, so I’ve kind of been doing things wrong for a long time…

This is really messing with my head. My worldview is changed.

Single things can have either/or properties, which I have gotten to work before. Here is the example:

The umbrella is carried by the player. The umbrella can be open.

Example 47 is Change of Basis, which adds sleeping and waking states:

A person is either awake or asleep. A person is usually awake.

Is there a properties index in Inform? It’d be fun to see all of them laid out. But I don’t see one.

Section 4.8 is New Value Properties. This is where instead of ‘either/or’ properties, you attach things like texts or numbers.

This is just objects from OOP, where you can have an ‘object’ with associated functions and numbers and strings, but here the ‘object’ is a physical object. So like, Very Object Oriented Programming.

A dead end has some text called the river sound. The river sound of a dead end is usually "a faint whispering of running water". The Tortuous Alcove has river sound "a gurgle of running water".

This has inflexible ‘typing’ (is that the word?), so if you try to say something like:

The river sound of the Tortuous Alcove is 7.

…then Inform would object, because the number 7 is the wrong kind of value to go into the “river sound” property. If we need a numerical property, we can try this instead:

A dead end has a number called the difficulty rating. The Tortuous Alcove has difficulty rating 7.

You can establish defaults for value properties:
The river sound of a dead end is usually "a faint whispering of running water".

If you don’t provide a default, Inform will, usually a blank.

Example 48 is about giving flavor to things:

A food is a kind of thing that is edible. Food has some text called flavor. The flavor of food is usually “Tolerable.”

In my extension, Quips and Conversation, I give properties to conversation topics (called ‘quips’ in honor of Emily Shorts similar terminology):

A quip has an object called the target. The target of a quip is usually nothing.

A quip can be TargetGiven or MeihTarget. A quip is usually MeihTarget.

A quip has some text called TargetResponse. The TargetResponse of a quip is usually "You get no response." 

A quip has some text called TargetSummary. The TargetSummary of a quip is usually "You already tried talking about this."

Example 49 is Straw Boater, which gives ‘movement sounds’ to vehicles. It cleverly uses the fact that not setting a default for a text value will just print nothing, which honestly feels more like a bug exploit than a technique, since you could just explicitly set the default of your property to be nothing.

Section 4.9: using new kinds of values in properties. This combines value properties and assigning values to kinds. As an example:

Brightness is a kind of value. The brightnesses are guttering, weak, radiant and blazing.

The lantern has a brightness called the flame strength. The flame strength of the lantern is blazing.

What’s particularly nice is that we can now use the names of the possible brightnesses - “weak”, “blazing” and so on - as adjectives. Inform knows that “The lantern is blazing” must be talking about the brightness property, because “blazing” is a brightness.

A dead end is a kind of room with printed name "Dead End" and description "This is a dead end, where crags in the uneven rock are caught by the [brightness of the lantern] flame you hold aloft. Despite [river sound] there is no sign of the stream." A dead end is usually dark.

You can also assign properties to values:

A brightness can be adequate or inadequate. A brightness is usually adequate. Guttering is inadequate.

This is actually where my climbing rock example comes from. I wanted to make a bunch of identical rocks, each with a different letter of the nato alphabet on it. So I made nato-code into a kind and gave one to every rock, and added this line:
Understand the nato-code property as describing a climbing-rock. A climbing-rock is usually alfa.

So now if I say ‘there is a tango climbing-rock in ____’, then I can type in ‘X tango rock’ and get a response. It’s the perfect way to make a bunch of identical objects with slightly-different properties and honestly shows Inform’s power.

Finally, in this section, you can assign numerical values to your earlier text values:

Temperature is a kind of value. 100C specifies a temperature.

A brightness has a temperature. The temperature of a brightness is usually 700C. The temperature of blazing is 1400C. The temperature of radiant is 1100C.

The description of the lantern is "The lantern shines with a flame at [temperature of the brightness of the lantern]."

There are 4 examples in this section. To begin with we have Undertomb 1 and Undertomb 2, examples 50 and 51. The first adds ‘river sound’ to each room, while the second adds a brightness level to a lantern that decreases over time with some new code we haven’t seen before:

After waiting in the Tortuous Alcove when the brightness of the lantern is not guttering:
    now the lantern is the brightness before the brightness of the lantern;
    say "You wait so long that your lantern dims a bit."

So ‘the brightness before the brightness of the lantern’ is the new thing here.

I’ll admit, I generally just use numerical variables for this kind of thing. I have a lot of stuff like ‘pillar-level is 0’, ‘pillar-level is 1’. It’s functionally equivalent and often easier for me to read.

Example 52 is The Crane’s Leg 1. This is a very convoluted example where materials and numbers are assigned to everything, but each kind has an associated ‘ideal’ object which we can then imitate. It uses relations and is a lot to discuss right now so I won’t. If you like this kind of thing the Emily Short games Metamorphoses and Savoir Faire are really fun and pull these kinds of tricks all the time.

Example 53 is Signs and Portents, which adds ‘Destination’ as a value:

Destination is a kind of value. The destinations are London, Abingdon, Luton, Weston-super-Mare, Runnymede, Hell, and Low Noon.

and adds them to a signpost.

Section 4.10 is Conditions of things.

This is basically a way to define values by using wording similar to either/or properties:

The cask is either customs sealed, liable to tax or stolen goods.

Initially the cask will be “customs sealed”, the first value we gave. We could now write, for instance,

The description of the cask is "A well-caulked Spanish wine cask.
[if liable to tax] It really is a shame to have to pay duty on it!"

You can also do this for kinds:

Colour is a kind of value. The colours are red, green and white.
A colour can be bright, neutral or flat. Green is neutral.

Now in fact these properties are not anonymous: Inform has worked out names for them, even though we didn’t give any. The usual arrangement is that the name is the name of the object with the word “condition” tacked on: for instance, “cask condition”. So we could write:

The printed name of the cask is "wine cask ([cask condition])".

This kind of statement is the thing I ran fleeing from terror of in the past, but I have to post here, so let me puzzle it out. It seems like if you list more than two things in a ‘thing1 can be ____ or…’ statement, then instead of being an either/or property it reinterprets it to be:

thing1 has a [whatever our value is called] called thing1 condition.

If you do this again, the next one is called ‘thing1 condition 2’.

But, you can name it what you want as follows:

A fruit can be unripened, ripe, overripe, or mushy (this is its squishiness property).

And now the resulting property and kind of value would be called “squishiness”.

This is the kind of thing that makes my head hurt. I’d much rather just stick to text properties and numerical properties for most of this kind of thing. Like just saying:

A fruit has some text called the ripeness. The ripeness of a fruit is usually "unripened".

And then do a bunch of if statements, which you’d have to do with values anyway.

Section 4.11 is default values of kinds, which are always useful. The default of texts is “”, the default of numbers is 0, and so on. Defaults are listed in the kinds index I screenshotted above.

You can only assign defaults to things that exist in the world, so you can’t say ‘default value of vehicle’ if the game has no vehicles.

4.12 is values that vary. This is just creating variables instead of hardcoded properties. Most of my values vary. You can code this in three ways:

The right way (my name for it):
The prevailing wind is a direction that varies. The prevailing wind is southwest.

The wrong way (my name for it):
The prevailing wind is a direction variable. The prevailing wind is southwest.

or the “smooth, but going to cause you problems later debugging your code” way:
The prevailing wind is initially southwest.

Apparently you are not required to specify what value a variable starts with, which is something I always thought would make my computer explode. If you don’t specify, it just starts at the default (which is 0 for numbers).

We can have variables of any of the kinds of value, including new ones, but should watch out for a potential error. If we write:

The receptacle is a container that varies.

in a world which has no containers at all, Inform will object, because it will be unable to put any initial value into the receptacle variable.

As a final note on kinds, when Inform reads something like this:

Peter is a man. The accursed one is initially Peter.

it has to make a decision about the kind of “accursed one”. Peter is a “man”, so that seems like the right answer, but Inform wants to play safe in case the variable later needs to change to a woman called Jane, say, or even a black hat. So Inform in fact creates “accursed one” as an object that varies, not a man that varies, to give us the maximum freedom to use it. If we don’t want that then we can override it:

Peter is a man. The accursed one is initially Peter.
The accursed one is a man that varies.

In this way, Inform is a lot like GPT. Both are marvelous and easy for people bad in certain areas like writing and drawing because it can guess what you want and fill it in. They also are very frustrating and hard to master for very technical and experienced users because it can guess what you want and fill it in.

Example 54 is Real Adventurers Need No Help, which lets you turn off hints.

A permission is a kind of value. The permissions are allowed and denied.

Hint usage is a permission that varies. Hint usage is allowed.
Check asking for help for the first time:
    say "Sometimes the temptation to rely on hints becomes overwhelming, and you may prefer to turn off hints now. If you do so, your further requests for guidance will be unavailing. Turn off hints? >";
    if player consents:
        now hint usage is denied;
        say "[line break]Truly, a real adventurer does not need hints." instead.

Section 4.12 is Values that never vary (is this just global variables/constants? This is my first time hearing any of this).

Rather than typing “55” (say) every time it comes up, we might prefer to write:

The speed limit is always 55.

at the start of the source text, and then talk about “the speed limit” every time we would otherwise have typed “55”.

Yeah, isn’t this just magic numbers/global constants? I’m going to google ‘programming magic numbers’ and see what comes up.

Oh, looking it up says this is the opposite of magic numbers, and that this is a very good thing. Magic numbers are where random numbers appear in your code for no reason, while the preferred practice is giving them names. Which is what this section teaches.

We just use the word always:

The speed limit is always 55.

and use that throughout the code:

if the speed is greater than the speed limit, ...

and this allows us to make changes everywhere by changing that initial line:

The speed limit is always 70.

Hmm, this fixes a little problem I was having, and I just went through and replaced a common thing I use in my code with a global constant.

This section ends with a statement that I can’t really parse. It says:

“Speed limit” is then a number constant. Any attempt to set this elsewhere, or change its value, will result in a Problem message,
(so far this makes sense)
and moreover it can be used in contexts where only constant values are allowed. For example,

The generic male appearance is always "He is a dude."

Trevor is a man. The description of Trevor is the generic male appearance.

means that the SHOWME TREVOR testing command produces, among other data:

description: "He is a dude."

Can anyone explain this to me? Which part of this only works for constant values, and would fail if replaced with a variable value?

Anyway, Section 4.14 is Duplicates. This is useful when you want multiple indistinguishable copies of something, but that is almost always annoying. (There are some typical ‘help’ questions that people ask on here that almost always make me think ‘that game will not be fun and/or the author probably won’t finish it’. Those include inventory limits, implementing toilets, making realistic elevators, and making indistinguishable objects. Then there are ‘I will almost certainly not play that game unless forced to’, which are when people ask about real-time events in Inform, timed text in Twine, or preventing UNDO use. I’ve found great games that break all of those above rules so they’re not real).

All you need is to define a kind and then declare multiple of it.


A square is a kind of thing. In the Lab are two squares.

(This is a simplified example of the manual example, which used nested kinds).

You can’t make more than 100 duplicates of something due to memory issues.

Using too many duplicates can also clog up other inform functions:

If there are very many items in the same place, commands like TAKE ALL and DROP ALL may mysteriously not quite deal with all of them - this is because the parser, the run-time program which deciphers typed commands, has only limited memory to hold the possibilities. It can be raised with a use option like so:

Use maximum things understood at once of at least 200.

(The default is, as above, 100. Note the “at least”.)

There is a caution about a bizarre event that can occur:

Thirdly, note that Inform’s idea of “identical” is based on what the player could type in a command to distinguish things. In a few cases this can make items unexpectedly identical. For example:

The Lab is a room. A chemical is a kind of thing. Some polyethylene and polyethylene-terephthalate are chemicals in the Lab.

results surprisingly in “You can see two chemicals here”, because the run-time system truncates the words that are typed - POLYETHYLENE and POLYETHYLENE-TEREPHTHALATE look like the same word in a typed command. So Inform decides that these are indistinguishable chemicals. Typically words are truncated after 9 letters, though (unless the Glulx setting is used) punctuation inside a word, such as an apostrophe, can make this happen earlier.

Example 55, Early Childhood, has multiple blocks that can be repainted. It starts with kinds ‘red block’ and ‘blue block’, but kinds can’t be changed in gameplay, so it switches to using properties:

The colours are red, blue and green. A block is a kind of thing. A block has a colour. A block is usually blue

Then it goes to adding a way to print the color of a block:

Before printing the name of a block: say "[colour] ". Before printing the plural name of a block: say "[colour] ".

(This is code I’ve directly copied in my project from this example before).

Finally it adds a way for the user to type the color and have it recognized:

Understand the colour property as describing a block.

This is a vital thing that I think ought to have been in the main text. Quite a lot of good stuff is hidden in the examples.

(To be continued: I exceeded the page limit)


Chapter 4 (Part 2)

Section 4.15 is Assemblies and Body Parts, another section I’ve run my eyes over several times before without processing anything.

Apparently it’s just saying that you can make two kinds of things and then assign one or more of the first kind be part of or inside all of the second kind, like so:

A silver coin is a kind of thing. A banking room is a kind of room. Five silver coins are in every banking room.

This works for body parts (which I am always loathe to implement, and which are another red flag to me personally when new players ask about them):

A nose is a kind of thing. A nose is part of every person.

This can cause problems:

This works:

Cleopatra is a woman in Alexandria. The player is Cleopatra.
A nose is a kind of thing. A nose is part of every person.

but if those lines are in reverse order then Cleopatra’s nose is assembled before she becomes the player, with the result that it ends up called “Cleopatra’s nose” rather than “your nose” in play - which is very regal but probably not what we want. To avoid this, settle the player’s identity early on in the source text.

You can also make assemblies of values and relations in general using relation verbs (a later topic):

A colour is a kind of value. The colours are red, green and blue.

Liking relates various people to various colours. The verb to like means the liking relation.

Every person likes a colour.

Although I don’t see any difference between the fancy text above and just plain old:

A person has some text called the favorite-colour.

or even

A colour is a kind of value. The colours are red, green and blue.

A person has a colour called the favourite-colour.

Four examples again!

Example 56 just adds a kind called jacket which always has a container called the pocket that is part of it:

A jacket is a kind of thing. A jacket is always wearable.

A pocket is a kind of container. A pocket is part of every jacket. The carrying capacity of a pocket is always 2.

Example 57 is Model Shop, and gives every device in the game an on/off button, which is honestly an excellent idea (I had so many devices in my game I stopped adding buttons because it was so tedious. So there’s a gold forge, a magnet, and a microscope that can all be switched on with no explanation of how this is achieved). Anyway, here is part of the example:

An on/off button is a kind of thing.

Instead of pushing an on/off button which is part of a switched off device (called the machine):
try switching on the machine.

There are a few more rules like that and then:
One on/off button is part of every device.

Example 58 is U-Stor-It. This adds chests to the game which are containers, but have supporter lids (this is great! I’ve run into trouble with devices that are also containers and supporters, like the above-named Gold forge. I probably won’t change what I already have, though).

A chest is a kind of container. A chest is always openable. A chest is usually fixed in place. A chest is usually closed. The specification of a chest is "Represents a container with a separately implemented lid; the lid is itself a supporter."

A lid is a kind of supporter. A lid is part of every chest. The specification of a lid is "A supporter attached to a chest, which can only support things when the chest is closed."

There are then a bunch of rules for putting stuff in and looking under and so on.

Example 59 relies on some complex shenanigans to disambiguate whose nose to look at. It includes such hits as:
Definition: a thing is selfish if it is part of the player and the player can see an other person.
Does the player mean doing something when the noun is a selfish nose or the second noun is a selfish nose: it is very unlikely.


Rule for writing a paragraph about Rudolph:
    say "The reindeer are already harnessed and waiting impatiently. The brilliance of [Rudolph]'s nose casts an eerie red glow over [the list of unmentioned animals in the location]."

if that sounds exciting (the last part is cool to me).

Section 4.16 is Names made in assembly.
It explains how things that are part of every person or thing are named:

For example:

A nose is a kind of thing. A nose is part of every person. Antony and Cleopatra are people.

might result in the creation of “Antony’s nose”, part of Antony, and “Cleopatra’s nose”, part of Cleopatra. In this way, Inform names the noses after their owners. It will always do this unless there are multiple indistinguishable things being created, as in the “five silver coins are in every banking room” example: those will all just be called “silver coin”.

A small pitfall of this is that if we write:

Marcus Tullius Cicero is a person.

then although “Marcus Tullius Cicero’s nose” and “Cicero’s nose” are both valid names for the consular nose, “Marcus’s nose” is not.

I suspect the last part is because it thinks the first few words are adjectives, since ‘the nose of a small ent’ would not logically be called ‘small’s nose’. But IDK the reasoning.

There is then a highly technical explanation of the naming conventions which I invite the reader to peruse themselves. It’s only likely to come up if you’re making a highly systematized game where many objects have many identical parts.

Section 4.17 is the finale, which is pretty self-explanatory and short:

That concludes our tour through the design of the initial state of a simulated world. We have seen how to create rooms and to stock them with containers, supporters, devices, doors, men and women. The player of such a simulation can explore, move things around, open and close certain doors and containers, lock or unlock them provided a suitable key is found, switch machines on or off, and so on.

But that is about all. There is as yet no element of surprise, no aim or sense of progress to be earned, and no narrative thread. We have painted the backcloth, and laid out the properties, but the actors have yet to take the stage.

For my own postscript, I’d like to mention why people asking about implementing toilets (for example) is a red flag.

Specifically, if they want a toilet to work the way that you’d expect it to.

It’s because if the toilet does nothing special (doesn’t trigger events or have any secrets, etc.), then you’re spending a lot of your time and a lot of the player’s time on something that doesn’t advance the plot, solve puzzles, or offer anything of interest. If you were asking how to make a cool toilet, that is different, but a standard toilet that does nothing surprising shows that you believe a good author is one who makes a simulationist world that does exactly what is expected, while I contend that what makes a good game is doing what is not expected. Ryan Veeder likes to deeply implement unimportant or non-plot-necessary things, but it’s always really weird things, like the ice cream store in Taco Fiction. That’s cool.

The standard weight is initially 10.
A thing has a number called weight.
The weight of a thing is usually the standard weight.

Inform won’t like this. You can’t assert things (like “usually” here) using a variable, because what should happen if that variable changes later? Assertions happen at compile time, and changing variables happens at runtime, so whatever you’re intending here almost certainly won’t work.

But if the standard weight is a constant, then it’s fine: you’ve acknowledged that this isn’t something you can meaningfully change later.

They’re under “kinds” since properties don’t exist independently of the kinds that own them.

With the relation, you can ask Inform to give you “a random person who likes red” or “the number of people who like blue”.


Oh, right! Zarf helped me with something like that recently where I wanted to make a list of things that all shared the same value for a property, and this was the only way to do it. My brain just didn’t make the connection here. (Here’s a truncated version of the code I use now that I got help on, for posterity):

The verb to rockheighten means the rockheight property.

The description of the climbing-wall is "The climbing wall isn't exceptionally large, which is reassuring, since there isn't any safety equipment that you can see. It has a series of protruding rocks, each with a different word on it. 

At the bottom are [a list of climbing-rocks which rockheighten 1]." 

A climbing-rock is a kind of thing. A climbing-rock has a number called the rockheight. The rockheight of a climbing-rock is usually 0.
1 Like

I think it’s:

(called the […] occurs in:

  • definitions: Definition: a person (called the [...]
  • rules: After unlocking a door (called the newly-unlocked) with something (called the key):
  • relation declarations:
    • Contact relates a thing (called X) to a thing (called Y) when X is part of Y or Y is part of X.
    • Marriage relates one person to another (called the spouse).
    • Pet-ownership relates various animals to one person (called the owner).
  • conditionals:
    • if the player carries a lit thing (called the illuminator):
    • while the holder of p is a container (called the encloser):
  • assemblies:
    • A person (called its fan) likes every colour.
    • Every person likes a colour (called its favourite colour).

whereas (X - description of objects) occurs in To-phrases, nothin’ but to-phrases.

1 Like

Conditions are just anonymous enumerated kind of value properties.

A fruit can be unripened, ripe, overripe, or mushy (this is its squishiness property).

gets you exactly the same results as:

Squishiness is a kind of value.
The squishinesses are unripened, ripe, overripe, or mushy. 
A fruit has a squishiness.

And, of course, other things could have squishinesses.

An idea is a kind of thing. An idea has a squishiness.

Including (this is its squishiness property) is completely optional; it just gives it a better name than the default. One could do:

A fruit can be unripened, ripe, overripe, or mushy.
An idea is a kind of thing.
An idea has a fruit condition.

The killer feature of conditions, aka anonymous kinds of value, is that they make adjectives. This is the big advantage over text or number properties. Having done the above, you can do, e.g.,

let x be a random unripe fruit;
if the player carries a ripe fruit: [...]
repeat with f running through the overripe fruits: [...]

It’s a singularly terrible example. It’s not the case that a constant value is required for a description property. It’d be really nice if the docs didn’t have pronouncements like “contexts where only constant values are allowed” when that’s the only time “contexts where only constant values are allowed” is mentioned.

I do know one example. Assertions (all the statements outside of code blocks like rules or to-phrase declarations) can’t deal with anything dynamic: they’re about creating the world’s static opening condition. And so, you could say:

xyz is always "xyz".
abc is initially xyz.

but if you say:

xyz is initially "xyz".
abc is a text that varies.
abc is initially xyz.

You’ll get

The sentence ‘abc is initially xyz’ (line 5) tells me that ‘abc’, which should be a text that varies, is to have an initial value equal to ‘xyz’, which in turn is a text that varies. At the start of play, variable values have to be set equal to definite constants, so this is not allowed.

[ oops, missed that Daniel already covered that…]

[also, oops, it’s not as terrible as I thought; it just doesn’t make its point that clearly.]

The generic male appearance is a text that varies.
The generic male appearance  is initially "He is a dude."
Trevor is a man. The description of Trevor is the generic male appearance.

will trigger the same error.


It gets worse. I7-2296: things being privately-named causing their printed names not to be used in room description

Lab is a room.
A thing is usually privately-named.
The box is in lab. 
The toy is in lab. 

results in “You can see two here.”

lab is a room.
A thing is usually privately-named.
alice is a woman in lab.
consuela is a woman in lab.
box is a thing in the lab.

results in “You can see three women here.”

Inform’s idea of “identical” is based on what the player could type in a command to distinguish things

applies even to things that don’t have a name the parser recognizes at all.

A colour is a kind of value. The colours are red, green and blue.

Liking relates various people to various colours.
The verb to like means the liking relation.

Every person likes a colour.

Assembly assertions create new objects or values. That’s useful for the body parts case 'cause you really do want a one-to-one ratio of people to noses. The text explains that Every person likes a color. results in new colors being created on a per-person basis: if Alice and Bob are other people, now there are 6 colors: red, green, blue, your color, Alice’s color, Bob’s color. And A person likes every color. results in 3 new identical (but for their relation to color) persons being created, similar to what you’d get with There are three people. (If you include both lines, compilation fails.)

I’m hard-pressed to think of a use for Every person likes a color.. I can imagine a use for A person likes every color. because you could reassign everything about those new people objects.

The potentially big value of the liking relation above compared to a property is that liking relates various people to various colors. People don’t have to choose just one!

If one really did want just one liked color per person then

A person has a color.
The verb to like means the color property.

would allow most of the same options in terms of working with people and colors.


I’m enjoying seeing them, it’s cool to compare implementation notes!

Ha, that’s actually genius.

Oh that’s funny, I was just looking over the code for my first game in preparation for releasing it on Source Code Amnesty Day, and saw some uncharacteristically well-implemented rules to prevent the player wearing multiple copies of one article of clothing – which I now realize I must have lifted directly from this example!

Oh wow, not knowing this seems like it’d make things super hard and or annoying! The sailboat race that I implemented in my second game really relies on this feature of Inform, since there are three boats that all have a bunch of shared properties that need to get compared (heading, place in the race, stage in the course, speed…).

I do too – though again, since I’ve been reviewing old source code in the last couple days, I have to say that I’m having a hard time remembering what all those numbers are meant to represent!

I just read this one over and now want to make a game about Platonic Ideals :slight_smile:

Huh, I’ve also done this sort of thing – after I had to make some changes to rebalance an initial “magic numbers” implementation of the sailboat race, I redid the code to refer to a couple variables (like leg length, wind speed, etc.) that I could then tweak more easily. But I think I did that with just regular variables, not constants.

Oh lord, can confirm – the climactic puzzle of my first game involves hiding ten indistinguishable objects (more or less) in different places in a room, and it was a giant bear to get working (still doesn’t 100%, in fact).

(I think I’ve avoided everything else on your two lists, though!)

Oh, this solves a mystery! Late in my Cragne Manor run, I noticed that I’d have to type DROP ALL and TAKE ALL more than once to get the desired behavior, so this must have been what was going on (admittedly, I was a giant pack rat in that game).

Wait, is that really only in the examples? That’s such a critical thing to be able to do!

Oops, I’ve done this too :slight_smile: Admittedly my first game had a couple puzzles that specifically turned on eyes, noses, etc.

I’ve found this basic approach, of getting around multiple-inheritance issues by just crowbarring two different things together by making one a part of the other and using Understand commands to make this invisible to the player, really easy and useful (as with 99% of the Inform techniques I like, it’s kind of a godawful kludge).

I’ve never met Graham Nelson, but many of these examples strike me as very Graham-Nelsonish, and I find them delightful (the bit about Cleopatra’s nose also qualifies).


Hmmm, ten indistinguishable objects, body parts, Mike’s game…


Er, I was thinking more of the nose and eyes and such, not that body part, but fair cop!

It does have its own subchapter, 17.15. Understanding things by their properties.
But I agree that it could have been mentioned in the main text of 4.14 already, too, and that there are generally some important things which are a bit hidden in the examples.

1 Like

I do like avoiding giving a property to everything if not everything needs it. But when being selective like this, you also have to be careful to avoid runtime errors.

The advantage of everything having property A is that anything can be checked for property A.

If you only let, say, waterfalls have property A, and somewhere in the game you have code that checks the value of a thing’s property A without first checking that it’s a waterfall, you’ll get a runtime error, and you might not know about it for some time (or when the game’s released) if you’re unlucky.



if you want non-standard directions, ALAN 3 is the language of choice, adding new direction is very simple, if not even elementary.

1 Like