Sorry, this is a simple one!
[code]The yard is a room.
The stable is inside from the yard.[/code]
When I ‘x stable’ the interpreter spits ‘You can’t see any such thing’. The two rooms are connected but how do I ensure that one is visible from the other?
Also, bonus points, I’m sure visible exits used to be listed automatically in the room description. How do I make that happen? (Or am I thinking of TADS?)
There are extensions like EXIT LISTER to list exists either after a description or in the status bar.
I’d make the stable an open, unopenable, enterable, transparent container, although that might thwart something you want to do later.
You could also make the stable a door if you wanted to go that route. The simplest way is just to define a piece of scenery called “stable” in the yard, and use an Instead rule to handle “enter stable”.
What is the most elegant way to make adjacent rooms examinable from the player’s current location?
With OOP in mind, I would give each location a description that is printed when the location is examined from an adjacent room. (There of course could be overrides.) Thing is, I’m back to my original question. That description can’t be used if the location is out of scope!
If I have 1000 rooms, each with 16 exits, representing each adjacent location with a piece of scenery or other object in each room seems a little hacky.
Say, I have a house that is west of a field. How do I make sure that ‘x house’ returns something pertinent other than: 'You can’t see any such thing? …with the least amount of additional code.
Out of unshakeable curiosity, what exits would those be? Even accounting for in/out and up/down I can only count 12.
You might want to have a look at example 217 (at least as of 6L02), “Dinner Is Served.” The most relevant part is the part after “The rest is window-dressing,” especially the part about adding rooms to scope, defining a new syntax for examining that lets you examine adjacent rooms (most Understand lines are defined to apply to things and rooms aren’t things, so the parser won’t understand the commands unless you include a new Understand line that applies to rooms), and defining rules for examining rooms.
If you really want every adjacent room to be examinable, what you’d want might be something like this, untested:
[code]A room has some text called the remote-examining text. The remote-examining text of a room is usually “[description of the item described]”.
Definition: a room is nearby if it is the location or it is adjacent. [because it’d be frustrating not to allow the current room]
After deciding the scope of the player:
repeat with the next room running through nearby rooms:
place the next room in scope.
Understand “examine [any nearby room]” as examining.
Instead of examining the location: try looking.
Instead of examining an adjacent room (called the next room): say the remote-examining text of the next room.[/code]
…and you might also want to have something like in the “Dinner Is Served” example for dealing with things in the other room.
Also a thousand rooms is a lot!
Thanks for the help. Great example.
BTW, 1000 rooms was an off the cuff example but, now thinking about it, a lot of fun could be had with a procedurally generated map!
One tip: you don’t need “any” if the objects are already in scope (it’s used to indicate that the scope rules should be ignored for that grammar line). You can just Understand “examine [room]” or “x [room]” as examining.
If you also want to allow “look west” or “look toward the library”, you can use the extension Facing by Emily Short.
In fact you don’t need the new understand line at all.
The world model in IF can be extended in an infinite number of ways. You have to focus on solving the problem you have, not the problem that somebody might hypothetically come up with. Otherwise you’ll never get a game out.
Huh. In light of Draconis’s and Juhana’s comments, is the Understand line necessary in the “Dinner Is Served” example?