Contextually Shifting Descriptions in Inform 7

Authoring Inform 7
1

This perhaps goes more in general design discussion but it’s also specific to Inform 7. So I’ll put it here and see how that goes. There is an Inform 7 implementation question here, which is why this felt like the better place.

In my latest classes that use text-based IF, I find a lot of people really want to do what I would call contextual knowledge descriptions for locations. As an example, consider a slightly modified example from the game Reliques:

Longwall Street is a room. “Almost overgrown in the deep forest, collapsed and at once standing, the cyclopean east-west Longwall of the fallen city sinks here to a mostly flat, lichened stone clearing. You figure that it must once have been a customs post or something very much like that. To the west, an old wall turret like a broken chess piece still seems enterable by a dark doorway, whereas the eastern side of the wall’s gap is only a shapeless ramp of masonry. Northwards, to what was once the interior, stubborn, wiry trees grapple with ancient pavings.”

Easy enough. Now the bare minimum writers like to do is something like this:

Longwall Street is a room. “[if unvisited]Almost overgrown in the deep forest, collapsed and at once standing, the cyclopean east-west Longwall of the fallen city sinks here to a mostly flat, lichened stone clearing. You figure that it must once have been a customs post or something very much like that.[paragraph break]To the west, an old wall turret like a broken chess piece still seems enterable by a dark doorway, whereas the eastern side of the wall’s gap is only a shapeless ramp of masonry. Northwards, to what was once the interior, stubborn, wiry trees grapple with ancient pavings.[else]OTHER TEXT HERE.”

You can see I just added a check for unvisited and then they will fill in the suitable text for “OTHER TEXT HERE”.

But where things get complicated is that people also want to be able to indicate whether the player has been to a place before. The logic to this is sound in that if we were truly describing something, that would factor in to how we describe it.

So consider that the OTHER TEXT HERE might be replaced with:

“To the west is the old wall turret and to the east is the stond mound.”

Here I’m being as simple as possible. Basically just an abbreviated list of where you can go and what’s there. Easy enough.

However, if the player has been to one of those locations, that description might change. For example, consider if they have been to the stone mound but not the turret:

“To the west is the old wall turret and to the east is the stond mound you climbed up before.”

Likewise, though, maybe the player went to the old turret at this point but not the stone mound:

“To the west is the wall turret you visited and to the east is the stond mound.”

And, of course, there’s the situation where the player has been to both:

“To the west is the wall turret you visited and to the east is the stond mound you climbed up before.”

Conceptually, this can make sense and can give vibrancy to the story in the sense that the protagonist’s description is being changed based on what they have visited prior since their contextual knowledge of the world has now grown. Something that was unknown or only vague may now be known and specific.

The question is: how would you implement this in Inform where it’s not a huge mess of ugly code?

There may be many different possibilities. It’s essentially treating knowledge as a conditional and applying that to descriptions. I’m just curious to see what people think makes the most sense, particularly when a key aspect of this would be the ability of an author to make the descriptions of the world as variable as possible given what the player has seen.

1 Like
2

Technically, I think I’d do something like this.

A room has some text called the unvisited summary.
The unvisited summary of a room is usually "[a lowercase item described]".
A room has some text called the visited summary.
The visited summary of a room is usually "[the lowercase item described]".

To say a/an lowercase (item - an object):
    let T be "[an item]";
    say "[T in lower case]".
To say the lowercase (item - an object):
    let T be "[the item]";
    say "[T in lower case]".

To say summarize (the place - a room):
    if the place is visited, say the visited summary of the place;
    otherwise say the unvisited summary of the place.

Now you can do something like this:

The visited summary of the Crumbling Turret is "the ruined tower you climbed up earlier".

The description of the Plaza is "To the north is [summarize the Crumbling Turret]."

And the result will be either:

To the north is a crumbling turret.

To the north is the ruined tower you climbed up earlier.

(If you don’t specify a special summary text, the default will be “the [location name]” in all lowercase if it’s visited, and “a [location name]” in all lowercase if it’s not. The use of “a” versus “an” should be handled automatically.)

2 Likes
3

I’d probably follow Draconis’ path, but I’d stick a rulebook there instead, to customize the message if I wanted to. Then again, that’s the kind of thing I’d do in lieu of actually finishing a game.

3 Likes
4

Interesting. Thank you!

I find this mostly works. As a note for others who might want to implement, it does give an error if you look when you haven’t been to a location yet. The error is:

Run-time problem P47 (at paragraph 1 in the source text): Phrase applied to an incompatible kind of value.

For example, consider this source (shortening the text considerably and with the assumption that the solution provided is in place):

Longwall Street is a room. “[if unvisited]Almost overgrown … ancient pavings.[else]To the east is [summarize the Turret Roundhouse].”

Turret Roundhouse is a room. “This broad … a lookout.”

The visited summary of the Turret Roundhouse is “the dark and musty roundhouse”.

In this case, if you go to the Turret Roundhouse, then go back to Longwall Street, the text prints correctly. However, if you look once in Longwall Street and then – crucially – look again, you will get the above error. (Or just type look as your first command in Longwall Street.)

However, I would think this would work since there is a usually qualifier applied to the unvisited text, which it seems is what the error is referring to. If I add the following line, everything works:

The unvisited summary of the Turret Roundhouse is “the turret roundhouse”.

So it seems I have to make sure to declare the unvisited summary as well, without relying on the fallback to the “usually” text. At least at a first glance.

I’ll play around a bit more but this solution is definitely on the right track for me.

1 Like
5

Ah, I think I figured it out. I had to change the following:

To say a/an lowercase (item - a room):
	let T be "[an item]";
	say "[T in lower case]".
	
To say the lowercase (item - a room):
	let T be "[the item]";
	say "[T in lower case]".

I changed from item - a thing to item - a room.

With that change in place, the usually text works correctly. It is interesting, however, why the problem didn’t happen all the time.

6

You could circumvent the type system by going “item - an object” for both phrases. What’s happening is that the room kind is not a thing, so your phrases can’t match the call for “item - a room” as such. Making them an object allows you to reuse the phrase for both rooms and things (however, it might be wise to provide alternate handling for things like values, numbers etc as well).

3 Likes
7

Oh, yeah, that’s an error on my part. I’ll edit my post.