top expert

what are turns made of?

to everything, turn, turn, turn.

Last week, a reader commented on my use of a carry out rule. That’s great! I’ve been thinking about it, and decided it’s probably time to review action processing.

“Action processing” is a general term referring to order, organization, and outcomes with regard to the things that “happen” during Inform games. Time passing in parser games typically occurs is measured in units of time called turns. Turns pass in response to player commands. Usually, one actionable (valid) command creates a response, and that response takes one turn. The most common command is EXAMINE. If a player examines something, a typical response is for Inform to print the description of that something.

>x chairs
There were an incredible number of seats there, probably twenty at least! I had a hard time imagining so many people in one place all at once. There weren't any people sitting in them, but I had a feeling that there was more to them than I could see at first glance.

This exchange takes one turn, and increments an automatically tracked number called the “TURN COUNT”. We can refer to this number any time we like:

say "The current turn count is [turn count].";

Even though players may not see all or even most of it, a lot of things happen during the course of an Inform turn. I’ll share a link to a very complex diagram of the turn, but don’t get lost in it, as understanding the highlights is often enough.

Check out this 2009 post from Emily Short’s blog.

What I say here will not be exhaustive, but it should provide a good starting point for new authors. I’ll list these in order, though some cycling is possible.

the player’s command.

The turn starts with the player’s command. In nearly every parser game, time stands still until a command is entered. Parser gameplay usually consists of commands being parsed into actions and, when applicable, one or two nouns. While there are some opportunities to get involved with parser operation, a lot of it is not accessible to us as beginners. Let’s set aside the parser for another day.

However, before the command parsing begins, we do have some fairly direct methods for engaging with Inform. This involves two basic formulations:

before reading a command:

Since the game has not read the command yet, our options are quite limited. Perhaps we’d like to check or change some variables or modify the appearance of the command prompt.

after reading a command:

This one is used more commonly. We can check a command in ways we can’t–by default, anyway–check via Inform’s natural language diction. We can even edit or replace commands, bypassing the parser to do so. In fact, the command isn’t really a command. It’s a line of text that Inform’s parser hasn’t evaluated yet.

Note that no turns have passed at this phase, because the parser has not yet turned a command into action.

However, there is a lot to consider while using either tactic, since we are setting aside Inform’s usual framework of parsed commands and actions. That isn’t to say that a beginner should never use them! My advice is just to exhaust the possibilities of action processing first.

before.

Inform will then parse valid commands into actionable elements. This occurs in a series of steps. During this process, the state of the world will be checked several times.

Once a valid command has been processed, Inform will perform a couple of checks pertaining to items included in groupings, for instance what is included in the “all” of TAKE ALL.

Once that’s done, our action rules begin in earnest. The earliest possible action processing rule is the BEFORE rule. BEFORE rules are, in my experience, both potent and uncommon. Uncommon, because it’s not usually necessary or useful to do things with BEFORE (we’ll use later rules for almost everything). Potent, because when you need them, you really need them. The biggest reason to use BEFORE is that it comes before Inform has checked either visibility or accessibility.

“Visibility” is a little misleading. It is a check to determine the room has light or not. We could use a BEFORE room to allow players to perform actions that are prevented by darkness.

If we wanted to render an item or room visible in a less limited sense, we would change the scope of the player. More on that another day!

“Accessibility,” on the other hand, governs what the player can touch (many actions require one or more “touchable” things). Using a BEFORE rule may allow the player to manipulate an item locked within a transparent container, even though that is usually impossible. Essentially, a BEFORE rule will allow the player to touch any visible or in-scope thing, regardless of location. BEFORE also allows actions against non-touchable objects, for instance:

before touching north:
	say "OK!"

will yield

>touch north
OK!

You must name something more substantial.

Note that the “OK!” response is from the BEFORE rule, while the “You must name something more substantial.” comes from the BASIC ACCESSIBILITY RULE, which has subsequently determined that a direction cannot be touched.

The other reason for using BEFORE, and this will be a recurring concept, is that we can “get in front” of later phases of action processing. Let’s say we have an INSTEAD rule (the next phase of the turn) that almost always works, but we need to disable it for a very specific situation. If we don’t want to retool the actions involved, we can just prevent that INSTEAD from firing:

before jumping when the turn count is less than ten:
	say "It's far too early for that." instead.

Still, because of visibility and accessibility differences, it’s good to think such things through.

instead.

Once BEFORE rules have completed, and visibility and accessibility are determined, INSTEAD rules are processed. INSTEAD rules, as the name suggests, happen INSTEAD of something else. Although INSTEAD can be a trap for new authors (I’ll come back to this), it has a lot of uses. I usually use it for simple redirection of actions. We might have a custom action for something, for instance. In some cases, built-in actions might be redirected to it.

instead of cutting something:
	try preparing the noun.

In this way, trying to cut something–an onion, for instance–would redirect to an action we’ve come up with, PREPARING. Note that we can be very general with our INSTEAD rules. There’s nothing to stop us from making a rule like:

instead of doing something:
	say "I prefer not to.".

That’s kind of silly. But let’s say we have an item. It’s an apple. Instead of implementing every possible action with the apple, we can use a general instead rule to head most things off.

instead of doing something other than eating, taking, or examining to the apple:
	say "That apple is only good for eating.".

That can be pretty handy, especially if we are trying to avoid Inform’s built in action responses.

My personal taste is to avoid instead rules in a lot of cases, because INSTEAD stops action processing. If we have an INSTEAD rule for SMELLING THE ROSE, Inform will stop processing that action the INSTEAD is reached. My general preference is to use the entire processing turn unless I have a reason not to. From a learning point of view (I’m still learning, after all), I benefit from keeping an eye on what happens as the turn progresses. Another reason is that I like using AFTER rules for things like keeping score, tracking player goals, and so forth. I’ve written about that here!

Still, it can’t always be helped. This is especially true of actions that are part of the Standard Rules. There are multiple rules governing the EXAMINING action, for instance, and it isn’t easy for us to just jump in the middle of that. Rather than taking a wrench to the action and hoping for the best, it’s probably best to “get in front” of the action with an INSTEAD rule.

instead of examining the jeweled scepter when the house is on fire:
	say "You don't have time to look at that right now!".

Here’s something you don’t want to do, and I want to stress this emphatically: don’t write your game using INSTEAD rules for everything. You can, definitely, and because you’ll be stopping other actions, you’ll never have to worry about what Inform does during the usual turn. You’ll never need to learn how default responses work. Consider this code:

instead of unlocking the iron door with the titanium key:
	say "Even though your hands are sweaty and shaking, you manage to get the iron door unlocked!";
	say "The fearsome mutant blorglebeast charges! But you manage to squeeze through the door in the nick of time, locking it behind you.";
	now the player is in the safe room;
	try looking.

Now, chances are this will all do that the author expects. We have dramatic text, and the player has gotten beyond the locked door! It’s fine. But what if you want a scoring system later? What if you want more than one thing happening, or if it matters if the door is actually open? This will work, but there’s no future in it, and it doesn’t have much to teach.

That isn’t to say don’t use it; just be wary of it.

check.

Next come CHECK rules, which have a narrower scope than INSTEAD. Usually, a CHECK rule is used to evaluate a specific action.

check eating the strawberry:
	say "You are allergic to strawberries." instead.

Note that we are still shutting down the action with “instead.” We don’t have to do that, we could use “check” to print one message or update a status, then continue on with a later CARRY OUT rule.

Why not use an instead rule? Once concept of organization is to use INSTEAD rules for broad, general purposes. If food can have a fried property, we could have a rule that handles all such cases with a single response.

instead of eating something fried:
	say "I've sworn off fried foods for the sake of my heart."

A CHECK could follow behind with specific cases that get past our rather healthy prohibition against fried foods. We can handle such scenarios with more tailored and specific response messages.

check eating kale:
	say "Even though they all say how healthy it is, I can't stand Kale. I can't even swallow one bite of it!" instead.

The general concept is that action processing begins wide but narrows to the specific.

As a matter of personal style, I rarely use CHECK messages (I’ll explain later), but that doesn’t mean they can’t be useful to you.

carry out.

By this time, the player’s parsed command has travelled a long way. BEFORE, INSTEAD, and CHECK have all permitted that the action reach the CARRY OUT phase of action processing. As the name suggests, now is the time for actions to be carried out. Things aren’t usually stopped here; the action does whatever it does and moves on.

What kinds of things can happen during carry out? In some cases, the state of the world changes. If a player successfully opens a door, the status of the door changes:

Carry out an actor opening (this is the standard opening rule):
	now the noun is open.

Sometimes, the only obvious result is printed text.

Carry out examining (this is the standard examining rule):
	if the noun provides the property description and the description of the noun is not "":
		say "[description of the noun][line break]";
		now examine text printed is true.

Note that “examine text printed” is tracked so that Inform knows whether it has printed something while examining, it doesn’t have any persistent effect on the world.

CARRY OUT might be a state of mind, then, since complexity, world condition, and printed output are all optional for a CARRY OUT rule. Instead of what such rules do, it’s often useful to think of when they happen during the player’s turn.

If BEFORE is the wide, open mouth of a funnel, then CARRY OUT is the narrowest point in the process. This is where specific, successful actions are carried out. In an abstract sense, a printed failure message might be a valid CARRY OUT rule. If the rule is specific and is going to continue on through action processing, CARRY OUT is a good fit.

Most of what your game does to affect the world or give feedback on completed actions will happen here.

I usually recommend specific rules, rather than complex conditional rules. That is, I prefer

carry out eating the apple:
	say "Juicy and crisp. Delicious!".

carry out eating the plum:
	"Delicious. So sweet and so cold.".

rather than

carry out eating a fruit:
	if the noun is the apple:
		say "Juicy and crisp. Delicious!";
	otherwise if the noun is the plum:
		say "Delicious. So sweet and so cold.".

As part of action processing, multiple applicable rules can execute during the same turn. The built-in rule for eating sends whatever is successfully eaten “nowhere,” or out of play.

Carry out an actor eating (this is the standard eating rule):
	now the noun is nowhere.

By default, both our rule printing feedback and the built-in rule taking the noun out of play will be processed.

after.

AFTER rules follow on after something has been carried out (or otherwise passed beyond the CARRY OUT phase of action processing). AFTER rules are useful and versatile. They can accommodate broad conditions, like

after doing something:

This makes AFTER rules handy for things like scoring systems, where actions and values require checking or updates with every successfully carried out action. If you’ve been following along, you know that I’ve used AFTER rules for tracking player objectives, for instance. A familiar idea from the documentation is giving items a property after the player examines them. We can use such a property to manipulate item descriptions, among other things. We’ll use a custom property called “examined” for this purpose.

a thing can be examined or unexamined.
a thing is usually unexamined.

first after examining something unexamined:
	now the noun is examined;
	continue the action;

A couple of features to note! “FIRST” can be used to push a rule to the front of its class. That is, if we have multiple AFTER rules and desire to arrange output in a specific order, we can use FIRST and LAST designations to do so. Note that this is only relevant to multiple rules from the same phase of action processing. We can’t make a CARRY OUT rule execute before an INSTEAD rule, but we can decide which applicable CARRY OUT rule runs first (or last).

The other important element of the above code is the phrase “continue the action.” We haven’t seen this before, but if, for example we want an action to proceed in spite of a rule that would normally end it (an INSTEAD rule, for instance), we can include the code “continue the action.”

AFTER rules, by default, end the action. INSTEAD rules end with a designation of “failure,” which I wouldn’t worry too much about. It’s a technical rather than a practical designation. AFTER rules end in “success.” In both cases, action processing stops. One implication of this is that it isn’t possible to reliably execute multiple AFTER or INSTEAD rules unless we’ve made arrangements. This isn’t a big deal for INSTEAD: that’s supposed to stop things. If we’re using “big” AFTER rules, on the other hand, we need to think things through.

One reason AFTER rules end processing for a specific action is that they can “get in front of” REPORT rules. In our fruit-eating example above, Inform has a built-in success message.

Report an actor eating (this is the standard report eating rule):
	if the action is not silent:
		if the actor is the player:
			say "[We] [eat] [the noun]. Not bad." (A);
		otherwise:
			say "[The actor] [eat] [the noun]." (B).

Now, we’ve already written our own text. This doesn’t interest us. We can stop the report rule from printing, or we can just make an AFTER rule.

after eating a fruit:
	do nothing.

That’s enough to prevent the report message and call the action a “success” (which, again, we aren’t paying too much attention to at the moment). If we preferred, we could move our text feedback here. We could also use AFTER rules to preempt any other REPORT rule, be it ours or Graham Nelson’s.

report.

I don’t do a lot with REPORT, personally, though it’s been helpful to me in some very specific situations. It’s generally used to print success messages from the standard rules. I’m sure a lot of us will recognize this, for instance.

Report an actor taking (this is the standard report taking rule):
	if the action is not silent:
		if the actor is the player:
			say "Taken." (A);
		otherwise:
			say "[The actor] [pick] up [the noun]." (B).

While it’s generally for feedback, there’s nothing stopping authors from messing with world state at the report phase. Some of the things that work other places will work here. Organizationally, though, it’s time to wrap things up by the time REPORT rolls around.

Report can’t handle the kind of broad, “big” rules that AFTER can. REPORT DOING SOMETHING, for instance, doesn’t work. AFTER is for follow ups, REPORT is a lid closing.

churn.

Note that action processing can repeat, or spawn parallel actions during a single turn. If we use INSTEAD to redirect action, for instance,

instead of taking the massive iron weight:
	try pushing the noun.

“Try pushing the noun” will spawn a new action that begins at the BEFORE phase. Consider this possibility:

carry out pushing the big red button:
	try hiding under the table;
	try covering my ears.

Inform will try to perform both actions starting at BEFORE, as ordered in the rule, then go back to try taking the original action (“pushing the big red button”) through action processing.

every turn.

Once every action dictated by the player’s command has completed, Inform will check scene status (I’ll be writing about scenes soon), then take a look at EVERY TURN rules.

EVERY TURN is part of the player’s turn, but it isn’t directly triggered by player action. Rather, EVERY TURN rules run independently. They’re good for general world management and machinery. Perhaps we’d like an ambient sound in a room:

every turn when the player is in the damp corridor:
	if a random chance of one in three chance succeeds:
		say "You hear the sound of dripping water.".

or

every turn when Scene III is happening:
	increment the dangerous number;
	if the dangerous number is 10:
		say "The skylight shatters overhead, and a very dangerous looking man leaps through!";
		now the dangerous man is in the living room.

scene iii ends when the dangerous man is in the living room.

And so forth! General, player-independent management of the game world is what EVERY TURN rules are all about. If they seem similar to AFTER rules used to keep score, they really aren’t. Think of such AFTER rules as responding to actions. EVERY TURN, on the other hand, is concerned with the game world itself.

Note that it is very common to have multiple EVERY TURN rules processing during a turn. If we add “rule succeeds” or “rule fails” or “stop the action” to an EVERY TURN rule, Inform will stop processing EVERY TURN rules. This is true of other phases, too. It usually isn’t desirable to say rules “succeed” or “fail” unless we have specific reasons for doing so.

what else.

Most of what happens next is out of scope for us. Inform will check for timed events, then advance the clock. More scenery stuff, etc.

A brief recap, in order of the kinds of action processing rules:

• BEFORE: first to process. Can bypass checks for visibility and accessibility. Support for “big” rules that can cover multiple actions and such.
• INSTEAD: Best used to redirect actions, prevent broad categories for action, or otherwise get in front of CHECK rules.
• CHECK: Perform checks on specific actions and stop or redirect as needed.
• CARRY OUT: Perform specific actions, print output, update world state as needed.
• AFTER: Good for action follow ups (score systems, property changes). Alternately: a way to get in front of REPORT. Support for “big” rules accommodating multiple actions.
• REPORT: Print output once actions are complete. Like CHECK and CARRY OUT, REPORT does not support “big” rules.
• EVERY TURN: Rules that execute every turn, independent of player action. Best used for checking and updating world state.

Sometimes a mix is good! Eventually, you might want to spread actions across multiple phases of action processing. I think the important thing for us beginners is to try and experiment with every phase, getting a feel for when and how things happen during an Inform turn.

next.

Back to relations. Scenes, too.

I’m on Bluesky!