Printing room description details and inventory details

Authoring Inform 7
1

There are some oddities to what things Inform tells you about in room description details and inventory details for a container.

If it’s closed, we always hear “closed”.

In inventory, we hear about “open” for things that are both open and openable, but we never hear about “open” in room description details.

For perceptibly empty containers (i.e., empty containers that aren’t opaque and closed), we’re always told “empty” in room description details; in inventory, we’re not told about it for these cases:

  • transparent, closed, and openable
  • opaque, open, not openable

I think those two exceptions for empty constitute a small bug. But I’m having trouble considering what the behavior should be in general.

There’s never an attempt to automatically describe something as transparent or opaque. This is appropriate, 'cause transparency could mean anything from glass to a veil to the bars of a cage. So, being able to see the contents of something doesn’t tell us whether it’s open or closed, and neither openness nor closedness tells us whether we could see contents if they existed. [ edited: oops, openness does tell us we could see contents if they existed, it’s just closedness that doesn’t. But a typical player wouldn’t know to interpret the absence of being told “closed” to necessarily mean “open”. ]

To know all those things without knowing opaque vs. transparent, we’d have to be told all of empty, open, closed (as applicable) all of the time whether the container is openable/closable or not.

But always printing these for containers would create visual clutter, and the room description behavior with details + contents doesn’t look great, e.g.,

You can see lucite case (closed) (in which is a toy) here.

Assuming we’re sticking to parentheticals after the thing’s name, what do you think the behavior should be?

[ Edited to add: ]

I suppose not specifying openness or closedness for unopenable/unclosable things is a sensible default.

1 Like
2

Thinking about it more, I’m thinking it’s appropriate to say (for both room description details and printing inventory):

  • “open” or “closed” for anything that’s openable
  • “closed” for closed unopenable non-empty transparent containers (the thinking being that if it has something in it then, without “closed”, the player would think they could put something in it; if it’s a closed unopenable empty transparent container, it had might as well not be a container and we don’t need to mention its closed-ness)
  • “empty” for open or transparent containers that are apparently empty, i.e., either really empty or all contents are undescribed or concealed (if they’re non-empty, we’ll know because we’ll be told about their contents).

These would mean saying open and empty significantly more often…

There are other distinctions between room description details and inventory details:

  • inventory details always describe lit things as providing light; room description details only say providing light in a dark room… and it is dark room, per se, independent of whether or not you’re in a closed opaque container. If another not carried thing in the container is your only light source, it doesn’t get “providing light”. If the container itself is lit, but the room is dark, it would get “providing light”.
  • inventory details say locked for locked things; room description details don’t. This means that when you pick something up, you magically know it’s locked without trying it.
  • and inventory details say “being worn” for worn things which is inapplicable in room description details, of course
2 Likes
3

I would suggest that if a transparent container is not openable that “closed” incorrectly implies it can be opened. There are situations where you don’t want something like

You can see a tractor beam (closed) (in which is a very-offended-looking cow) here.

3 Likes
4

I agree with this.

It suggests an angle on Inform’s world model which I hadn’t thought about. The “openable” flag on containers gives them two somewhat different uses.

  • An openable container is a simulation of a physical container. Whether it’s open or closed is a fact in the player’s world.

  • An unopenable container can be physical (e.g. a basket which is always open). But it can also be a organizational tool for the author. (The tractor-beam case.) That is, a way to collect a group of objects which move together (if the parent container moves), with flags for whether the objects in the group are visible and/or takeable. This is useful but it doesn’t represent physical transparency or openness.

Supporters don’t have this distinction. Supporters are kind of inherently a physical simulation. And I think this leads to that most contentious rule, the “describe what’s on scenery supporters in room descriptions” rule. The fact that some games want to yoink that rule implies that there’s two use cases for supporters, and we haven’t conceptualized it properly.

(I mean, it’s not really conceptualized for containers either. The “openable” flag is a sideways way of thinking about it; it doesn’t distinguish between baskets and tractor beams.)

3 Likes
5

I am persuaded in regard to closed unopenable non-empty transparent container case…