let’s make IF: what a scene.

Scenes as an alternative to countdown numbers.

obligatory.

“lets make IF” is a series of Tumblr posts about my experiences as a beginning Inform 7 author. I have written one game, and I’m working on two others. When I first started writing about Inform 7, I felt intimidated by some of the available information. I thought: why not write as a beginner, for beginners? Need more Inform 7 resources?

Reminder: since this is a competition game, I cannot provide full source code or extended gameplay excerpts. Examples have been modified in order to avoid spoiling the competition release.

moving on.

This post is a culmination of lots of topics I’ve covered here and on tumblr. If you find yourself scratching your head, try going back through those posts. I’ll be dealing with the following topics:

Tables
Scenes
Action processing in general (getting rules in the right order, knowing what to expect in terms of text printing and so forth)

I’ve covered a few issues in this series:

Creating forward momentum by destroying rooms
Using every turn rules and a number called “countdown” that changes every turn
Using a scene as an alternative to a number
Using “after” and “before” rules to check and update information in tables while actions are processed

To speak truthfully, I haven’t been fully satisfied with either of my approches (scene or number). After returning to my project, I have come up with what I hope will be my final take on the collapsing cave complex problem.

and the winner is… scenes.

As the Inform 7 documentation observes, variables and various broad rules could do everything that scenes do. Why even use a scene? The first and most simple reason is that they are native to Inform 7. I don’t need to build anything. Learning about scenes is learning about Inform, and that’s what this blog is all about! That’s not all: since scenes are in the project Index, I have a clickable reference that allows me to jump to all of my scenes in the source code. I can also see how they are arranged in what Inform 7 calls the “plot.” Here’s a visualization of the scenes in my current project (so far).

If something isn’t working, I can go straight to it. If something isn’t linked the way I expect, I can check that in the Index. Scenes are a powerful tool that takes advantage of Inform 7’s built in Index.

setting the stage.

My example in a previous post was a bit of spitballing; it didn’t account for many situations. I’ll lay out our requirements once more and try to come up with a best (for me, anyway) and final approach.

Objective: write a prologue for an Inform 7 text adventure that engenders a sense of urgency while giving the player time to perform basic tasks (examining, etc)
- Most rooms should collapse upon exiting. This should be a one-way trip.
- There should be two types of room: some should collapse after a specified number of turns, while others should print ambient text.
- When a room collapses after a specified number of turns, the player will “try going” to the next room. Player death will not be a part of this solution.
- The full gamut of action processing rules (before, instead, check, carry out, after, report) should be used whenever possible, since we have after and before rules running in almost every turn.
- Multiple conditions for printing text: score, goals, state of a scene.
- Ability to follow custom rules while printing conditional text.
- Ability to deal with complications that come from having the player go somewhere in-scene (more on this below).

That seems like a lot! Don’t worry, I’ll take my time. I should start with two fundamental features. Most rooms collapse upon exiting, and players can exit in one of two ways. They can simply walk out in the usual way, typing a command to walk in a given direction, or they can be driven out when the room collapses. Mechanically, how would we do this? Let’s start, as we always do, with a room.

pod is a room.
the printed name of pod is "Point of Departure".
the description of pod is "You begin here, in a rather unstable-looking cavern."

I can make a scene, too. Let’s not worry about ending it just yet. Having a name will be good enough for now.

pod timer is a scene.
pod timer begins when play begins.

This is enough to start writing some ambient text. I’ll figure out what to do when time runs out in a minute. Note my use of the TE temporary variable! Such practices will save me some typing.

every turn when pod timer is happening (this is the pod timer rule):
	let TE be time since pod timer began;
	say "[if te is zero minutes][run paragraph on][otherwise if te is one minute]This cave shudders ominously.[otherwise if te is two minutes]Bits of gravel fall from the ceiling.[otherwise if te is three minutes]Another aftershock shakes the room. This place is coming apart![otherwise if te is greater than four minutes]You have encountered a bug. Please let Drew know about this problem with the pod timer rule.".

So far, little has changed from my previous example. However, I used death as a solution. Death is a bit of an easy way out. I don’t have to deal with evolving complexity. Instead, I can just shut things down. It isn’t a good solution for this project: my goal is to create and sustain momentum. Ending the game dispels that sense of movement, so I should do something else. Instead of ending the game, I would like to move the player to the next room. I don’t have one, so let’s make it.

ib is south of pod.
the printed name of ib is "In Between".
the description of ib is "This medial location is in an increasingly dangerous cavern."

Let’s not worry about an every turn rule just yet. I just need a destination for the player.

when the party’s over.

When the room collapses, I want to the player to leave (as in the action going somewhere). I also want the current scene to end, so that we can start a new scene for the new room. I could just drop the player in the new location:

move the player to ib;

The problem there is that I already have a framework based around checking player actions. I should do what I can within action processing. As you can probably see, I left a gap in my every turn rule: when te is four. How should I approach this? Since I am trying to use all of action processing, I want to be selective with my use of “instead” rules. Why? Because they shut down the rest of the turn. My “after” rules will never execute, for instance, and I spent a lot of time with those!

In this project, I will mostly use “instead” for one purpose: executing other actions that can have their own go at action processing. In this case (to start):

instead of doing anything other than going south from pod when pod timer is happening:
	if time since pod timer began is four minutes:
		try going south;
	otherwise:
		continue the action.

Why does it look this way? Truthfully, I could have put the “if” phrase in the initial “instead” rule. I only broke it up because it’s a) more readable this way and b) it’s easy to add to if I want. What about the “anything other than going south” condition? In this case, I could easily set up a recursive loop with our “instead command.” Instead of going south, the player would try to go south, and instead of doing that, the player would try to go south, and so forth. So I exclude it from my rule.

That should all work. The player will head south after the specified time, or else will leave on their own. By adding an end to the scene…

pod timer ends when the player is in ib for the first time.

…I now have a little working snippet of code. You can view (and run) it here. Note that I’ve organized code by headings. Why? I can put all scene-related code in one place and pick it up in the Index. Check it out for yourself!

next.

That isn’t all! I need a good handoff from one scene to another. Also, the text isn’t very dynamic yet. What about transitions between rooms, for instance?