What is the "best practice" for similarly named things?

Say I have a room called cave entrance where you can enter a cave by going north, but I also want a scenery thing in the room so the player can examine it and enter it by typing “enter cave”. However, I’m not sure how I should name the thing, since “cave entrance” would clash with the name of the room.
Maybe in another situation, I have two generic trees, each in different rooms, both there for different interaction or flavor text or whatnot. How should I name each of the trees so they don’t clash with each other?
I’ve used the printed name property of the things, but I’m a bit worried about that, since that doesn’t override interaction with the given name of the things. Like if I called a tree “dirt path tree”, a player interacting with “dirt” might end up using the tree instead.

This isn’t specific to Inform, so take it with a grain of salt.

I ran into the same situation with a cave entrance. I tried to think about how you’d describe it from outside vs. inside, and settled on “mouth of cave” vs. “cave entrance.”

With things like trees, I decided that nearly identical objects are probably less interesting than objects that are somehow distinct, and went with descriptions like “gnarled oak” vs. “rotting pine,” with disambiguation for “tree” resolving to one or the other based on which one is in the same location as the player.

I’m curious how more experienced authors handle this, though.

Not that I’m any kind of expert, but:

In general, you want to make the names of locations as distinct from one another as possible, to avoid unintentionally creating a maze effect. Since players can’t refer to rooms by name (unless you’re implementing a system that lets them travel to a room by naming it) then name-clashes aren’t a problem.

Anyhow, here’s some examples of how to join things up using I7:

"Havey Cavey" by "just testing"


The cave is a room. "Just the sort of place that a bear - or a grue - would feel at home in."

The printed name of the cave is "spooky cave".
[Remember, you don't *have* to name things the same thing in your code as they appear in the story, it's just it's usually convenient.]

The cave entrance is south of the cave. "A broad, rocky ledge with a path winding off into the distance, and a long drop to the valley floor below."

[Inform is plenty smart enough to differentiate between fairly similar names most of the time.]

daysplinter is a privately-named thing in the cave. Daysplinter is scenery. The description of daysplinter is "The rock wall has split. From inside the gloomy cave, the daylight looks almost blindingly bright. However it looks just wide enough that you might squeeze through." Understand "split/gap/splinter", "rock/rocks" or "day/daylight" as daysplinter.

[a privately-named thing is something that doesn't make its "code name" visible to the player, the way that, say, "split rock" does below. This is handy when you want to give game objects distinct code names so that the game knows what you're talking about, but in the game world you want them to all have the same name, like a set of chairs or something, or when the literal description might confuse Inform (or yourself!)]

The printed name of daysplinter is "splinter of daylight". [notice that when giving something a printed name the period goes *outside* the quotes. If you put it inside then you'll get an unwanted newline.]

Split rock is a thing in the cave entrance. "North of where you're standing there's a V-shaped split in the rocks." Understand "v", "v-shaped", "narrow", "gap" or "rocks" as split rock. 
[When quoted text is just appended to a thing, Inform treats it as the initial appearance. If you'd rather, you could put the "North of where you're standing..." text in the room description and make split rock scenery. In that case you wouldn't need to make it fixed in place, since scenery defaults to fixed.]

Split rock is fixed in place. [to prevent the player from carrying it around.]

After going north from cave entrance:
	say "You squeeze yourself through the narrow split in the rocks.";
	continue the action;
	[This is how you add a description of travelling from one place to another. You have to add "continue the action" if you want the room description to be printed on completion of the travel.]

Instead of entering split rock, try going north. [Now the player will end up inside the cave.]

The player is in cave entrance. [This is how you make the game start in a room other than the first one defined.]

The long gallery is an open unopenable door. The long gallery is west of the cave and east of the cathedral. 
[Doors can be any connecting space between to rooms that we don't want to model, either to save on coding effort, or because we don't want the player to linger there. ]

The initial appearance of the long gallery is "[if the player is in the cave]A long, rocky gallery slopes down to the west, and a splinter of daylight to the south shows where you came in[otherwise]A rocky gallery slopes up and to the east[end if]."

Instead of going down in the cave, try the player trying entering the long gallery.

Instead of going up in the cathedral, try the player trying entering the long gallery. 

The description of the long gallery is "It looks steep and rather slippery." 
[The whole point of using a "door" here is so that there's a thing the player can examine both for versimilitude and to get more information. Notice that the description is written so that it makes sense when the gallery is examined from either location. (You could use  the same trick as in the initial appearance, of course.) ]

The description of the cathedral is "A no doubt fanciful name, but lacking light you're unable to tell."

Hope that’s useful.

1 Like

p.s. “try the player trying entering” is just future-proofing the code, so that if, say, you added a rock-fall or something that closed off the long gallery, the code will do the appropriate thing (i.e. fail to let the player enter). Hard-coding “enter the long gallery” might have introduced a bug into your game (depending on how other code was written).

(tried to edit my earlier post but FF just kept circling the airport.)

The key is scope. As a general rule, disambiguation questions only get asked when there are multiple things in scope that the command could apply to. And also as a general rule, only things within the current room are considered to be in scope. Not the current room, not things in other rooms.

So you can absolutely have a cave entrance in the cave entrance:

Cave Entrance is a room.
The cave-scenery is privately-named scenery in Cave Entrance. The printed name of the cave-scenery is "cave entrance". Understand "cave" or "entrance" as the cave-scenery.
Instead of entering the cave-scenery: try going north.

Or two trees in different rooms:

There is a birch tree in the park.
There is an oak tree in the forest.

(The complicated-looking stuff in the first one is just to make two objects with the same name without confusing Inform: the objects need different internal names, but can have the same printed name, and the same “Understand” lines.)

4 Likes

I know we’ve had this discussion before, but I wish people wouldn’t bring up “privately-named” in this context. It’s a distraction from solving the problem and it leaves authors perpetually confused about what privately-named is for.

I just see it as a style thing: I use “privately-named” to flag objects whose source code name doesn’t match what I expect the player to type, as a reminder that Inform isn’t going to give me any synonyms automatically (so I have to do them all myself).

(For OP: “privately-named” means that Inform won’t assign synonyms to this object automatically. Since the birch tree is not privately named, it’s given the synonyms “birch” and “tree” by default. Since the cave-scenery is privately named, it’s given nothing, which is why we have to specify words like “cave” and “entrance” ourselves: “cave-scenery” won’t be recognized.)

1 Like