[code]The Learning Lab is a room.
The Office is a room.
The office door is east of the Learning Lab and west of the Office.
The office door is a door.
The office window is a door.
The office window is east of the Learning Lab and west of the Office.[/code]
Clearly I want to model a room that has an Office. There are two ways into that Office: an actual door and a window (which acts as a door).
This doesn’t work because Inform sees this combination of statements as a contradiction. I understand why that error is reported but what I don’t see is what I can do to simulate the above situation. I tried looking up examples in the manual and, unless my search-fu is failing me, I don’t see this particular situation covered.
Good point. Essentially this very example is predicated upon the intuitive notion there could be two ways into a room – a window and a door.
So from an operating standpoint, GO EAST (from the lab) or GO WEST (from the office) would attempt the door first, as being the more obvious intent. You raise not just a good point but a great point, as I think on this, because this might be a way to teach situational game logic. Specifically:
Initially, the door is assumed to be the obvious choice for a GO WEST or GO EAST.
If the player has tried the door and found it locked, then the window is the obvious choice.
If the player has not tried the door, it is first tried then found to be locked, in which case then the window is tried.
However, none of this works if I can’t declare two objects to be doors leading to the same place (from both directions).
Actually, sorry about the terse first answer: the general solution to almost all cases is to make the door a real door (which is likely to be the primary method of entering and exiting the room) and create a window backdrop that’s present in both rooms.
The Learning Lab is a room.
The Office is a room.
The office door is east of the Learning Lab and west of the Office.
The office door is a door.
The office window is a backdrop. The office window is in the Learning Lab. The office window is in the Office.
The office window can be open or closed.
Instead of entering the open window:
say "You climb through the window.";
if the location is the Office:
move the player to the Learning Lab;
otherwise:
move the player to the Office.
…and then add rules to cover all the different scenarios (opening and closing the window, trying to enter through a closed window, going east/west when the door is closed but the window is open etc etc).
Okay, that certainly makes sense. Thank you for that.
My initial thought was that’s a bit of a challenge in terms of presenting this as an “intuitive” idiom for Inform 7 use. Essentially it’s “If you want doors in the same location, that both lead to the same space, think backdrop.” Yet in writing that out, I think part of that stems from the term “backdrop” which people might not associate with this kind of solution. Granted, a backdrop is a bit of scenery in the background, in normal parlance, so there is a bit of a correlation there. Here, however, the author’s emphasis is on a door or connector, not a background element.
So as I think on it, this might be a chance for me to bring in a way to say “A portal is a kind of backdrop” or something along those lines, showing authors how to flesh out the model with concepts that align with how they are thinking about a given problem.
You could also make a privately-named backdrop and add the window as a container which is part of it. That would get you opening/closing/locking/unlocking/inserting into automatically. Then add a carry out rule for inserting something into the window (move it to the other room) and one for entering it (move the player) and you have a functional door.