Why are scene changing rules run twice each turn by default?

Authoring Inform 7
1

I was trying to make use of some timed scenes (i.e. those ending when a certain time since <scene> began... value was reached) in 6M62 and found that they weren’t acting the way that I expected them to.

The reason seems to be that (as noted in other posts) the turn sequence rulebook has two nameless rules that trigger the scene changing rules – the specific issue seems to be that the two invocations of the rulebook happen on either side of the advance time rule. This means that the time since... value is changing between the two invocations.

Is there any particular reason that the scene changing rules are being called twice by the turn sequence rules? What is the logic of their current placement?

If I’m reading the logic of DetectSceneChange() (which is the I6 routine behind the scene change machinery rule) correctly, then any triggered scene change will automatically result in the routine being run again, until either no scene changes result or it has called itself 20 times (in which case it spits out the message ">--> The scene change machinery is stuck." and halts). Given that logic, is there any reason to be calling the scene changing rules more than once per turn?

Also, for those working with 10.1: Does it still work this way in the new version? (EDIT: Yes, this still works this way in 10.1.)

1 Like
2

I can’t recall having ever seen an official explanation. But scenes’ utility would be reduced if their starts and ends were checked less often. And complication would grow (and in a big game, things might grow slow) if they were checked too often. So I’ve always figured it was simply arrived at as a happy medium, strategically placed after the end of each action, reasonably expected to be the biggest engine of state-change in a game, and then again after the advance time and update chronological record rules to facilitate considerations of turns/time since or was/had been state changes.

I once went to the bother of re-implementing Scenes (my version was a Sitch) with phrases to explicitly start and end them at some given moment, rather than giving them preconditions that were checked at specific points in the turn sequence (this wasn’t difficult and doesn’t take much code). For what it’s worth, I ultimately concluded that scenes as designed were a pretty good idea and abandoned the Sitch strategy.

3

To be clear, I’m not contesting the design of the scene system itself – I’m trying to understand the reasoning behind running the scene changing rules twice during the turn sequence rules, in the spirit of learning to work with the system instead of against it.

By default, the turn sequence rules are set up as:

  1. parse command rule - get player input from prompt and parse into action
  2. declare everything initially unmentioned rule - clear mentioned status globally in preparation for new turn
  3. generate action rule - resolve parsed action within world model via action processing
  4. [unnamed scene change check rule #1] - check for scene changes and run any when <scene> begins or when <scene> ends rules
  5. every turn stage rule - runs the every turn rulebook
  6. timed events rule - handle any At the time when... rules
  7. advance time rule - update the turn count and time of day globals
  8. update chronological records rule - update status for all past tense conditions used in the story
  9. [unnamed scene change check rule #2] - check for scene changes and run any when <scene> begins or when <scene> ends rules (again)
  10. adjust light rule - determine whether the player has ambient light and run the printing the announcement of light or printing the announcement of darkness activities if there is a change from the last check
  11. note object acquisitions rule - set the moved status of anything directly held by the player (something also done by the taking action), remove the undescribed property for anything in player inventory, and update the active player's holdall if the story allows these

Your point about the chronological records update is one to consider. In thinking about this I’ve come up with other questions that call for consideration:

  • What is the best way to define the relationship between the turn sequence rules, player-perceived time units (i.e. command prompt to command prompt cycles) and game turns/minutes?
  • Which world states should scene start/end rules be able to rely upon as being stable within a given cycle, and which cycle is the right one with which to align the checks for those rules?
  • Should different rules apply to past world states (i.e those accessed via conditions using was/has been/had been)?
  • Should different rules apply to out-of-world states (e.g. score)?
  • When should timed events happen relative to the actual change in time and other state changes?
  • When should chronological records be updated relative to other state changes?

By the Standard Rules, turn sequence is aligned with player-perceived time units (because the first rule in the turn sequence rules is the parse command rule), but it’s out of sync with game time (which changes at invocation of the advance time rule). As a result, neither time of day nor turn count is stable from the perspective of either turn sequence or player-perceived time (and the same applies to measures derived from them).

I’m curious about everyone’s intuitive sense of how these cycles should line up, and what range of reasonable answers can be put forth for the questions above.

1 Like
4

I don’t understand why you would want fewer scene-change checks. If your scene-ending condition is something which is brought about by a player action, then you don’t want the every turn rules to run before the game notices. Similarly, if it’s something which is connected to a timed event, you want the game to notice before giving another command prompt. That means that two checks are the minimum, and that is what the default is. You can add checks at other points if you have non-standard scene-end conditions that warrant them.

2 Likes
5

The two checks on either side of the advance time rule make it difficult to anticipate when scene start and end logic relying on time of day or turn count or values derived from them will trigger. A simple scenario to illustrate:

"Scene Logic"

Place is a room.

A firework is here. The firework can be ignited. Understand "fountain" as the firework.

Instead of burning the firework:
    now the firework is ignited;
    say "The fuse sputters and hisses, growing shorter by the second."

Fountain Spray is a scene. "With a whuff, the firework begins to spray a multicolored fountain of sparks."

Fountain Spray begins when the firework is ignited for one turn. [version A]
Fountain Spray ends when the time since Fountain Spray began is one minute.

When Fountain Spray ends:
    now the firework is not ignited;
    say "The fountain gutters out."

Test me with "burn firework / z / z".

I would naively expect the transcript of the test me to look like the following:

>test me
(Testing.)

>[1] burn firework
The fuse sputters and hisses, growing shorter by the second.

>[2] z
Time passes.

With a whuff, the firework begins to spray a multicolored fountain of sparks.

>[3] z
Time passes.

The fountain gutters out.

Instead, compilation on 6M62 produces:

>test me
(Testing.)

>[1] burn firework
The fuse sputters and hisses, growing shorter by the second.

With a whuff, the firework begins to spray a multicolored fountain of sparks.

The fountain gutters out.

>[2] z
Time passes.

>[3] z
Time passes.

Everything happening on the same turn is surprising to me, given the setup. The scene begins with the first check on the first turn and ends with the second check on the first turn.

A modification:

Fountain Spray begins when the firework is ignited for two turns. [version B]
Fountain Spray ends when the time since Fountain Spray began is one minute.

which yields:

>test me
(Testing.)

>[1] burn firework
The fuse sputters and hisses, growing shorter by the second.

With a whuff, the firework begins to spray a multicolored fountain of sparks.

>[2] z
Time passes.

The fountain gutters out.

>[3] z
Time passes.

The scene begins with the second check of the first turn and ends with the second check of the second turn.

Another variation:

Fountain Spray begins when the firework is ignited for one turn. [version C]
Fountain Spray ends when the time since Fountain Spray began is two minutes.

which yields:

>test me
(Testing.)

>[1] burn firework
The fuse sputters and hisses, growing shorter by the second.

With a whuff, the firework begins to spray a multicolored fountain of sparks.

>[2] z
Time passes.

The fountain gutters out.

>[3] z
Time passes.

The output looks identical to version B in this case but would not if there were every turn rules that applied. The scene begins with the first check of the first turn and ends with the second check of the second turn.

Another variant:

Fountain Spray begins when the firework is ignited for two turns. [version D]
Fountain Spray ends when the time since Fountain Spray began is two minutes.

with result:

>test me
(Testing.)

>[1] burn firework
The fuse sputters and hisses, growing shorter by the second.

With a whuff, the firework begins to spray a multicolored fountain of sparks.

>[2] z
Time passes.

>[3] z
Time passes.

The fountain gutters out.

The scene starts with the second check of the first turn and ends with the second check of the third turn.

WWI 10.2 explains:

In theory any condition can be used to cue the scene - here, it’s “the player is in the Station for the third turn” - but it’s wise to look for a state of affairs which will last at least a brief time, because scene changes only happen at the start and end of turns.

but it doesn’t go into any detail about the placement of checks with respect to timekeeping.

It doesn’t seem like using time-related values to trigger scene changes is intended to be undesirable. I note that WWI 10.2 also introduces a time-based condition (“Train Stop begins when the player is in the Station for the third turn.”) as an example scene start condition, and WWI 10.3 continues with a time-based scene end condition, plus various time-related phrases.

WWI 10.4 introduces qualifying on the current scene in conditions, for use in rule preambles. But the every turn rules won’t be checked until after the first scene change check of the turn sequence, so it’s important to know which check (first or second for a turn sequence) will cause the scene in question to start or end. Likewise for the if <scene> has happened... and related conditions in this section.

If there were only one scene change check per cycle, then the reliability of time-related values as scene start and end triggers would be increased, because there would be a single stable value of each time-related value that could be applicable within the scene changes for a given turn sequence.

1 Like
6

It may help to think of this from the bottom up, rather than the top down.

If you write “Pentascene begins when the jar contains 5 coins”, in some sense you want it to start as soon as the fifth coin enters the jar. We sometimes get a question from a beginning I7 author who really expects this. They write an action rule which contains now the copper coin is in the jar; that’s the fifth coin; why doesn’t the scene start at that line of code?

In fact it would be pretty awful if I7 worked this way. Your “When Pentascene begins” rulebook would run in the middle of the action. The outputs could get intermingled in a sucky way. So we don’t want that. But we do want the scene to start as soon as reasonably possible after that line of code. As Zed says, the happy medium is to check when every action is complete.

And then the end-of-turn rules count as virtually an action for this purpose. (If an every-turn rule moved a coin, you wouldn’t want the scene to be delayed until after the player’s next turn.)

1 Like
7

I think a moral of this story is that Scenes and number-of-turns-based conditions are just a bad mix, for all the trouble and potential for error you’re citing. And time-based conditions aren’t much better.

I think I would’ve gotten Scenes sooner if the docs didn’t frame them so much as being about time: I think a more useful framing is that they’re about arbitrary game state. (I’m not calling the time-centric framing wrong, but it was an emphasis that distracted me, personally, from seeing how to use Scenes in a way I think plays to their strengths.)

8

I’ve got a big directory of the documentation examples, the Friends extensions, other extensions, and lots of published-source games – the I7 Standard Examples, Kerkerkruip, Counterfeit Monkey, Scroll Thief, The Weight of the Soul, and more. I grep the directory to variously find the right usage for something I’m trying to do, or just see how people have used something. Looking for scene beginning/ending definitions involving turn counts or time durations, one sees them in a few examples and in five out of the six I7 Standard Examples. And there are a handful in Counterfeit Monkey.

So I agree with you that it wasn’t conceived as being something to avoid. But it’s feeling like others have concluded that on their own.

1 Like
9

Agreed.

An interesting point. If every turn rules are virtually an action, why not put the scene change check after both action processing and every turn? With the current structure the naive user perhaps still faces unexpected complications:

"Scene Logic"

Place is a room.

A container called a jar is here.

A coin is a kind of thing. The player carries five coins.

Pentascene is a scene. "The jar begins to glow."

Pentascene begins when the jar contains at least five coins.

Pentascene ends when the jar contains less than five coins.

When Pentascene ends:
    say "The jar's glow fades to nothing."

Every turn during Pentascene:
    now a random coin in jar is off-stage;
    say "One of the coins disappears in a puff of smoke."

Test me with "put coins in jar / z".

yields:

>[1] put coins in jar
coin: Done.
coin: Done.
coin: Done.
coin: Done.
coin: Done.

The jar begins to glow.

One of the coins disappears in a puff of smoke.

The jar's glow fades to nothing.

>[2] z
Time passes.

The scene starts in the first check of the first turn and ends in the second check of the first turn, because scene change checks occur on either side of the every turn rules. Again, the naive expectation is that the scene would end the turn after the coins are inserted. By default spatial conditions aren’t stable between scene change checks in a turn sequence, either.

EDIT: With WWI 10.2 warning that scene change checks happen twice in a cycle, perhaps this behavior shouldn’t be unexpected. My point is that it’s not clear exactly why this works as it does until one knows enough to be able to inspect and understand the turn sequence rulebook and its rules. (Though I suppose that’s true for the Standard Rules in general.)

10

Assume for the sake of argument that WWI is amended to say “Don’t use time-based conditions to start or end scenes; they won’t work like you expect them to because scene changing rules are checked twice each turn and time-related values change between the checks.”

The implication would be that the system as currently set up works predictably for triggers based on “physical” conditions (i.e. conditions based on spatial or other non-time world model state) instead of temporal conditions.

The current setup seems to create two different sets of conditions that are effectively each checked as a group.

The first check is most immediately responsive to:

  • changes in lighting condition (as occurred during the previous turn sequence),
  • changes to moved status of objects (as changed due to placement in player inventory through means other than taking in the previous turn sequence),
  • physical rearrangement resulting from player actions (in the current turn sequence), and
  • scene is happening status as set by the second check of the previous turn sequence (plus scene status changes occurring during this scene check due to the way that DetectSceneChange() works).

The second check is most immediately responsive to:

  • physical rearrangement resulting from every turn rules in the current turn sequence,
  • physical rearrangement resulting from timed events in the current turn sequence,
  • times and durations as set during the current turn sequence,
  • chronological records as set during the current turn sequence, and
  • scene status as set by the first check of the current turn sequence.

Of course each scene change check will be responsive to any condition from either condition group. Without looking more deeply at this, it’s easy to craft a scene change trigger like:

Grue Anxiety begins when in darkness and the player does not carry the flashlight. "Uh-oh. Watch out for grues!"

It seems like most people think that scene should start as soon as the player drops the flashlight (which is the sole light source) down a crevasse, due to the scene change check immediately following action processing (i.e. first check of the turn sequence). Instead:

>DROP FLASHLIGHT INTO CREVASSE
The flashlight plummets into the crevasse, soon disappearing from sight. You hear no impact.

It is now pitch dark in here!

>Z
Time passes.

Uh-oh. Watch out for grues!

The scene change occurs on the first check of the following turn, because the adjust light rule is placed after the second scene change check in the turn sequence rules.

1 Like
11

This is some really good documentation on how to think about scenes while structuring your code!

I think it’s in the nature of the beast that no matter how we arrange things, it’ll be easy to come up with some regrettable consequence. Suppose we switched the order of the adjust light rule and the second scene change check. Now the scene change can be sensitive to the plunge into darkness and avoid the situation you cite… but if a when scene begins rule caused the flashlight to plummet into the crevasse, you wouldn’t get the “It is now pitch dark in here!” message from the Adjust Light rule until after the following action.

In even a small game it’d be untenably slow to check all the things we might want to after any given thing that might have changed game state. So we compromise and leave it to the author to manually patch any resulting infelicities. If you really need a scene’s start to be triggered by plunging into darkness, After printing the announcement of darkness, follow the scene changing rules. should do it (among other possibilities).

[Edited to add: Of course I know you, personally, don’t need schooling in how it could be accomplished, Otis; spelling out an example was my well-intentioned attempt to try to keep it useful to less experienced people stumbling on this thread…]

12

There’s a bit of documentation on these decisions in the Standard Rules:

The “first” rules in the turn sequence cover us up to the end of the events which take place in the model world during this turn’s action(s). […] We then run the scene changing rulebook, because people often write every turn rules which are predicated on particular scenes (“Every turn during the Grand Waltz: …”), and such rules will fail if we haven’t kept up with possible scene changes arising from something done in the action(s) just completed.

We now come to the rules anchored at the end, using “last”. This part of the rulebook is reserved for book-keeping which has to happen positively at the end of the turn. First, we check for scene changes again. We did this only a short while ago, but scene changes might well have arisen as a result of rules which fired during the every turn rulebook, or from timed events, or in some other way, and it’s important to start the next turn in the correct scene — so we check again to make sure.

In other words, the designers’ intent seems to have been that scenes can respond to changes in world state from actions or from every-turn rules, which are the two main ways the state can be affected.

(You may have looked at this already, but it seems useful to have in the thread for reference.)

3 Likes
13

No, I hadn’t seen that; I’m still mostly rooted in the 6M62 world, and I don’t think there’s any documentation on the Standard Rules that was provided for it. Thank you for pointing to this reference!

As Zed points out, every choice in how the turn sequence rules are arranged results in trade-offs, creating strengths and weaknesses. I think my question has implicitly been about what strengths are being created by the current setup, and whether any accompanying weaknesses (e.g. effectively removing time-based conditions as a useful option) are being deliberately chosen.

I think that passage does a great job of explaining the logic of the design choice, so I will mark this as solved. (I’m picking Draconis’s answer for the citation even though everyone else responding seems to have deduced the same logic.)

2 Likes
14

This is super helpful, thanks for sharing!

I’ll say as a not-too-technically-sophisticated author, I’ve run afoul of some of the wonkiness documented here, but while not fully understanding what was going on, I found it pretty easy to just trial-and-error my way through by doing things like changing events to fire in two turns rather than one turn. So while the back end machinery was indeed somewhat confusing in the absence of this documentation, at least in my experience it was pretty easy to diagnose and fix the issue, which I guess is a vote in favor of the current design approach.