Nesting Objects

Hello all,
I was just wondering about everyone’s thoughts on objects within objects within objects, not boxes of containers per se. For instance, lets say that a player has a closet. In the closet are some hanging clothes. If the player opens the closet they will see the hanging clothes. However, if the player searches or examines the hanging clothes they will see the different clothes that are actually hanging there. As a result of this, now when the player looks in the closet they will see all of the clothes hanging in there, or do you think it would be best if the description returns to seeing hanging clothes in there ?

I guess my question is how many layers do you think are too many ? My thinking is that the player is exploring the narrative and as a result they get as many details as they are interested in getting (or not getting whichever the case may be). But from what I remember back in the 80’s the challenge of the text adventure was not exploration per se, but trying to figure out which objects in the description could be taken and interacting with and which verbs could be combined with those objects and where to use the objects (the break mirror puzzle in Ghost Town by Scott Adams still lingers in my memory).

Lots of players (especially parser) love ransacking through a well-implemented room and discovering secrets. It will depend on the story you are telling though - if the player is searching a crime scene, of course it’s natural they are going to investigate. If they are casually walking through the home of someone they don’t know, the author may wish to limit how much the PC will let them go snooping.

It comes down to writing the game you want. Just be aware that if critical information is deeply nested you always run the risk of casual players not encountering it. It’s always fun and good to put optional world/lore-building stuff for the player to dig for or skip at their option. I’d advise that if the player has to go in a closet that contains a coat that contains a jewelry box that contains a mint-tin that contains a required key that you give them subtle nudges that they need to do so - either via blatant hinting, or tutorializing early in the game that there are deeply-nested objects to search for.

This level of detail is very time-consuming to implement, so that’s another consideration to take. Authors should try to keep the same “depth” level throughout the game. You may not want to set up expectations that players can examine every piece of junk in every single drawer if it’s not important to the story. Usually when players encounter this level of detail they will expect it throughout, and it can be a disappointment if the implementation gets shallower as the game progresses. Usually when there is deep implementation that signals to the player this object is very important or else it wouldn’t have a description and they’ll hang on to every coffee cup and piece of pocket lint even if it really doesn’t matter. That can lead to lawnmowering frustration: if they get stuck, they’ll try every inventory item on the mysterious lock even if it doesn’t make sense, which can be immersion-breaking.

You can also count on the player will fill in detail in their minds. You don’t have to implement everything in a medicine cabinet with descriptions if there’s no real need for it when all you need is “It’s a medicine cabinet with all the personal stuff you’d expect the owner doesn’t want you to mess with.” This all goes toward game pacing. An exploration game may warrant this, but at the risk of knocking the player off the main plot for long periods of time.


thank you for the reply, very solid points there. I completely agree with consistent levels of depth/detail and the role of the player’s imagination as an assistant in story telling and world development.

I guess my thinking as far as narrative, is that I do not want to overwhelm the player with a lengthy description of everything that is visible but would rather encourage the player to examine and explore the environment to get more description. Which connects to your point about writing the game that you want. I am so used to coding the game that the contract studio is paying me to do or that current market trends are encouraging one to do, that it did not immediately occur to me to just do whatever I want to do :slight_smile:

1 Like

I’d suggest checking out some of Ryan Veeder’s games. He’s discussed on a podcast how he works very hard to write descriptions that don’t avert the player from the critical path of what he wants them to do. There’s an art to writing descriptions that are descriptive without being distracting. Everything you mention is a potential keyword to examine. If you describe the wallpaper, that usually cues parser players that there’s something important about it they need to investigate, so just be aware of that.

This is, of course, with regard to parser implementation. With choice-based narratives, the author gets a lot more control over what the player can actually do and can direct exploration in a more controlled manner.


interesting debate on design, because I’m working (messing) with converting the good ol’ treasure hunt in “game world lore” hunt (cfr. the “isekai” genre in Japanese animation) and indeed debating on nesting objects (and accompanying lore is of my interest
(incidentally, my experimenting with “lore hunt” explains my peeve about differentiating between examining and reading books…)

Best regards from Italy,
dott. Piergiorgio.


I agree with what @HanonO said, but would just like to add a few points.

When nesting objects, do what you would expect to find in the real world. For example, your wardrobe may contain some clothing. Amongst the clothing is a coat. The coat has a breast pocket and the breast pocket contains an ID card. This is exactly the type of thing you would expect to find in the real world, so it should feel quite natural to the player. Just make sure that you provide plenty of clues when examining objects. For example, when examining the coat, you need to mention that it has a pocket. The player should never have to guess that it has a pocket.

Authors love to hide things and players love to discover those hidden things. Every little discovery is a step towards solving a puzzle.

The only suggestion I’d make is that the nesting should not go too deep and the level of nesting should be varied. Also, the number of objects in a container (or on a supporter) should be varied. Sometimes it will be one object, sometimes two or three, but rarely more than that. Again, it comes down to what feels right in the real world. And it’s okay to throw in a few red herrings to put the player off the scent, but don’t go overboard with the red herrings.

When implementing containers, don’t forget to check what can be put into those containers. Using Hanon’s example:

The key can be placed in the mint-tin or the jewelry box and the mint-tin can be placed in the jewelry box, but the jewelry box cannot be placed in the mint-tin. Similarly, the broomstick cannot be placed in the mint-tin or the jewelry box.

I couldn’t agree more. As a player, I hate being blasted with a full screen of room description every time I enter the same room. It’s much better to give a concise description of the style or feel or function of the room, but leave the details of the individual scenery objects to EXAMINE responses.


Or split up rooms. Hadean Lands has a great many closets for exactly this reason.


thank you I will take a look at those, amazing and fascinating how much this community has changed in 40 years, awesome stuff

Agree on your point, aside a criticality on the last one:

the balance between the room description and the details given by eXamining the context. whose we can consider the root (or better, the top parent) of the question, because is where the nesting starts.

on paper, one should implement the eXamine response for every noun in the room description, but this is somewhat unfeasible in Z-machine format, albeit there’s a contrib library (both standard and puny) whose allow up to 10 scenery objects for room at the price of one. Hence, the room description should have limits, and the obvious one is describing what stands up conspicuously (for example, everyone can see at glance if a desk has drawers or not; so, the drawers should be in the room’s description, at least IMVHO)

Then, a room’s description should do is establishing the relationship between the items in the room, whose can led to interesting entry points for subtle details (e.g. in a living room of a couple is an armchair and not a sofa in front of the TV: this can be an interesting nudge, suggesting that either there’s couple issues or one of the partners don’t like TV, for example)

Best regards from Italy,
dott. Piergiorgio.

In Inform 6, you can also implement “poor man’s scenery objects” by adding names to the room object, e.g.:

Room pway "pathway"
    with description "The gravelled path winds between the ivy-covered oaks.",
    name 'ivy' 'gravel',

Now if the player tries to examine the ivy or the gravel, they get the message “That’s not something you need to refer to in the course of the game.” which is slightly better than claiming they “can’t see any such thing.”

I know about this, whose isn’t an alternative, but a complement; notice that there’s another Z-machine limit involved here, namely the dictionary entries.

On paper this feature can be used for the “lesser” scenery (the ones ßtesters always prove that actually are “major” scenery…)

Best regards from Italy,
dott. Piergiorgio.

1 Like