make "cheap doors" work more like real, first-class doors that are objects

[pahp]

In order to keep our object count down, and to avoid having to go through the effort of making objects for boring doors, we have extensively used something I'll call "cheap doors" -- I think they have a name but I cba to figure out what it is rn. But cheap doors are the "cheap scenery" of doors. As you know, with cheap scenery, you don't need to create actual objects, you just provide a list of things you can look at or interact with in a room, and the cheap scenery does it for you.

Anyway, a "real door" is implemented like this:

e_to ThatsABigDoor

... where ThatsABigDoor is a real object that implements the door. In contrast, cheap doors work like this:

e_to Hallway2

... where Hallway2 is a room. It allows you to go e and end up in Hallway2, just like a door should. Unfortunately, it is a fiction. They have played us for absolute fools.

This leads to many many interactions like this:

Hallway
This is a hallway, extending to the north and to the south. To the west there is a utility closet, which is open. A row of uninteresting
filing cabinets lines the east wall.

> open door
You can't see any such thing.

> close door
You can't see any such thing.

> l door
You can't see any such thing.

> 

It makes the player feel crazy, like the door is a hallucination. At least, that's how it makes me feel.

I think that doors should be able to be interacted with.

One solution to this is to make them all actual first-class objects, but that will add a lot of work and many more objects to the game that we don't need.

The alternative, suggested by @spacehobo is to add some hooks in the cheap scenery supporting the door so that it behaves more doorishly. See the security fob scanner in the elevator for an example, but @spacehobo also gave this sketch in Signal:

We just define, like

[ BeADoor ;
  Examine: "It's a door you don't need to go through.";
  Open: "Don't open that";
  Close: "You can't even open it.  Why would you close it?";
];

Here, BeADoor is a global definition of how these fake doors should behave, and then we can reuse it everywhere we have one of those doors. He continued:

And then our cheap_scenery will have like

'door' 'doorway' BeADoor

Now... all that said, I think we want to avoid as much as possible any dynamic description changes based on whether a door is open or closed. In some places in the game there is currently description text saying that a door is open or locked, etc. Unfortunately, any example of this is a place where dynamic descriptions must be implemented so that the desc matches the state of the door. (If the desc says the door is open, but you close it, now the description should say that it is closed. Ugh.)

Also, "real" doors can be closed, and then they won't let you through until you open them. (Jerks.) We could possibly implement this in our BeADoor code, but for a first pass, I suggest we implement something a bit dumber to avoid dynamic descriptions / checks / keeping state. Basically, let's make it so that these generic doors just always do the right thing with a minimal amount of effort:

• if a player says "open door" it says the door is opened, but then slowly closes on its own
• if a player goes through a fake door, the description says you open the door and walk through (it silently closes on its own).
• if a player says "close door" it will say something like "the door is already closed"
• no descriptions talk about doors standing open, being locked / unlocked / etc.

Thoughts?

I think there are three problems here:

1. A third issue (3) is that some doors (like the "Antique Wood Door" mentioned above) need to be able to be referred to according to their obvious descriptions -- i.e., they have a unique name besides "door" that should work.
2. I should be able to refer to the door, but I can't, because it's not a real object. We need some help here (see below).
3. Stating in the desc that the door is open is maybe not the best, because it implies that I should be able to open or close the door, but that then requires interaction in the description.

Anyway, all doors of this type (in the whole game) need to be able to be looked at, examined, maybe opened or closed (using names / words that make sense for them based on their description). Opening and closing is tricky, because unlocked "real" doors can be opened and closed, and they do obstruct movement when closed. (Try this with the brass knobbed door.)

[libraun]

So far, I have a skeleton of this on "jet-DoorCallback", but it doesn't quite work as advertised. Still thinking on it.

[spacehobo]

I've added an inline comment here about why it doesn't work for you.

Basically you're trying to do too much. There are no objects, so there is no open/closed state for any of these doors. They should just be a set of static messages when the user tries to do things to the doors.