[I7] Need help using "printed name" to prevent confusion with article

Authoring Inform 7
1

New-ish Inform writer here. I’m doing a game where the player needs to collect a full octave’s worth of bells for a task. I figured, to be kind to the player, I’d use a C scale, because everyone can remember that one: C, D, E, F, G, A, B.

I began with:
Pitch is a kind of value. The pitches are Aa, B, C, D, E, F, G, and untuned.
(One of the bells is found untuned, and can be tuned later.)
(This was the moment I realized I was in trouble: the note “A” looks like the indefinite article to the parser AND the player. Uh oh.)
A bell is a kind of thing. A bell has a pitch called the tuning. The tuning of a bell is usually untuned.

Ideally, I wanted these bells to be identical, so the user could only tell which was which by listening to them, but I realized that was more torture than it was worth. So I tried to define them this way:

On the workbench is a bell called A-bell with printed name "Bell A". The tuning of A-bell is Aa.
On the workbench is a bell called U-bell with printed name "Untuned bell". The tuning of U-bell is untuned.

This gave me the error: Problem. You wrote ‘On the workbench is a bell called A-bell with printed name “Bell A”’, but this seems to give something a name which contains double-quoted text, which is not allowed.
I am baffled, as the examples of using printed name all use quotation marks. What’s going on here?

I’m also making this thread not only about this one error, but to ask: can you forsee any other problems this “Bell A” naming scheme? I’m worried I may have gotten in over my head fighting the parser over this.

2

When you use “called”, Inform interprets everything until the next punctuation mark as part of the name. (This is intentional: “called” is the main way to ensure Inform doesn’t misinterpret a name as something else.)

So Inform thinks you’re making an object called “A-bell with printed name ‘Bell A’”, which isn’t allowed. Split it up into two sentences and the problem should go away.

1 Like
3

Thank you very much! Can you also speak to whether or not having the user type, for example, “x bell A” or “take bell A and bell B” might be problematic in edge cases in the future?

4

The only issue I can see is with the note “A” looking like the indefinite article “a”—but indefinite articles in IF are mainly only used with masses of indistinguishable objects, so that might not actually be a problem.

For precedent, Hadean Lands includes commands like “TAKE F SHARP CHIME”, though it avoids using A.

5

On purpose! I also avoided D and E. This is a long-standing principle of parser IF that we don’t talk about much… be careful of one-letter words that conflict with the defaults. :)

(I put in a G chime, but the G abbrevation for AGAIN is only recognized when it’s on a line by itself, so it wasn’t much of a clash.)

1 Like
6

Another option might be to use the solfege names—instead of single letters, name the chimes do, re, mi, fa, sol, la, ti. None of those are likely to conflict with anything.

If you want to give the bells different names before the player figures out the tuning, the classic technique is to give each one a unique adjective. Maybe they’re different colors, or made of different metals, or have different symbols engraved on them. (This technique goes back at least to Zork’s “nasty knife” vs “rusty knife”, but the most famous usage I can think of is in the Enchanter trilogy, with its wide array of adjectives for different scrolls.)

3 Likes