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

Playing IF Reviews and Essays
21

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:
open/closed
transparent/opaque
openable/unopenable
fixed in place/portable
enterable/?

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!

5 Likes
22

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.

6 Likes
23

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:

Use DICT_WORD_SIZE of 12.

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.

3 Likes
24

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!

3 Likes
25

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.

2 Likes
26

This is a good thread. Thanks for taking this on. I’m already learning lots of little bits I never took any notice of before.

I only ever complain about the Inform 7 docs when I post here, so here’s something that makes them really good: I love the examples. It would have been enough for them to show only the most basic cookbook code, but they’re all little works of art in their own right. Emily Short and the other example writers must have taken a lot of pride in them.

I want to post Up and Up by itself here, because this is one of the examples that really stuck with me, for whatever reason:

“Up and Up”

The Plain of the Skull is below the Endless Tower. The description of the Plain of the Skull is “A vast and trackless plain, enlivened only by the bones of those who have previously tried and failed to cross. Above you is the Endless Tower, which rises half-way to the moon.”

The description of the Endless Tower is “From up here the Plain of the Skull seems only a small bald patch: the world is round and most of it is covered with trees. Far off to the southwest is a shimmering surface that might be water; but there are no signs of cities or civilizations, only the lizard-skeletons.”

[And now we borrow from the instructions on Actions to create our actual message. “Before…” introduces a rule that occurs when the player tries to do something; in this case, we will make a Before rule for going to the tower.]

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…”

The player carries a bit of harness. The description of the harness is “A strip of worked leather and a loop of metal, scavenged from one of the skeletons on the plain. Without it, you might think your entire quest was in vain.”

Test me with “look / up”.

5 Likes
27

I find using both ways is good for organising the source to follow my thinking. A bunch of synonyms for one way of addressing the thing can go together with slashes in one set of inverted commas. Then some separate, odd-man-out ways can go on their own after commas.

Yeah. I’d have to say, these movement loopholes/overlaps are the most common bug that will sneak through into a game of mine. One of the loopholes messed up a ‘do or die’ moment in my room in Cragne Manor. Then I fixed it. Then the overseers tried to add an emergency TAKE BACK mechanism to my do-or-die moment in case players didn’t have UNDO, and I think their addition also fell foul of the existence of in/out/exit-type loopholes, and so even the TAKE BACK isn’t guaranteed to work, as I understand it.

-Wade

4 Likes
28

I wonder how many used it even back in the Infocom days. In a game like Zork I, I definitely wouldn’t even think of using it until I had dealt with the thief, because in addition to suppressing the room description it also doesn’t list the objects in the room.

And at least Cutthroats has bugs that only happen in superbrief mode. The easiest one to reproduce is to go to Red Boar Inn and wait for the Weasel to search your room (that you left unlocked). If you go back to your room while he’s there, he should kill you as soon as you enter. But if you do it in superbrief mode, he won’t.

5 Likes
29

Chapter 3 Continued (3.8-3.26)

Chapter 3.8 is Scenery! ‘Scenery’ has to be one of the most common words in my code outside of standard English words like the/of/a/etc.

Any thing can be scenery, and this does not bar it from playing a part in the story: it simply means that it will be immobile and that it will not be described independently of its room. Being immobile, scenery should not be used for portable objects that are meant to be left out of the room description.

Pretty much everything in a room that isn’t takable ought to be scenery.

This can cause some problems if you have some very dense room descriptions. This is especially bad when people are modeling their actual kitchen and include every appliance, every cupboard, etc.

Ryan Veeder has a great way of writing strong room descriptions with few objects in it, and even has a great blog post about it.

Scenery has two properties: it doesn’t move and it isn’t described. You can make something immovable but still described by calling it ‘not portable’ or, I think, ‘fixed in place’, but I’ve often wished for the opposite: a word for something takeable, but not described, at least temporarily.

An interesting side bit of trivia:

If a supporter is scenery, it may still be mentioned in the room description after all, but only as part of a paragraph about other items, such as

On the teak table are a candlestick and a copy of the Financial Times.

The first example in this sections is Disenchantment Bay 2.0. It gives an example of just adding everything in the room description as scenery:
“Some navigational instruments, some scratched windows, a sign, a radar display, and some radios are scenery in the cabin.”

I personally have my own little template, which is
____ is scenery/a thing/etc. in _______. The printed name of ______ is _____. Understand ____ or _____ or ____ as _____. The description of _____ is _____.

Someone upthread posted a similar template but it includes “instead of doing anything with _____ instead of examining it”. That would probably improve my games, to be honest, but I’m not sure that a single catchall can work for things as disparate as ‘listen to’ or ‘push’ or ‘search’, especially if writing different catchalls for all things. But I guess that’s what testers are for, is seeing what responses don’t make sense. (Thanks testers!)

Example 16 is Replanting, which has an interesting rule:

The Orchard is a room. "Within this quadrille of pear trees, a single gnarled old oak remains as a memory of centuries past." The gnarled old oak tree is scenery in the Orchard.

Instead of taking some scenery: say "You lack the hulk-like strength."

This is an example of a custom ‘can’t take that message’ for the tree, which really is vital for most scenery; I have a lot of these in my code. But what’s interesting is the way it’s phrased:
Instead of taking some scenery: say "You lack the hulk-like strength."

I didn’t know you could write it like that, but I guess it should make sense. I suspect inform ignores ‘some’ or ‘a’ when processing this type of command, and just treats scenery as the kind it is, so this is basically like saying ‘instead of taking scenery’.

Section 3.9 is backdrops! Backdrops are scenery that appears in multiple rooms, such as the sky in an outdoor game or the floor in a spacestation.

A backdrop can be placed in a region or a room. This is one reason regions are nice, you can just apply a global change to everything.

You can also do this apparently:

The special place “everywhere” can be given as the location of a backdrop to make it omnipresent:

The sky is a backdrop. The sky is everywhere.

Behind the scenes, backdrops are just a single object that gets physically moved from room to room (I think infocom games did that and it got copied here?)

Disenchantment Bay is again an example here, with a glacier added as a backdrop (although since this is currently a one-room game, it doesn’t do much).

I have a way of classifying actions in my game as ‘physicality’, like ‘touching is physicality’. And then if something is far-off, I say:

Instead of phsyicality when the noun is a distant thing:
    say "That's too far away!"

with similar rules for immaterial things.

3.10 is properties holding text.

So instead of being either/or properties like open or closed, you can have properties of a room with text in them.

This is, in a way, Object-oriented programming (with literal objects!) as you can take an object and associate whatever you want with it.

For now, we only mention descriptions, but I usually have a lot of text. For instance, copying Emily Short, in my game conversational topics are called ‘Quips’, and I have a ‘preview’ for each quip as well as a ‘response’ for each quip.

Anyway, for room descriptions, you can write them in three ways. The first two are sensible:

The Painted Room is north of the Undertomb. The description is "...

or

The Painted Room is north of the Undertomb. The description of the Painted Room is "...

But the weird way (and the one that was used in games I learned from) is:

The Painted Room is north of the Undertomb. "This...

So you just put some quotes and start typing. Pretty neat.

3.11 is two descriptions of things. This one really threw me for a loop when I first started coding.

All the example games use the same trick as in 3.10 for objects, so like

There is a leaf in Mudland. "A leaf has fallen, out of season, lying in the mud."

But this isn’t the description of the object, which is a separate thing you set by saying The Description of the object is ".... Instead, this determines what people see when they run into the object, instead of ‘You see a leaf here.’

So this works great, but when I later wanted to modify it, I had no idea how to!

It urns out, this thing is actually a property called ‘the initial appearance’.

It’s used when something has not been ‘handled’, which is Inform’s word for ever taken. I didn’t know Inform’s word for it, so my current game coded something called ‘onceTaken’ which is functionally identical.

Disenchantment bay now adds tons of descriptions of everything in this example.

A new example, Laura, teaches multiple things not mentioned in the section above.

First is that Inform might parser ‘and’ or ‘with’ in names as code, which can mess things up, so you can fix that as follows:

Often it is enough to preface these ambiguously-titled things with “a thing called…” or “a supporter called…” or the like, as here:

South of Spring Rolls is a room called Hot and Sour Soup.

prevents Inform from trying to read “Hot and Sour Soup” as two separate rooms, while

The player carries an orange ticket. The player carries a thing called an orange.

creates two objects instead of the one orange ticket that would result if the second sentence were merely “The player carries an orange.”

It then mentions we can instead just set the printed name property. I do that for everything in my game; with 10 sub-games, there’s so much overlap that I have to name them weird things with hyphens in it and then change the printed name. For instance, I have a wax statue of the pharaoh Khufu in one sub-game and a mummy pharaoh in another.

Here’s the example:
The City of Angels is a room. The incriminating photograph is carried by the player. The printed name of the incriminating photograph is "incriminating photograph of a woman with blonde hair".

Understand "woman" or "with" or "blonde" or "hair" or "of" or "a" as the incriminating photograph.

Now I actually don’t like the ‘of’ thing here. As the book says,

in the case there were two items with “of” names, the game would disambiguate with a question such as “Which do you mean, the incriminating photograph of a woman with blonde hair or the essence of wormwood?”

What I like to do is to combine ‘of’ with one of the words. So if there is a ‘box of gold’, I’ll say:

Understand "box" or "box of " or "gold" as the box of gold.

That way, it’ll only recognize ‘of’ as the box if people are specifically typing ‘box of gold’.

There is a pitfall to the ‘understand’ method:

[I]f we specify a whole phrase as the name of something, all the words in that phrase are required, in the order given. Thus “Understand “blonde hair” as the photograph” would require that both “blonde” and “hair” be present, and would not recognize >X BLONDE, >X HAIR BLONDE, or >X HAIR.

New authors make this mistake all the time, and unfortunately so do I. If you’re playing an Inform game and see a ‘blue chest’ and type X CHEST and don’t get a response, they probably made this mistake.

For some real advanced understanding, the author provides this:

We can create tokens, such as "Understand “blonde hair” or “hair” as “[hair]”, and then use these tokens in match phrases. This saves a good deal of time when we want to specify a number of different but fussy alternatives. So, for instance, here is a drawing that would not respond to >X OF, or >X BROWN EYES, but would respond to >X DRAWING OF MAN WITH BROWN EYES, >X MAN WITH BROWN EYES, and so on:

The drawing is carried by the player. The printed name of the drawing is "drawing of a man with brown eyes".

Understand "eyes" or "brown eyes" as "[brown eyes]". Understand "man" or "man with [brown eyes]" or "brown-eyed man" as "[man]". Understand "[man]" or "drawing of [man]" or "drawing of a [man]" as the drawing.

Section 3.12 is Doors! Useful but complicated.

Doors go between rooms:
The heavy iron grating is east of the Orchard and west of the Undertomb. The grating is a door.

The standard for doors is:

In the absence of any other instruction, a newly created door will be fixed in place, closed and openable.

If you use doors like this, you don’t include any connection directly between rooms, just the door itself.

Amusingly, this section borrows the name of its example rooms from Ursula Le Guin’s book ‘The Tombs of Atuan’, an excellent book I read for the first time last year:

The red rock stair is east of the Orchard and above the Undertomb. The stair is an open door. The stair is not openable.

In this example, we’ve made a stairway into a door. This is convenient; anything that people might enter or interact with assuming it will lead them to another room makes a good door.

Apparently there are also one-sided doors (which is great for me because I want one coming out of my Graveyard in my game):

The blue door is a door. It is south of Notting Hill. Through it is the Flat Landing.

(I’m literally copying this into my game as I write this).

Doors have front sides and back sides (apparently!) and this is put in the special ‘important boxed format’ of the manual, which I think is the first appearance of this format (here is a picture of the special box, for those using screen readers):
image

So the front side of a door is the first room in the code, and the back side of a door is the second room in the code (I presume we mean here the first room in specifically the declaration of the door, not the room of the two which is first mentioned in the source text at all).

A classier way to handle it is ‘other side of the door from _____’. In the examples given, this works if the blank is a room, but it also mentions the word ‘object’, so maybe you can type anything there?

with some experimentation in a sandbox game, it seems it only works for rooms, not objects.

Similarly, we can extract the direction of (door) from (room)

We have disenchantment bay again, this time simply adding a new door and a new room: the deck. This automatically places the glacier backdrop in the deck.

Example 21 is Escape, which introduces a window which serves both as a door and as a way to see the other side:

Instead of searching the window:
    say "Through the window, you make out [the other side of the window]."

Example 22, Garibaldi 1, gives you a machine that prints out the status of every door in the game and which rooms it connects:

The security readout is a device. The description of the readout is "The screen is blank."

Instead of examining the switched on security readout:
    say "The screen reads: [fixed letter spacing]";
    say line break;
    repeat with item running through doors:
        say line break;
        say " [item] ([front side of the item]/[back side of the item]): [if the item is locked]LOCKED[otherwise]UNLOCKED[end if]";
    say variable letter spacing;
    say paragraph break.

This could be really useful for debugging a door-heavy game!

Next is locks and keys. I highly recommend using Locksmith for any game with a bunch of locks and keys in it.

Here are three ways to match keys to doors:

It seems unwise for a door in Notting Hill to be unlocked, so:

The blue door is lockable and locked. The matching key of the blue door is the brass Yale key.

Since the second sentence here is a little clumsy, we can equivalently say

The brass Yale key unlocks the blue door.

Yet a third way to say this is:

The blue door has matching key the brass Yale key.

Containers can have keys, but not supporters.

Keys don’t have to be actual keys; you can have lockpicks or something more exotic (like a raw steak for a flesh-eating door, or that weird animal head door in Zork II).

3.14 is devices, something I’ve used several times in my current game. The only thing a device does is it can be ‘switched on’ or ‘switched off’, standard actions in the inform library. Although it’s a bit annoying that you can’t have something be both a device and a container (I think, I’ve definitely gotten errors like that).

This section also mentions that you can make decisions on how to print things based on the status of an object:

The coffin is an openable container in the Undertomb. "[if open]The lid of a plank coffin yawns open.[otherwise]A plank coffin lies upon the dirt floor of the Tomb."

This is good stuff; I spent years trying to figure this out.

Example 25 has Disenchantment bay adding switchable instruments.

Example 26 makes a light switch and previews the introduction of light and dark rooms.

It mentions something very obscure which I’ve tried hard to understand but always fail. This is our first experience with the dreaded ‘scope’:

Finally, we need to deal with a special case. In general, the player cannot interact with other things in a dark room because he can’t see them, but if we adhered strictly to this it would be impossible for him to find the light switch to turn it back on. So we need something from the chapter on Activities to change this:

Terrifying Basement is a room. The light switch is a switched on device in the Terrifying Basement. It is fixed in place.

Carry out switching off the light switch: now the Terrifying Basement is dark.

Carry out switching on the light switch: now the Terrifying Basement is lighted.

After deciding the scope of the player when the location is the Terrifying Basement:
place the light switch in scope.

Upstairs is above the Terrifying Basement.

Section 3.15 is light and darkness itself!

Rooms are either ‘dark’ or ‘lighted’.

When the player is in a dark room, he can still go in various directions, but he cannot see the room description or interact with any of the objects in the room, except those he is holding.

This means the description of a dark room will never be printed unless the room is lighted. The standard way to light a room is with a ‘lit’ object, which can shine through transparent containers but not opaque.

3.16 is vehicles and pushable things. I didn’t know vehicles were standard in Inform! I thought the manual had examples on how to make them, but not that they were hardcoded.

Next in the tour of standard kinds is the “vehicle”. This behaves like (indeed, is) an enterable container, except that it will not be portable unless this is specified.

In the Garage is a vehicle called the red sports car.

The player can enter the sports car and then move around riding inside it, by typing directions exactly as if on foot: and the story will print names of rooms with “(in the red sports car)” appended, lest this be forgotten.

There is also an extension for rideable vehicles called ‘Rideable Vehicles’ by Graham Nelson.

Example 27 is a simple example of a rideable bike (rideable meaning you go on top of it instead of inside it).

Example 28 is more disenchantment bay. This doesn’t have a vehicle, but does have a pushable container. This contains the seemingly-contradictory but technically correct code:
It is fixed in place and pushable between rooms.

Example 29, Hover, has a floating car kind of thing. This example heavily modifies the rules to let you see the exterior but modified by a blue tint.

This example would have been very useful for my revolving glass door that divides a room into four sections. But c’est la vie:

The container interior rule is listed before the room description body text rule in the carry out looking rules.

This is the container interior rule:
if the actor is the player and the player is in an enterable thing (called current cage), carry out the describing the interior activity with the current cage.

Describing the interior of something is an activity.

Rule for describing the interior of the hover-bubble:
say "The hover-bubble is transparent, but tints everything outside very faintly lavender."

Rule for describing the interior of the hover-bubble when the hover-bubble contains more than one thing:
say "The hover-bubble is transparent, but tints everything outside very faintly lavender. Beside you you can see [a list of other things in the hover-bubble]."

Definition: a thing is other if it is not the player.

Rule for listing nondescript items of the hover-bubble when the player is in the hover-bubble: do nothing.

I honestly handle technical stuff like this with global variables and then hunting down individual rules and saying ‘the ___ rule does nothing when _____’. I do use the rule for listing nodescript items thing. For instance, I have a climbing wall that players can move from rock to rock on, and it was reprinting the whole room text each move, so I added this:

The room description heading rule does nothing when looking is stupid.
The room description body text rule does nothing when looking is stupid.
The offer items to writing a paragraph about rule does nothing when looking is stupid.

To decide whether looking is stupid:
	if the climbing-wall is nowhere, decide no;
	if the player is not enclosed by pride-room, decide no;
	if the current action is not looking, decide no;
	decide yes;

I think it catches a little more than I want, but no one has complained yet!

3.17 is men, women, and animals.

A person is a kind of thing, and man, woman, and animal are kinds of people.

Inform has a hard gender binary. Even ‘neuter’ is secretly male:
Because of the existence of "neuter", we sometimes need to be cautious about the use of the adjective "male": since Inform, partly for historical reasons, uses an either/or property for masculinity, neuter animals are also "male".

You can make neuter animals by the way with The spider is a neuter animal in the Bathroom.

Example 30 is Disenchantment Bay again with a Captain.

We’re close to the end, so let’s keep going!

Section 3.18 is articles and proper names!

Inform guesses which kind of indefinite articles you want for things by your use of them in the code:

Suppose we have said that:

In the Ballroom is a man called Mr Darcy.

When the Ballroom is visited, the man is listed in the description of the room as “Mr Darcy”, not as “a Mr Darcy”. This happened not because Inform recognised that Darcy is a proper name, or even because men tend to have proper names, but because Inform noticed that we did not use “a”, “an”, “the” or “some” in the sentence which created him. The following shows most of the options:

The Belfry is a room. A bat is in the Belfry. The bell is in the Belfry. Some woodworm are in the Belfry. A man called William Snelson is in the Belfry. A woman called the sexton's wife is in the Belfry. A man called a bellringer is in the Belfry.

In the Belfry is a man called the vicar. The indefinite article of the vicar is "your local".

I had to use this recently because I had a clone of the player called ‘your clone’ that follows you around and copies you.

The subtlest rule here is in the handling of “the”. We wrote “The bell is in the Belfry”, but this did not result in the bell always being called “the” bell: in fact, writing “A bell is in the Belfry” would have had the same effect. On the other hand, “A woman called the sexton’s wife is in the Belfry.” led to the wife always being known as “the” sexton’s wife, not “a” sexton’s wife, because Inform thinks the choice of article after “called” shows more of our intention than it would elsewhere.

I’ve noticed frequently in this chapter that using the ‘called’ way of naming something resolves almost all the problems you might have with compiling. Good to know for the future!

It also includes some collective noun things:

Now we can write:

The water is here. The indefinite article is "some".

and this time Inform does not treat the “some water” thing as a plural, so we might read:

You can see some water here.
The water is hardly portable.

Example 31 is just the example in the text itself, with the vicar.

Example 32 gives a way to switch between using articles and not:

The Ark is a room. A bearded man is in the Ark.

Instead of examining the bearded man for the first time:
    now the printed name of the bearded man is "Japheth";
    now the bearded man is proper-named;
    say "You peer at him a bit more closely and realize that it's Japheth."

Section 3.19 is carrying capacity. This can be used well, but the people I see most often concerned about it are people just starting out who believe that being meticulously accurate to reality will make people like their games more. This kind of author also tends to put multistep actions for things like driving (making opening the door, getting in, buckling belt, putting key in, etc. separate actions) and will implement every single object in a kitchen or bathroom.

But when used right, this can be good for optimization games or games where the puzzle depends on inventory. Although it can be really annoying; I made a game where you turn into a dog and your inventory limit gets set to 1, and people hated dropping everything. It’s one of my lowest-rated ‘big’ games.

You can make carrying capacities for both supporters and containers, as well as players.

The bijou mantelpiece has carrying capacity 3.

The carrying capacity of the player is 4.

Section 3.20 is Possession and clothing. It introduces a new relation, ‘worn’, which is different than carrying.

Mr Darcy wears a top hat. Mr Darcy carries a silver sword.

In fact, Inform deduces from this not only who owns the hat and the sword, but also that Darcy has the kind “person”, because only people can wear or carry.

This is true! In a recent thread, I discovered that making a person wear a watch made them alive and a man.

You can also just declare something wearable:
The gown is wearable.

Example 33 revisits Disenchantment Bay, adding some clothing.

Section 3.21 is The player’s holdall. This is just a way to have a single container the player throws everything in. If you are going to have an inventory limit for the player themself, then having a holdall is a good way to keep everyone from being mad at you.

The Attic is a room. The old blue rucksack is a player's holdall. The player is wearing the rucksack.

The carrying capacity of the player is 3.

Example 34 is Disenchantment bay with a holdall backpack.

3.23 is food. Declaring something ‘edible’ lets you eat it and it disappears, with no other effects.

3.23 is parts of things. This is useful when something needs to serve multiple purposes or have different responses when you try to touch or take different parts of it. For instance, I have a wax figure of Napoleon in my game, and he holds a steel saber. Touching them should feel different!

So you can say stuff like:
The lever, the white button and the brown button are parts of the Chocolate Machine.

Example 35 is Fallout Enclosure. It gives you a way to interact with everything ‘held by’ an object in some way:

An enclosure is a kind of thing. A container is a kind of enclosure. A supporter is a kind of enclosure.

Understand "zap [something]" as zapping. Zapping is an action applying to one thing. The Zapping action has a list of things called the remnants.

Carry out zapping an enclosure:
    if the noun holds something:
        now the remnants is the list of things held by the noun;
        repeat with N running through the remnants:
            move N to the holder of the noun.

Example 36, Brown, has a sticky label that can become part of something and then taken again.

Example 37 is a 4-star example (perhaps our first?) that is the complete Disenchantment Bay. It is quite complex and worth checking out!

Section 3.24 is Concealmen, which decides which objets carried by other people are visible or not:

Rule for deciding the concealed possessions of the Cloaked Villain: if the particular possession is the sable cloak, no; otherwise yes.

You can use this trick to hide parts of an object!
The coin is in the Roman Villa. The face and inscription are parts of the coin. Rule for deciding the concealed possessions of the coin: if the coin is carried, no; otherwise yes.

This sounds super useful! Glad I found this…

There is also an either/or property called "described"/"undescribed", intended to be used only as a last resort, but which has the ability to hide something from room descriptions. This not really hiding: the idea is that "undescribed" should be used only for cases where some other text already reveals the item, or where its presence is implicit.

This is the thing I was looking for! Wow, it was ‘undescribed’ all along…this could have saved me so much pain with a key I had opposite of a revolving door…I can’t believe it…

Example 38 is a complex example where someone has concealed possessions, but they become visible if you take his jacket or if you search him.

Section 3.25 is The Location of Something.

Things without specified locations are Nowhere. The player can’t be Nowhere, that gives you a runtime error I’ve gotten too many times.

You can find the location of something, though.

This phrase produces the room which, perhaps indirectly, contains the object given. Example: if the player stands in Biblioll College and wears a waistcoat, inside which is a fob watch, then

location of the fob watch

is Biblioll College. In general, a thing cannot be in two rooms at once, but there are two exceptions: two-sided doors, present on both sides, and backdrops. The “location of” a door is its front side, but a backdrop has no location. (Objects which are not things at all, such as rooms and directions, also have no location.)

I use this a lot, it’s good stuff.

There is a technical note which is good here:

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. And when something moves around, anything it encloses will move with it. In the example above, Biblioll College (a room) and the player (a person) both enclose the fob watch and the waistcoat. (The small print: a door is enclosed by the rooms on both sides; a backdrop is never enclosed.)

Enclosure is only useful when being used as a question. So the following is fine:

if the player encloses the fob watch, ...

But these will produce problem messages:

The player encloses the fob watch. The location of the trilobite is the Museum.

‘Enclosed by’ includes things in containers players are carrying, like it says, which is useful. I had rules in my game that said the player can’t leave while ‘carrying’ a diamond ring due to a security system. Rovarsson broke the game by hiding the ring in a rucksack, since then it wasn’t ‘carried’ according to inform. Switching it to ‘enclosed by’ foiled his plan.

Example 39, Van Helsing, describes wayfinding, helping Dracula chase down the player:

Every turn:
    if the location of Count Dracula is not the location of the player:
        let the way be the best route from the location of Count Dracula to the location of the player, using doors;
        try Count Dracula going the way;
    otherwise:
        say "'Muhahaha,' says Count Dracula."

Finally (Phew! I think I bit off more than I can chew), we have 3.26, Directions.

Directions are a ‘kind’, but not things or rooms. Every direction must have an opposite:

Turnwise is a direction. The opposite of turnwise is widdershins.
Widdershins is a direction. The opposite of widdershins is turnwise.
Hubwards is a direction. The opposite of hubwards is rimwards.
Rimwards is a direction. The opposite of rimwards is hubwards.

Ankh-Morpork is hubwards of Lancre and turnwise from Borogravia.

This will mess up the automatic Index map, since it doesn’t know how to draw it, but you can say:

Index map with turnwise mapped as east.

Example 40 is a way to change the directions or exits of a room.

Example 41 is way to change compass bearings to be based on hexagons to work with wargaming. It also includes a picture of a wargame! You can tell the author really likes wargames, as they go into the history a lot here. My dad loved these (he’s still alive, but I never see him play them).

Example 42 is nautical directions. I honestly love it when people who put port/starboard in leave them as E/W as well for convenience.

And that’s it! Whew!

You can do a ton in Inform with just the stuff in this chapter.

3 Likes
30

Get rid of that glut of Instead rules by using tables. I7-Extensions/Can't Take That.i7x at main · rileypb/I7-Extensions · GitHub

2 Likes
31

For a real-world example, Counterfeit Monkey has a display case which is “unlocked” by a screwdriver (which can remove the screws holding the back panel on). Why do it this way? Because OPEN X WITH Y maps to the “unlocking” action and this way we can let Inform’s internal machinery handle most of the process for us.

I wrote an extension to change this, once upon a time, but it would need to be totally rewritten for Inform 10. It’s much easier to make enumerated properties in I7 than in I6, so there’s no longer a strong reason to have “male/female” and “neuter/not neuter” be independent when we could just have a “male/female/neuter” enumeration. (In I6, binary attributes are far, far easier than enumerated properties.)

For bonus points we could also add an option that makes an object use singular “they”, but that adds some complications to the grammar, so it’s probably better bundled with an “advanced pronouns” extension that lets things take multiple pronouns—like a ship being either “it” or “she” but not “he”.

I believe you can set a direction to be its own opposite, if there really isn’t an appropriate opposite in the setting. For example, some early adaptations of Colossal Cave implemented the magic words as directions (after all, they’re commands that take you from a specific room to a specific other room; isn’t that the same as NORTH?) and in that case you’d want the opposite of XYZZY to be XYZZY.

There’s a long-standing convention that all ships in IF need to be travelling east, because then when the player types S, you don’t have to guess whether they mean SOUTH or STARBOARD. This is why, for example, the Titanic is headed east when it hits the iceberg in Jigsaw, even though that makes no historical sense. It just makes things so much simpler.

4 Likes
32

Tables are all well and good, but there’s nothing wrong with using Instead rules here. They get a bad rap but their performance impact is minimal compared to, say, route-finding or regex replacement.

3 Likes
33

Oh no. Instead rules are fine. I just like having this kind of text centralized in a single place where I can easily see what needs to be filled in. But I don’t want to hijack the thread.

4 Likes
34

Nathanael Nerode wrote Gender Options which handles multiple genders. I’ve extended it to add a non-conforming/non-binary option. It also adds the singular they. I need to clean it up and update the docs and then I can release it for 9.3. Then I can look into updating it for 10.

I have a WIP that actually uses all this stuff, but it’s shaping up to be big, and Spring Thing has gotten in the way.

Zed deserves a lot of credit for helping me out.

Edit: Fixed spelling of “Nerode”.

4 Likes
35

“Undescribed” will actually do this, though there are more sophisticated ways – there was just a thread about this!

Oh man, I love backdrops, especially once I realized you could make things – like containers, or people – part of the backdrop and open up multi-room interactions without needing to worry about manually moving stuff around.

This is a weird way, though the nice thing about it is that it’s analogous to how you write initial appearances for other objects, as you mention later – in some ways room descriptions are more like initial appearances (what you get when you type L) than descriptions (what you get when you type X THING – though of course you can’t X ROOM out of the box).

Jeez, having understand logic for just “with” or “of” seems like a really dicey design choice – I tend to do what you do, as well (though with the slash syntax, which seems easier to me for most things – “box/-- of/-- gold” or “box of/-- gold/–”.

I way way overuse this, because I learned it early and it’s easier than having to understand things like “rule for printing a paragraph about”. Actual description of a hat rack in my first game:

“This wooden number sports a profusion of hats – [if the silly floppy tam is undescribed and the crown of laurels is undescribed and the ear warmers are described]among the swarm, a silly, floppy tam and a crown of laurels catch your eye[end if][if the silly floppy tam is undescribed and the crown of laurels is described and the ear warmers are described]among the swarm, a silly, floppy tam catches your eye[end if][if the silly floppy tam is described and the crown of laurels is undescribed and the ear warmers are described]among the swarm, a crown of laurels catches your eye[end if][if the silly floppy tam is described and the crown of laurels is described and the ear warmers are described]none of the swarm of hats has much to recommend, though[end if][if the silly floppy tam is undescribed and the crown of laurels is undescribed and the ear warmers are undescribed]among the swarm, a silly, floppy tam, some ear warmers, and a crown of laurels catch your eye[end if][if the silly floppy tam is undescribed and the crown of laurels is described and the ear warmers are undescribed]among the swarm, a silly, floppy tam and some ear warmers catch your eye[end if][if the silly floppy tam is described and the crown of laurels is undescribed and the ear warmers are undescribed]among the swarm, some ear warmers and a crown of laurels catch your eye[end if][if the silly floppy tam is described and the crown of laurels is described and the ear warmers are undescribed]among the swarm, some ear warmers catch your eye[end if].”

(I should at least have done these as "otherwise if"s. Pretty unwieldy regardless!)

Checks out!

…I’m too lazy to update this long comment so far down, but yeah, it’s super helpful even though there are more elegant ways of doing things!

(I got hung up on the “concealed” vs. “undescribed” thing for a long, long time, I should say – it’s a pretty unintuitive part of the language IMO).

Thanks for flagging this – never came across it but sounds fun!

2 Likes
36

Yes. This is my go-to solution for the classic “pie on the window sill” problem.

2 Likes
37

3.6 Either/or properties

It seems weird that this doesn’t say anything about defaults.

I think it’d be good to lean more heavily on how openable/unopenable simultaneously conveys closable/unclosable, especially since containers are unopenable by default. One will find oneself saying “The basket is an open openable container”, even if it sounds a little funny.

I don’t think we ever are told explicitly that containers are unopenable by default. Something you’re supposed to learn from the Project Index, I suppose.

3.8 Scenery

Scenery is not portable by default, but you still can’t take it because there’s an explicit (and mostly redundant) can’t take scenery rule. Further scenery blocking actions:

  • can’t push scenery
  • can’t pull scenery
  • can’t turn scenery

I am either not a fan of the describe what’s on scenery supporters in room descriptions rule or not a fan of the absence of a describe what’s on scenery containers in room descriptions rule. Either describing them both or ignoring them both would be better than giving us another exception to remember.

3.13 Locks and keys

Inform will not allow any discussion of the matching key of a supporter, or of a supporter being locked or unlocked.

Oh, it talks a good game about what’s not allowed, but Inform’s a big old softie. This code:

The Lab is a room. The platform is a supporter.

when play begins:
  if the platform is unlocked, say "That's strange."

outputs “That’s strange.”

3.14: Devices and descriptions

In 9.3/6M62, all but one of the related standard rules didn’t actually test whether something was a device, it tested whether something provided switched on. In 10.1 the solitary holdout gave in and now tests for switched on, too. This means one can easily get by entirely without devices as their own kind: you can just say it can be switched on, instead. And that means you can functionally have supporters or containers that are also devices.

3.15 Light and Darkness

I think that the first mention of a dark room would be the right time to mention the existence of the in darkness phrase, and how it’s probably what you really want if you find yourself reaching for in a dark room.

3.16 Vehicles and pushable things

We have already seen that some things are portable, others fixed in place. In fact we can also make a third sort of thing: those which, although not portable, can be pushed from one room to another

I count four sorts of things.

  • portable/not pushable between rooms (the default)
  • portable/pushable between rooms
  • fixed in place/not pushable between rooms
  • fixed in place/pushable between rooms

That seems worth going into for a couple of reasons. The final entry sounds like nonsense. But fixed in place doesn’t mean fixed in place, it means “can’t be picked up”. Fixed in place/pushable between rooms would be the obvious implementation of an IF staple: the crate (or trunk) you have to push to the next room to stand on to reach something. The default is actually the combo that’s peculiar, easily resulting in messages like “The soccer ball cannot be pushed from place to place.” despite that being the point of a soccer ball.

[edited to insert comments on 3.14: Devices and descriptions]

2 Likes
38

… hahahahaha!

Completely unrelated: At first I thought it’s depressing how much I’m learning in this topic by having someone just read and paraphrase to me what I could read for myself (and presumably have mostly read before, at some point). But then I realised the paraphrasing isn’t just paraphrasing, it’s commentary that’s connecting each small bit to the whole, and mathbrush’s own authoring experience. That’s why this has become considerably more enlightening than just reading the manual.

-Wade

5 Likes
39

Matching key is an object property, so you could even make it a room, or a region, or a direction!

It’s not in the slightest bit useful but you can.

2 Likes
40

The most controversial rule in all of Inform!

3 Likes