Consensus on listing container contents


I’m am fairly new to I7 and to the contemporary IF community, I sincerely hope to remain lurking around as I have recently found the medium to be much more interesting than I remember (plus cheap).

My experience with IF goes back some 30 odd years with local games but I am afraid that it also stops there. I mention that because I am not familiar with classic works and how did they tackle presenting information to the player, thus, my question: is there any kind on consensus about whether or not to list the contents of a container in the room description?

The default I7 behavior towards supporters seems ok to me, but I am not sure if the player is supposed to examine a container to find out its contents. I can get on board with closed containers (the player opens them and a message reveals their contents) but what about open, transparent or even impossible to close containers?

So far I am not looking so much for technical guidance as for “best practices” so any input is welcome.

Thanks in advance.

I don’t know that there’s a best practice, just one game and then the next. Inform’s default logic is certainly logical. Things that can be seen are listed, things that can’t aren’t. But whether you want this logic on every object in a particular game is another matter that can only be answered in the context of that game.

Which is to say – start making something. See if you like what Inform 7 does by default. Does it suit your game or part of the game?

A big open chest full of jewels will probably draw the player’s eyes, and we’d expect most PCs to see the jewels straight away. But what about a little leather pouch on the wall, even if it’s open? You probably don’t want the player to know what’s in it 'til they examine it, so you want the listing behaviour off on the pouch. These are the decisions you have to make as you go along, then program. And until you’re faced with them in context, I wouldn’t worry about them. In the meantime, keep noting what the default behaviours are.



It really depends on what you want. The contents of a closed glass display case should be visible, I think. But the contents of an open mouse hole would probably be hidden. With the closed glass display case example, I think it depends on how much description you want to throw a the player right away. It’s not unreasonable at all to have them examine it to see the jewelry inside.

I think the whole point of most traditional containers (boxes, suitcases, etc) is to keep their contents out of immediate view. But of course there are a million variations on the theme. The question is: what do you want the player’s experience to be with this container? Is it a puzzle? A holder of a very important clue? Or scenery that sets the stage?


I hadn’t thought of it in terms of what I wanted the player to see, actually, thanks. As for the behaviour, I started taking note when I had three containers being a part of the same thing (a cupboard and its drawers) and started thinking if I wanted the player to see the contents… I put together a recursive cointainer type with rules for writing paragraphs about them only when the player had interacted with them and it was that which made me wonder about this question. I will ponder your advice with care.

Thanks Amanda… I am modelling a world that tries to make sense according to its rules so, in a way, everything is just part of scenery that sets the stage. On the other hand, most items will be on containers or supporters (because rarely we find things lying on the floor) and these include plot clues and puzzle pieces.

Now that I think of it, maybe I am overdoing it with the scenery and that’s part of the problem. On one hand, I would expect players to examine containers and find what’s on them. On the other hand I want something that feels “lived” and that usually includes layers upon layers of scenery and descriptions, maybe too much information for the player to keep track “where is what” (hence, showing them on the description).

On the whole, this is my first attempt at doing something, so surely it is also a matter of taste and betatesting.

I wrote my first game last year and learned much of what to do from my poor abused beta testers. Ultimately I think we all write the kind of games we like to play. I dislike the old-school habit of making me EXAMINE something and also SEARCH it. But others love that. So write what you like and then take the rebukes from your testers and modify. Congrats on getting cracking on a project!

It’s down to author’s preference and style. Some people want the prose and descriptions to read more like a novel without the parser interjecting “You also see a vacuum cleaner and a glass jar (in which are six jelly beans) here.” Many classic parser players and authors are accustomed to this format, but you might decide you don’t want that during a tense conversation or a climactic scene.

Inform allows de-listing contents of containers specifically for that reason, either globally or on a case-by-case basis.

One thing you can do is strike a happy medium. It can get repetitive if the format is always [room description] [separate paragraph of interactable stuff]. I tend to mention potentially important scenery in the room description, write an “initial appearance” description of important objects when initially encountered, then let the parser handle any extra clutter that the player throws around.

Thanks :). I am still commiting the first-timer sins (some things are still unplanned and it just grows, and grows…) but I am having a great time doing so.

I will likely search for a way to list contents of specific open containers in cases where there are vital intems inside and see if I can present them as “In the #### there is ####” instead the “You can also see a #####…” that has been already mentioned in the description. Thanks Hanon.