A Gripe (rant)

Authoring Inform 7
1

This whole business of having an object vocabulary or printed name be the same as some other word in the code (such as a kind or a value) is a huge and grotesque stumbling block. It makes authoring easier for the beginner, but in a more complex game it causes no end of trouble. Right now the compiler is choking because I’ve written both “a level is a kind of value” and “Through the main-stairwell door is the Stairwell Main Level.”. The word “Level” is okay as a room name, but when I try to use the room name in a description of a door direction, the compiler chokes and dies.

The workaround, of course, is to add a bunch of hyphens to the names of things, make the things privately named, and add vocabulary as needed using “Understand … as.” This is just a bunch of extra work.

I could give other examples. Apparently (this is in 6M62) you can’t have two different red buttons in your game, not even if you consistently call one of them a large red button.

None of this is a problem in TADS, because TADS object names all have to be unique, but they’re never used to construct in-game vocabulary. Inform tries to be friendly for the author – and it fails.

2 Likes
2

Hush hush… there there…

Here, have some saltwater taffy and a rootbeer float. Things are always better after saltwater taffy and a rootbeer float.

Okay?

3 Likes
3

Being a vulgar heretic, I’ve toyed with the notion of writing a pre-processor that would let me specify world model objects in a YAML file from which I7 would be generated. The actual game objects would get ugly names, prefixed with a sigil; everything would be privately-named. Something like:

rooms:
  Lab:
    description: "Mad scientist's lair"
    printed_name: "The Lab"
    understood_as:
    - lab
things:
  large_red_button:
    description: "Big and red and waiting to be pressed"
    printed_name: "the large red button"
    understood_as:
    - large
    - red
    - button
    holder: Lab
    attributes:
      - fixed in place

which would then become ugly Inform 7:

'lab is a room.
"Mad scientist's lair".
The printed name of 'lab is "The Lab".
Understand "lab" as 'lab.
'large_red_button is a fixed in place thing.
The description of 'large_red_button is  "Big and red and waiting to be pressed".
The printed name of 'large_red_button is "the large red button".
Understand "large" or "red" or "button" as 'large_red_button.
'large_red_button is in 'lab.

(Created at the speed of typing… I make no claim that the YAML or I7 is correct.)

The output could be written directly to an extension file that the story file would include.

While I’m being vulgar, there could even be different sigils for each of things, rooms, and regions. (I don’t think I need an extra level of indirection for directions.) Maybe another for objects that aren’t a thing, room, region, or direction. Or even another for author-created kinds of value. Or, coming back to my senses at least part-way, maybe just one for things and one for rooms.

3 Likes
4

I’m acquired a habit of suffixing my kinds of values’ names with “-value” 'cause even independent of consideration of avoiding stumping the compiler, I found that when I didn’t, things inevitably proceeded like:

Color is a kind of value. The colors are red, green, blue.

Ink is a kind of thing. An ink has a color called

crap. what do I call it? I wish I could just call it “color”, but I can’t.
umm, ok, I guess ink-color isn’t too bad.

With my -value habit, I’d just say An ink has a color-value called color and best of all spend less time thinking about naming things. (ABRCL: always be reducing cognitive load.)

4 Likes
5

I suggest that you get familiar with the called... construction for providing object names. It’s first mentioned in WWI 3.2 Rooms and the map. A brief scenario with the following compiles with no trouble:

Color is a kind of value. The colors are red, orange, yellow, green, blue and purple.

A control panel is here.

A thing called a red color button is part of the control panel.

A thing called a blue color button is part of the control panel.

The compiler ignores potential name conflicts when that construction is used.

2 Likes
6

As far as that goes, you can just say:

Ink is a kind of thing. Ink has a color.

to create a “nameless” property for the ink kind holding a color. You can then say things like:

In the bottle is purple ink called some expensive ink.

and then extract the color property as though it were a property named after the kind of value:

Instead of touching ink:
    say "You don't want to stain your fingertip [color of noun]."
3 Likes
7

If I understood correctly, there’s an option for what you want, described at the end of section “Rooms and the map” in the chapter “Things” of the documentation:

Use unabbreviated object names.

This will make Inform recognise only the full name of objects in the source. So if you have:

Use unabbreviated object names.

The large red button is a thing.
The small red button is a thing.

Then you can only use large red button and small red button in the source to refer to these things.

You have to be careful to always use the full names though, because if you use a bare red button in the source, then it will refer to a third, different object.

2 Likes
8

You may be right. I’ll have to look at that. The trouble is, since I already have 20,000+ words of code, adding that line would hose quite a lot of stuff that’s working now.

9

Yeah, I don’t really recommend using that in a big existing project. Unless you are willing to review the index and the full source to make sure no objects were created in the process of adding the option. And if you are really sure of yourself.

10

On the plus side, if you save the list of objects beforehand, you can diff it with the list afterward, then ctrl-F for any new names that appeared and fix them.

11

Thanks. I’ve gotten so in the habit of always naming my properties that I’d kind of forgotten there are some advantages to anonymous ones.