ifs, ands, and otherwises
reintroductions.
Hi all! It’s been a while. At some point, it will probably make sense to work through specific chapters in the documentation. Starting at the beginning would be the most logical approach, so let’s not do that. I’ve been thinking about what Inform calls “phrases” a lot, specifically ones used to create new conditions and adjectives.
using conditions to assess the state of the world.
What are conditions? They are used to form conditional statements. Chances are, we use them all the time. For instance:
if the secret number is five:
...
if the location is the winding staircase:
...
if the player carries the frying pan:
...
if the second noun is scenery:
...
if the turn count is less than 20:
…and so forth. A condition follows the magic words “if,” “when,” “while,” or “unless.” We can specify what code will run based on whether a condition is met or not. Consider the following preamble (the opening line of an Inform rule):
every turn when nothing is on the oaken bench:
We could “tree” things out, so to speak, using a shorter preamble:
every turn:
if nothing is on the oaken bench:
Another option would be to formulate a negative case:
every turn:
unless something is on the oaken bench:
What’s the difference? Since performance problems are rare (though we might talk about some common cases someday), it probably won’t matter whether a rule is processed as applicable on every turn (“every turn” preamble) or processed only when conditions are met (“every turn when nothing is on the oaken bench”).
It might matter, though, that Inform processes more specific rules first (the one with the “when” clause) and less specific ones later. By adding conditions to our preambles, we assign rules priority over the ones that don’t.
too many “ands” for my taste.
Wherever we put our conditions, though, we will want to make sure they are readable and applied consistently. Here’s a barely functional project that contains a lot of properties and values.
lab is a room.
closet is a room.
a cat is a kind of animal.
coat is a kind of value.
the coats are orange and black.
a cat has a coat.
a cat can be hungry.
a cat is usually not hungry.
food is a kind of edible thing.
the hat is in lab.
the ball is in lab.
the kibble is food in lab.
the evening jacket is a wearable thing in lab.
Marbles is a female cat in lab.
Carrot is a male cat in lab.
the butler is a male person.
feeding timer is a number that varies.
feeding timer is 20.
every turn when feeding timer is greater than zero:
decrement feeding timer
With this imagined example, we could write out some pretty complex conditions. Consider:
every turn when food is in the location and the butler wears the evening jacket and feeding timer is less than ten and the player holds the ball and an orange cat is in the location:
under one condition.
This isn’t terribly easy to read, is it? What if we needed to use these same conditions elsewhere? Given the complexity, we might forget an ingredient or get it wrong while retyping it. That makes for two concerns: readability and consistency. To make things easier for ourselves, let’s use a “to decide” phrase to create a single, more readable condition that we could use again and again.
to decide if the very specific conditions are met:
if food is in the location and the butler wears the evening jacket and feeding timer is less than ten and the player holds the ball and an orange cat is in the location:
decide yes;
With this custom condition, we can write a much tidier preamble. These two are functionally the same now:
every turn when food is in the location and the butler wears the evening jacket and feeding timer is less than ten and the player holds the ball and an orange cat is in this location:
...
every turn when the very specific conditions are met:
Much better! We could use a different organizational strategy we find it more readable. Choose what works best for you.
to decide if the very specific conditions are met:
unless food is in the location, decide no;
unless the butler wears the evening jacket, decide no;
unless feeding timer is less than ten, decide no;
unless the player holds the ball, decide no;
unless an orange cat is in the location, decide no;
decide yes;
This tactic is referred to in the documentation as defining a new condition by using a “to decide” phrase. Such phrases don’t just apply to things in the world. We can make custom criteria based on numerical calculations, table values, or anything else we can check in code. I’ve talked about this practice before because I use it all the time and I am still discovering new uses for it.
CF https://zedlopez.github.io/i7doc/WI_11.html#section_16
next.
Let’s discuss definitions next, which we can use to create new adjectives.
top expert 