Inform DOORS help

I’m a new coder getting to grips with Inform. The documents, user examples and answers in this forum provide a wealth of helpful guidance as I take my first tentative steps but I’ve got a bit stuck with doors.

I have a spacecraft made up of several pods and between those pods I want hatches (doors). At some point I will want all of them to be locked but will definitely want to lock and unlock them individually.

For my doors/hatches to be unique I guess I have to give them all unique names when I create them?

Then, when I’m in a pod like ‘The Galley’ I can reference whether I want the hatch to the ‘Rec Room’ to open or the hatch to the ‘Workshop’ to open.

…I’m slowly getting to my real question based on the above understanding!

Can a door have a different name from opposite sides?

If I’m in the Galley can I say “open Rec Room hatch” but, if I’m in the Rec Room, say “open Galley hatch” (to control the same door from the different directions)?

I tried simply creating a door called ‘Hatch A’ and creating different descriptions for it from the different rooms but, when I perform an action on it it says the actual hatch name, e.g.,

>open hatch
You open Hatch A.

What I would like to be able to do is, from the Galley say,
>open rec room hatch
You open the Rec Room hatch.

And, for the same door from the opposite side (in the Rec Room), be able to say,
>open galley hatch
You open the Galley hatch.

Is this possible?

1 Like

Yes! Try this.

Throughness relates a door (called X) to a room (called Y) when the other side of X from the location is Y.
The verb to access means the throughness relation.

A hatch is a kind of door.
The printed name of a hatch is usually "[a random room accessed by the item described] hatch".
Understand "[something related by throughness]" as a hatch.

Daniel’s approach is definitely the cleanest, but since it shows off a feature of the language that might not be obvious, it might be worth pointing out that you can do things like:

Understand “rec room hatch” as Hatch A when the location is in the galley. Understand “galley hatch” as Hatch A when the location is the rec room.

(“The location” means the player’s location).


Note that you can make most printed text conditional. This is different from coining synonyms with “understand.”

The printed name of red door is “[if location is bathroom]hallway door[otherwise]bathroom door”.

Yay! That worked perfectly…thank you so much.
Thanks also to Mike and to Drew (I had discovered the conditional text but thanks for this extra snippet anyway).


Just to give you something to think about, I use to have door problems with Inform, because they’ve got a lot of baked-in behavior that I found hard to manage. Thanks to the same stellar crew you’ve encountered here, I finally stopped using Inform doors altogether and make my own now, which means I can control everything about them. Remember that things in Inform don’t actually have to be the things; they just have to appear that way to the player.


Very much agree. You can even dispense with doors completely and just imply them through narration:

If you do want to use double-sided doors, you can also use the “Easy Doors” extension which allows you to place a one-way enterable easydoor as an object which teleports the player without taking up a map direction. Two of these can be set to be opposite sides of the same door.


Inform is deep…I feel like I need scuba gear in my inventory…

1 Like

Yeah, Easy Doors is a great extension for all kinds of uses (Hanon is too modest to mention that he wrote the thing :slight_smile: )

After several years of working with Inform, here’s my mental list of circumstances where you absolutely need a door as implemented by the standard library:

When you need to use a standard Inform door

And here’s the list of the places where you may not need one, but life will be easier if you do:

When you should use a standard Inform door


See, I like standard Inform doors, because they’re part of the map and thus attached to compass directions and such. But I know I’m an outlier in this respect.

(I also make games with lots of doors in them.)


I use Inform’s built-in doors, too. For ladders as well. By the time I heard they were bad, I’d gotten used to them.


I usually chuck Inform doors and just implement objects called doors. To make them exist in both coincidental rooms, I just make them backdrops.

Then I handle commands relating to these backdrops uniquely.


Galley Door can be open or closed. It is closed.
Instead of opening Galley Door:
    if Galley Door is closed:
        say "The door slides open.";"
        now Galley Door is open;
        say "[Galley Door] is already open."
Instead of going north in Corridor:
    if Galley Door is open:
        say "You step through [Galley Door] into the Galley.";
        now the player is in Galley.
        say "[Galley door] is closed.".
Instead of going south in Galley:
    if Galley door is open:
        say "You step through [Galley Door] into the corridor.";
        now the player is in corridor;
        say "[Galley door] is closed.".

Or stuff similar to that.

But then, I’m not the Inform 7 expert. I just make it do stuff, and if it works, I call it done, and don’t worry too much about if it’s the best way to do it.



I use them, I just throw in the Locksmith extension on top to beat them into submission. I barely even explicitly use the Locksmith extension’s features! It just makes some behaviour more automatic and adds synonyms and grammar.



Count me in as an outlier too then. I considered not using doors at all and do some trickery with scenery objects, backdrops, and changing room connections on the fly, but in the end I stuck to the default doors with some additional magic to make them disappear at times. In my IFComp game I count 10 doors in total (1 gate, 3 hidden doors, 4 portals, and 2 doors which pretend to be something else entirely :smiley: ).

1 Like

Same here!

Tip: if you define them as “openable”, you get all the default library behavior around the “open” and “close” commands automatically! Similarly if you define them as “lockable”, you get the default library behavior around “lock” and “unlock”.

(The idea is, containers and doors should behave the same way with respect to those commands, but those are two very different kinds of things. So instead of having an “openable thing” kind, they have an “openable” property that provides all that implementation.)

A false door is a kind of backdrop.
A false door can be openable. A false door can be lockable.

With help from @Draconis and like four other people discussing what we wanted from doors!