top expert

putting the final touches on our room-collapsing scenes.

obligatory.

I am, as I always say, a beginner when it comes to Inform 7. I do not understand everything about it, and I probably never will. But I can still make games, and so can you! We can both figure things out as we go along. Feel free to ask me stuff.

previously, on let’s make IF.

This has been quite a long journey, and along the way we’ve talked about tables, action processing, tracking player objectives, and keeping track of time. It’s a lot, and if you’re just tuning in, you’re probably wondering what this is all about. That’s ok! Next time, I’ll do a refresher post on using tables and definitions to catch you up to speed. I think we can fit in some new tricks for regular readers as well. Please look forward to it!

Last time, I set up a scene that depicted a room in the process of collapsing. I used the scene to print ambient text based on the number of turns (minutes) that had passed since the scene begin. I also used this code to determine when the game would move the player to another room. But there remained work to do. How should this hook into the next scene (another room collapsing)? How could I print text to show the transition from room to room? Would that text be different depending on whether they left on their own vs being pushed out by the collapse? And so forth. If you need to look back:

let’s make IF: what a scene.

properties.

Last time, I shared a bit of transitional code that would push the player out of the room once a specific threshold was reached:

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

There’s nothing here for us to distinguish between leaving voluntarily vs reaching the four minute mandate. I can’t, for instance, say “when the current action is going south” because that will be true in both cases. Let’s make some properties for rooms. I think two would be enough, but I’ll make three just to keep my options open.

integrity is a kind of value.

This could be anything, I just chose this name because it made sense to me.

a room has an integrity.

Ok, every room has an integrity assigned to it. I’ll set the default in a minute, after we’ve said what the possible values are.

the plural of integrity is integrities.
the integrities are intact, collapsing, and collapsed.

Again, my choices.

a room is usually intact.

With that, we have a default state. Rooms are intact until I say otherwise. How can this be used? I’ll add this to my instead rule above:

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

Good! To summarize, I have a way to tell how/why the player is going south: scene or command. If the scene is responsible, the room will be flagged as “collapsing.” If the player has voluntarily moved south, the room will retain its default property, “intact.” We can use this for our transitional text.

These transitions are tricky. In the Standard Rules, the going action includes a report rule for looking (this is how/why going from one room to another prints a room description). I want the text to print before the room description for the new room. We have a great deal of flexibility, since report rules come second to last (just before every turn rules). I’m going to use a before rule.

before going west from damp passage:
	if damp passage is intact:
		say "As you exit the damp passage, the mossy stones spill from the channel, making any return impossible.";
	otherwise:
		say "The collapsed channel disgorges its mossy contents, and a river of damp stone falls into the passage. You barely make it through the western exit before the hall is hopelessly and permanently filled with rock.";

As the two passages indicate, I can give different feedback based on the integrity of the room.

transitions.

Let’s conclude the turn. It already includes before, instead, after (our custom goal setting and scoring rule), and every turn rules. That’s in addition to what the Standard Rules are already up to. Busy! As a reminder, if I had relied on instead rules for everything, none of this would have been feasible (or things would have been far more difficult, anyway). Try to use the entire spectrum of action processing rules when you can.

I think my last rule fits as a report. If my rule involved printing text, I’d have to worry about Inform printing the room description and my own before text. Since that isn’t the case, I can just let this report rule fire whenever it does.

report going west from damp passage:
	now damp passage is not east of junction;
	now damp passage is collapsed.

We don’t necessarily have to change the world map (“now damp passage is not east of junction”). An instead rule would be good enough:

instead of going east from junction:
	say "That way is forever closed off.".

However, what if I have a custom “you can’t go that way” response? Since the built-in error is a check rule, I will need either instead or before to get in front of it. If I’ve changed the map, I can use “going nowhere” to cover everything.

instead of going nowhere in junction:
	if the current action is going east:
		say "That way is forever closed off."
	otherwise:
		say "The only available exit lies to the *SOUTH*.".

If I don’t change the map, I’ll have to deal with going east as a special rule that fires before my generic “instead of going nowhere” rule. A “first instead” might be best, though a before with “instead” or “stop the action” might do. As always, experiment and see what makes the most sense for you.

I could take advantage of the “collapsed” state and leave the map be, but that isn’t my preference. Again, do what’s best for your project.

Lastly, the scene must end. Remember that we can’t begin and end scenes in action properties. Rather, they are triggered by conditions.

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

There are other options. I could use “when damp passage is collapsed.” I’ve chosen the player’s location as the determiner because it’s easy for me to read at a glance, rather than digging up custom rules. Also, since this series of scenes is about movement, it makes sense to build around that. Whatever your approach is, it is best to do everything the same way, and also to be consistent in terms of where you place code related to the scene. This is the way I organize every room in my current WIP:

In this example, chapter 5 contains everything related to the scene. Text printing, player movement, updating room property, and so forth. When I click the link in the index, everything will be together in one place.

what else.

I named some other requirements in a previous post. How could we use goal information to affect things? Perhaps we want to only start scenes when a specific goal is active.

major trouble is a scene.
major trouble begins when the big picture goal of the player is destroy the automobile and the sledgehammer is carried by the player.

or

endgame is a scene.
endgame begins when the score is 300.

Conditional text works, too.

every turn when major trouble is happening:
	if the big picture goal of the player is destroy the evidence:
		say "The police are almost certainly on their way. Time to get rid of the evidence!".

Using scenes and goals to print specific text is fairly straightforward. Once the systems are in place, execution is not too difficult. If you need a refresher on my implementation of player goals, you can find it here (part one) and here (part two).

next.

As promised, I think dropping back for some refreshers might be useful. I’ll return to tables and definitions, just to get new readers up to speed. Perhaps a bit of action processing would be useful, too. See you then!