top expert

Methods for varying text.

last time, on Let’s Make IF.

As a reminder, we’re working on a small project that has multiple endings with a significant amount of text variation. My goal is to share source code for a sizable portion of the game. Once the code gets sent to testers, we’ll black out until it is entered in Spring Thing as a “back garden” entry. Once Spring Thing begins, the entire source will be shared along with the game.

We didn’t get too far last time. I made a room with only a few objects: a light, a table, and two differently-colored balls. It looks like this:

Portrait With Wolf ^_^
A fun activity by Drew Cook
Release 0 / Serial number 240827 / Inform 7 v10.1.2 / D

A Brightly Lit Room!
A bare place. A bright light emerges from an unknown source above.

A small metal table stands under the light. It is covered in gray, chipped paint. The following items rest atop it:
  a blue ball
  a red ball

Not a lot to see just yet! My design goal is have few things will a large number of possible descriptions. For our near-term purposes, we’re only going to implement a room and possibly eight objects.

changing things up.

Almost any printed text can be variable. It can be substituted, too (we talked about substitutions last time). Some complex substitutions might make things weird, but we aren’t interested in that kind of thing. We’re just focusing on text, which is generally safe to tinker with. If you had a peek at last week’s source code, you may have noticed a change. This code from the post…

ABR is a room.
the printed name of ABR is "A Brightly Lit Room!"

was updated to this in the shared source:

ABR is a room.
the printed name of ABR is "[one of]A Brightly Lit Room![or]Bright Room[or]Lit Room[cycling]"

The “[ONE OF]… [OR]…” construction is a common way to vary text without setting up separate logic, counters, or what not. By [ONE OF], we simply mean “one of the following options.” Those options are separated by [OR]. There are multiple ways of ending a series like this. The [CYCLING], as used above, tells Inform to print the options in order. Every time the name of ABR is printed, Inform will print the next listed text. Once the end of the list is reach, Inform will cycle through again, beginning at the first option once more.

[STOPPING] is another common way to end a [ONE OF] construction. In such cases, once Inform reaches the end of the series, it will always print the last option in the list.

There are also several possibilities for printing the options at random. You can review [ONE OF] features here in the documentation.

Something to note with changing the printed name of a room: the room name doesn’t just print whenever the player looks. It’s printing all of the time! By default, the room name is always displayed in the status bar at the top of the screen.

As-is, the contents of the status bar will change every turn, because the printed name uses our [ONE OF] construction. That’s more than we want, probably, We could get around this two ways. Well, lots of ways, actually, but let’s consider two.

The first is to customize the status bar. This isn’t too tricky.

when play begins:
	now the left hand status line is "A Mysterious Locale";

We can change the status line during action processing. “WHEN PLAY BEGINS” seems like a good time for that. Note that the convention is for the current location to print in the status line, so this might be confusing to players. More information about the status line can be found here.

Since substitutions are supported here, too, we could come up with an elaborate way to print alternate room names in the status line, but that seems a bit rich, doesn’t it? Perhaps we could just use something other than [ONE OF] to vary our room names.

using a list of adjectives.

These next approaches aren’t great for a large number of options, but they will illustrate some important concepts that will help us get to a working solution. To start, we need some variable thing that we can use to decide what to print. Inform allows for many possibilities. As one option, we could use adjectives as values. Those read well.

phase is a kind of value.
the phases are beginning, intermediate, and concluding.

We’re speaking in generalities here. Nothing has been assigned a “phase” yet. We can do that easily. We can give any in-game thing a phase, then use it to keep track of the nature of that thing. In this case, though, let’s cook up a variable.

print order is a phase that varies.
print order is beginning.

Since “print order” varies, we are simply stating that its starting value is “beginning.” Let’s change our substitution for the printed name of the room, using our new variable.

the printed name of ABR is "[if print order is beginning]A Brightly Lit Room![otherwise if print order is intermediate]Bright Room[otherwise if print order is concluding]Lit Room[otherwise]This is an error condition that should never arise. Please let the author know that you found a problem printing the name of ABR."

We are using [OTHERWISE…] conditions in sequence, which means the first match will print. There should only be one match, anyway. The final is an error trap. Our code will hopefully prevent it from printing.

What code is that? We need some sort of logic to tell Inform when the “print order” should change. We also need to decide WHEN it should change. Since we are doing this after looking, we will likely want a REPORT rule. In fact, we should make it a LAST rule to avoid tripping over the LOOK action. LAST REPORT means exactly that: our rule will be the last REPORT LOOKING rule to execute.

How about something like this:

last report looking:
	let the current phase be print order;
	if print order is last value of phase:
		now print order is first value of phase;
	otherwise:
		now print order is the phase after the current phase.

Inform is smart enough to think about the order in which we initially set up our “phase” value, so we can say things like “the phase after”, “phase before”, “first value”, and “last value”.

The “let the current phase”… construction isn’t necessary, but it makes for more readable code. Without it, we’d have to say…

now print order is the phase after print order

It’s a matter of personal preference. I prefer using temporary variables (that’s what the LET construction is) when they allow me to make more readable phrases (lines of Inform code).

using a number instead.

A less readable–though probably more scalable–option would be to use a number. Mechanically, things look different but operate in a similar fashion. Note that my habit as a writer is to write some numbers as words. Using numerical characters works just fine.

print order is a number that varies.
print order is one.

last report looking:
	if print order is three:
		now print order is one;
	otherwise:
		increment print order.

the printed name of ABR is "[if print order is one]A Brightly Lit Room![otherwise if print order is two]Bright Room[otherwise if print order is three]Lit Room"

Note the use of the phrase “INCREMENT PRINT ORDER”. It does what it says, as it will increase the number by one.

This is the better option when there are many possibilities. Keeping track of ten adjectives, for instance, might be a bit of a headache. Using numbers may also simplify our use of tables, should we choose to do so.

And we just might! But not just yet. This is supposed to be a fortune telling game (have I said that already?). Next time we’ll do a little work on designing systems for that.

As always, feel free to get in touch with questions, or just to chat about Inform 7.

today’s source

next.

card-picking is an action applying to one thing.

other.

Do you follow the weekly IF ‘zine What’s New in IF? I was interviewed there a couple of weeks ago. Here’s a PDF of the issue. I talk about making games, criticism, and yes, my work here at Top Expert. Check it out! And consider following the zine, they’re a bunch of great people.

What’s New in IF? – 2024 Zines by What’s New in IF? (itch.io)