Inform 7: object namespacing

A have a set of about 15 rooms. They’re set in an open landscape, so there are various landmarks that are visible from a lot of the rooms. This is all being implemented as scenery, with a unique description per room.

This means I end up with a lot of repeated object names. I’ve got a mountain that’s visible from every single room, for example.

Unfortunately, Inform 7 seems to put all names in the global namespace, which means that trying to do this:

Lakeside is a room. The mountain is scenery in Lakeside. "It's a mountain." River Mouth is a room. The mountain is scenery in River Mouth. "It's a mountain from a slightly different angle."
…causes an object name clash because ‘the mountain’ can’t be used in two places.

The only solution I can think of is to use unique names for every single object:

Lakeside is a room. MountainInLakeside is privately-named scenery in Lakeside. Understand "mountain" as MountainInLakeside. "It's a mountain." River Mouth is a room. MountainInRiverMouth is privately-named scenery in River Mouth. Understand "mountain" as MountainInRiverMouth. "It's a mountain from a slightly different angle."
This works, but… ew. There’s got to be a better way to do this.

What I’d really like is proper namespacing: the ability to tell I7 that objects declared within certain bounds are never going to used by code outside those bounds. Does such a thing exist? Or is there an alternative way to declare my scenery? It’s all non-interactive, so I never need to refer to it outside the paragraph where it’s defined; I did experiment with anonymous objects but was unable to make it work satisfactorily (seems I7 doesn’t like objects without names, surprise surprise).

I think you’d be better off using a single backdrop for each landmark, and make its description change depending on where you are.

This would require importing the object into scope for every room where it was visible, correct? I suppose I could still put the description next to the room definition by doing something like ‘instead of describing the mountain when the player is in Lakeside: say…’?

It’s still irritatingly verbose; I think, on the whole, I’d prefer to do it the long way to reduce complexity. (But it’s definitely worth while for non-scenery objects visible from multiple rooms.)

What I’d really like is a nice simple way of saying, here is a bunch of noninteractive things visible from this room only which are purely for flavour and don’t need logic attached, and here are the descriptions, and then not have to worry about them upsetting other rooms. Oh, well…

You can combine backdrops with regions and do this kind of thing:

The Place is a room.
The Other Place is north of the Place.
The Misplaced is north of the Other Place.
The Implacable is a region. The Place and the Other Place is in the Implacable.

The Magical Mountain is a backdrop in the Implacable. "[if in place]A magical looking mountain[otherwise if in the other place]That same quaint hill."

Test me with "x mountain / n / x mountain / n  / x mountain"

And/or you could selectively tweak the descriptions with a rulebook.

[code]A landscape feature is a kind of backdrop. The description of a landscape feature is “[desc of item described][run paragraph on]”.

To say desc of (item - a thing):
follow the landmark description rules for the item.

The landmark description rules is an object based rulebook with default failure.

A landmark description rule for a landscape feature (called item):
say “[The item] doesn’t look very special from this angle.”

The big scary mountain is a landscape feature. The sky is a landscape feature.

A landmark description rule for the big scary mountain:
say “It looks big and imposing, even at a distance.”

A landmark description rule for the big scary mountain when the location is the Foothills:
say “This close up, the face of the mountain seems to loom threateningly.”

A landmark description rule for the sky:
say “It’s blue, with not a cloud in sight.”

The Lakeshore is a room. The Meadow is west of the Lakeshore. The Forest is north of the Meadow. The Foothills is north of the Forest.

The big scary mountain is in the Lakeshore, the Foothills and the Meadow. The sky is everywhere.[/code]

Yes, I’ve just been reading about backdrops; they look really useful. Regions, too, but it’s a pity they can’t overlap.

This approach does seem the least bad, particularly since I’m going to want to hang some behaviour off them at some point. But it does seem like a very heavyweight solution to what should be trivial: fundamentally, I just want to place some scenery in rooms where the names are similar. Right now I’m trying to churn out room descriptions, and I’m finding that I’m continually running against issues where I can’t put a rock in this room because I’ve put a rock in that room.

I6 didn’t have this problem, by the way; creating anonymous scenery was easy:

Object -> "rock"
  with name 'rock' 'pebble' 'boulder'
       description "It's just a rock.",
  has scenery;

I’ve been trying various syntaxes for creating anonymous scenery; the closest I’ve come is:

Here is a thing which is scenery and has printed name "rock". It has description "It's just a rock."

But pronouns and plurals all come out wrong because I7 figures those out from the object name, and the syntax Understand "rock", "pebble" and "boulder" as it. doesn’t work so I can’t figure out how to get the player to refer to it…

Would it help to use kinds of things? Like this:


A mountain is a kind of thing. A mountain is scenery. The description of a mountain is usually “It’s a mountain.”

Valley is a room. “A mountain looms over you to the west.” One mountain is in valley.
Foothills is west of Valley. “You are in the foothills of the mountain to the west.” One mountain is in Foothills.
Upper Foothills is west of Foothills. “You are almost at the mountain.” One mountain is in Upper Foothills. The description is “You can see that the mountain is unclimbable. Might as well turn around.”

Test me with “x mountain/w/x mountain/w/x mountain”.[/code]

Genius! That works beautifully, and is ideal for the situations where backdrops are overkill. Thanks!

(The ‘one’ syntax is unintuitive, but obvious now I think about it. A neat trick.)

The thing is that if you type “A mountain is in Valley,” Inform thinks you’re making a general statement about mountains, so the compiler rejects it.

(And, you flatter me. :blush: )