I have no idea why Graham Nelson decided that doors should inherently be one-way portals. Okay, sometimes you might want such a thing, but as a general rule? I think not.
Here's how to create doors which "just work" both ways. Credit to the toilet door on page 138 of the Inform Beginner's Guide for most of the clues.
[ otherway x; switch (x) { n_to: return s_to; s_to: return n_to; e_to: return w_to; w_to: return e_to; ne_to: return sw_to; nw_to: return se_to; se_to: return nw_to; sw_to: return ne_to; in_to: return out_to; out_to: return in_to; u_to: return d_to; d_to: return u_to; } ]; class autodoor has static door openable lockable scenery with name "door", description [; if (location == self.comes_from) print_ret (string) self.descrip1; print_ret (string) self.descrip2; ], door_to [; if (location == self.comes_from) return self.goes_to; return self.comes_from; ], door_dir [; if (location == self.comes_from) return self.direct_to; return otherway(self.direct_to); ], found_in [; if (location == self.comes_from || location == self.goes_to) return true; return false ]; autodoor example_door "plain door" with name "plain", descrip1 "The door is painted brilliant white and has a glass panel set into it.", descrip2 "The back of the door is pretty uninteresting except for the glass panel", goes_to kitchen, comes_from hallway, direct_to n_to, with_key iron_key;
That creates a door which:
Also note that:
Why this sort of thing isn't a standard feature of the language I have no idea. (But then, the default state for all Inform6 locations is that they're dark and you cannot see, which in my opinion is the exception rather than the rule for most game rooms.)
Go up
Return to main index.