time trap

stopping the clock.

what usually happens.

Time in a parser game is measured in turns. A player types a command, and, if the command is accepted, the game will process it, update the state of the game world, and print feedback. For instance, this little Inform project:

lab is a room.

the shirt is a wearable thing. it is in lab.

can produce this gameplay:

Welcome
An Interactive Fiction
Release 1 / Serial number 260814 / Inform 7 v10.1.2 / D

lab
You can see a shirt here.

>wear shirt
(first taking the shirt)
You put on the shirt.

There are lots of things that might be happening in the background, of course. There might be a timer running, perhaps counting down to the arrival of a monster or an unexpected spring rain shower. Inform has its own invisible machinery processing, too, causing time to advance in the world.

Some commands should never advance the clock. Saving the game, for instance, isn’t something that is simulated in the game’s world. We often call such commands “meta commands” (with or without a space character) because they only have meaning outside of the fiction we’ve wrought.

Inform calls such actions “out of world.” Are there times, though, when an in-world action should not advance the clock? Authors are often interested in making exceptions for certain actions. In my own Repeat the Ending, I wished to prevent the clock from advancing while looking if certain timed events were active. This was because the player might need information from looking to complete the event, and I thought it would be needlessly punishing to count a “look” command against the clock.

Authors might have all sorts of reasons for stopping the clock. It’s important to note that the generally suggested solution will prevent the following from occurring (this may not be an exhaustive list):

The processing of every turn rules.
Advancement of timed events.
Incrementing the turn count.
Updating chronological records (which handles things like if we have examined the frob and the like.
Scene changing.
Adjusting light.
Setting held things to handled (if they aren’t already).

This list isn’t meant to discourage anyone. In general, an author wishing to prevent the turn from advancing specifically wants all of these things to be skipped. Still, for troubleshooting purposes, it’s good to know what’s at stake.

a documented solution.

The turn sequence rulebook is responsible for choreographing the various rules and rulebooks that process during an Inform game turn. Writing with Inform Example 408, “Timeless,” offers a straightforward approach to ending the turn sequence rules early. A rule is listed immediately before the “every turn stage rule”, and, should it be successful, the rulebook will end. In the case of the example, it excludes two actions, looking and examining. First, it declares a kind or category of action, “acting fast.”

Examining something is acting fast. Looking is acting fast.

Next, it declares and situates the relevant rule:

The take visual actions out of world rule is listed before the every turn stage rule in the turn sequence rules.
 
This is the take visual actions out of world rule: if acting fast, rule succeeds.

When the player either looks or examines, action processing will end in success when the “take visual actions out of world rule” executes, and this happens just before the “every turn stage rule” is listed.

handling more complex scenarios.

What if the machinery of our game is complex and time sensitive? Imagine, for instance, a game that includes both periods of exploration and turn-based combat. It might be desirable to manage a number of cases for time advancement. Rather than filling the turn sequence rulebook with a number of rules, we could make a rulebook.

time skipping is a rulebook.

This is my own name, of course. It could be anything that we find readable. I’d next make the rule calling upon the rulebook, and place it appropriately.

the time skip stage rule is listed before the every turn stage rule in the turn sequence rules.

this is the time skip stage rule:
	abide by the time skipping rules;

Note the use of “abide.” What’s that about? We are saying that if the “time skipping rules” succeeds, then the “time skip stage rule” will succeed. In this way, we can create a number of “time skipping” rules and, should one of them succeed, the “time skip stage rule” will also succeed, ending the turn sequence rulebook. If we are building from the “Timeless” example above, we could start here:

a time skipping rule (this is the take visual actions out of world rule):
	if acting fast:
		rule succeeds;

We could use more qualified rules:

a time skipping rule (this is the enjoy looking while you can rule):
	if looking and the player is in the deathtrap:
		rule succeeds;

Or consider other factors:

a time skipping rule (this is the examining held items costs nothing rule):
	if examining something held:
		rule succeeds;

Or check variables:

free action is initially false.

a time skipping rule (this is the free action rule):
	if free action is true:
		now  free action is false;
		rule succeeds;

We never want to do more of this than is needed, of course, because the clock advances by default. We likely expect certain things to happen, and it would be easy to lose track of what should and shouldn’t be firing at a given time.

troubleshooting.

Since these rules are all gathered in one place, we can add some troubleshooting checks fairly easily. Perhaps we’d like to see what the rulebook considers the “current action” or see a checked variable for ourselves. We can add anything that might help us understand what is or isn’t working.

a first time skipping rule:
	say the current action;
	say line break;
	if the noun is not nothing:
		say the noun;
		say line break;
	say "free action: [if free action is true]true[otherwise]false.";
	make no decision;

Note that “make no decision” isn’t necessary here. It’s the default outcome of a rule, but I like to see it as a way to verify that I haven’t assigned some other outcome by mistake.

advance time.

Could we have multiple rules loose in the turn sequence rulebook instead? Of course, but we’d lose out in terms of organization and consistency. Our custom rulebook will be listed in the project index, which can help us keep track of things. Finally, things will be easier to debug if we use a centralized design. For projects involving multiple scenarios for “out of in-world actions,” a rulebook is definitely worth a try.