Iron ChIF: Season One Episode 1 (lpsmith vs. Afterward, using Inform 7)

Our challenger continues his maximal transparency, with bug reports tracking his to-do items and even including his initial tester’s comments. And we find some substantial new code.

The Scenes extension and Being Chased both make use of Inform’s scenes. Lucian’s “Scenes” has some (non-recurring) scenes corresponding to discrete events in the story, while Being Chased defines several recurring scenes, creating the framework to both detect and customize some meaningful circumstances. Together, they effectively demonstrate how and when to use scenes.

As described in my above overview of Inform, a motivation for Inform’s rule-based design is rules’ value in handling all the exceptional behavior that IF is prone to. But just how do we actually specify the exceptions – how, in practice, do you catch all the cases you want while avoiding those you don’t?

Well, Inform has lots of ways to categorize elements to facilitate selecting or excluding them. I think of it as chunking and consider it a crucial part of the craft of Inform (it’s the focus of WI Chapter 6: Descriptions). You can define subkinds. Rooms can be grouped into regions. There are named action patterns (“kinds of actions” ). One powerhouse is adjectives from either/or properties or definitions or “conditions” (i.e., properties whose kind is an enumerated kind of value).

And there are scenes. They make a great way to approach set-pieces or events in your story, just as the name implies. But I fear that that evocation and the docs’ emphasis on their suitability for managing things related to the passage of time may distract from something important.

Scenes are perhaps the most general and flexible facility for chunking in Inform.

They’re conceptually very simple. A scene is either happening in the moment or it’s not. For each scene, you specify the circumstances under which it should begin[1] and end. It has two associated rulebooks, one to be followed when it begins and the other when it ends. If it isn’t defined to be recurring, it can only happen once.

And there’s a scene changing rule. It loops through the scenes and for each scene, if it’s happening, its end-condition is tested and if it should end, its ending rulebook is followed or if it’s not currently happening, likewise for its begin-condition and beginning rulebook (…unless it’s a non-recurring scene that has already happened). The scene changing rule gets followed before each turn[2] and again immediately after every action, before the every turn rules (making Every turn during <scene> a useful place for scene-specific rules).

And that’s pretty much it! The simplicity goes beyond conceptual into the actual. If they didn’t already exist, they could be made from scratch with not a lot of Inform code![3]

Some crucial things to note are:

  • the conditions marking scenes’ beginnings and ends are arbitrarily complex, anything you can come up with
  • any number of scenes can be happening at once

So they can correspond to any situation. If some combination of particular values or statuses or whatever conditions in your game’s global state give rise to some meaning that’s useful to track, scenes are often the best way to do so and to customize behavior based on their occurrence.


  1. technically optional, but a scene that can never begin is as useful as it sounds ↩︎

  2. “before each turn” is a colloquial description: it’s followed during the Startup rules before the first turn, and also near the end of the turn sequence, but notably after the advance time and update chronological records rules; see the turn sequence for details. ↩︎

  3. equivalent functionality, that is – you wouldn’t be able to reproduce the existing syntax ↩︎

10 Likes