Get rid of that glut of Instead rules by using tables. I7-Extensions/Can't Take That.i7x at main · rileypb/I7-Extensions · GitHub
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.
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.
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.
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”.
“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!)
…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!
Yes. This is my go-to solution for the classic “pie on the window sill” problem.
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.
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]
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.
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.
The most controversial rule in all of Inform!
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
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.
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/not 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.
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.
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’
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
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
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.)
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.
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 gonna cause you problems later debugging your code way:
The prevailing wind is initially southwest.
Apparently you can not 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:
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.
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:
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”.