I want to have a hut which the player can unlock and go inside. The inside of the hut needs to be a separate room, so I can’t just use a container. I can give the hut a door, but it’s natural for the player to try to interact with the hut using commands like ENTER HUT or UNLOCK HUT. This is what I have so far:
"Hut hut hut" by Adam Biltcliffe
Lab is a room. "There is a hut in the middle of the room for some reason."
The player carries an iron key and a bratwurst.
A hut is scenery in the Lab. Instead of entering the hut: try going inside.
Inside from the Lab is a lockable locked scenery door called the hut door. Inside from the hut door is Hut Interior. The matching key of the hut door is the iron key.
Instead of unlocking the hut with something: try unlocking the hut door with the second noun. Instead of locking the hut with something: try locking the hut door with the second noun.
Does the player mean doing something with the hut door when the player's command does not include "door": it is very unlikely.
This works after a fashion but there are two things I’d like to fix. The more serious one is that redirecting ‘unlocking it with’ from the hut to the door seems to break disambiguation follow-up questions:
>unlock hut
What do you want to unlock the hut with?
>key
I didn't understand that sentence.
The second, more minor issue is that because the name of the door also includes the word “hut”, I get a “(the hut)” clarification after every interaction with the hut. Adding the “does the player mean” rule stops the presence of the door from actually obstructing attempts to interact with the hut, but is there an easy way to tell Inform that a noun phrase without “door” never means the hut door? I can go all-out and make the hut door privately-named and then write ‘understand “hut/-- door” as the hut door’ but that’s unwieldy if the name of the hut door is actually more complex - is there anything easier?
Hut hut hut
An Interactive Fiction by Adam Biltcliffe
Release 1 / Serial number 241013 / Inform 7 v10.1.2 / D
Lab
There is a hut in the middle of the room for some reason.
>unlock hut
What do you want to unlock the hut with?
>key
(the hut with the iron key)
You unlock the hut door.
>
Just a piece of advice which you may certainly ignore:
I now stay far, far away from things with the same name for precisely this reason. Call it a wicker door or a wooden door or a blue door-- ANYTHING but the hut door. This kind of thing will continue to be a disambiguation irritation for both you and your players, so trying not to repeat names in different things saves a lot of headache.
In the thread otistdog linked, you’ll see me recommending including Emily Short’s Locksmith extension in your game.
Sometimes including this extension solves problems only tangentially related to doors, but I guarantee it solves tons of problems directly related to doors! The kind of rules you’re writing, it’s already developed at greater depth and in a general use case. So I would strongly recommend including it. There’s a chance you’ll find it solves all the (few) problems you’ve had so far.
For your other question, if you don’t want to rename the object per AmandaB’s suggestion, then you can use the clarifying the parser's choice of something activity.
For clarifying the parser's choice of the hut when the hut door is visible:
do nothing.
One very cheap trick is simply to make the hut be the door. That is, only have a single object. Then there can’t be any disambiguation and you don’t have to redirect any actions.
The Meadow is a room. "There is a small hut in this green and pleasant field."
The Hut is a room. "It's not very big."
The hut-exterior is a closed scenery door. The printed name is "hut".
The hut-exterior is inside from the Meadow. Through the hut-exterior is the Hut.
Understand "small", "hut", "door" as the hut-exterior.
The description of the hut-exterior is "It's a small thatched hut. The door is [if open]invitingly open[else]closed[end if]."
The Meadow is outside of the Hut.
In this example, the door is really one-sided – it appears in the Meadow but not in the Hut room. So the description only has to account for viewing the exterior.
(Exiting from the Hut still works; it’s just not via a door.)
You could do it the other way, with a two-sided door. Then the description property would have to be smarter. On the up side, that would support “close door” from inside the Hut, which my example doesn’t handle.
As an alternative, you could use the “Easy Doors” extension. Its purpose is so you can declare a door exists in a room, but you can place it like an object, it doesn’t require nor take up a map direction, is openable and lockable like a regular door unless you don’t want that, and it provides one-way transport to another location which needn’t be map-connected anywhere else (you can put another easy door in that room as an exit.)
What I found is that Easy Doors can be described as entire buildings instead of just a door, so you could have an easy door that can be locked with a key called “Small Hut” described as "A small hatched hut with a door - so you can open and close the small hut, then enter it - which leads to a room called “Hut Interior” you have set up elsewhere. You can declare “understand “hut/-- door” as small hut”