I have an exterior location with multiple exits into buildings.
I don’t want to use compass directions. Instead I want the player to be able to enter shop or enter hut. I’ve seen the Owen’s Law example but it’s not quite what I want.
The player should be able to:
> enter shop
...
> exit
...
> enter shop
...
> go outside
...
> enter shop
...
> leave shop
I know that entering relates to containers. I don’t think I want to make the buildings containers. Is it possible to navigate to another location by entering?
What’s the best way to achieve this? Can anyone point me to some examples?
The shop is a room.
The shop is inside from the bus stop.
To navigate to it I can:
> go inside
... or ...
> inside
As a player I would like to:
> enter shop
... or ...
> go inside shop
... or ...
> go to shop
but for each of those, I get:
You can't see any such thing.
To remedy that, I’ve tried adding the shop as scenery as well:
The shop is a room.
The shop is scenery in the bus stop.
The shop is inside from the bus stop.
But that fails to build because: this looks like a contradiction, because apparently something would have to be both a room and not a room at the same time.
To handle the user wanting to enter shop, I’ve made the shop-front an enterable container then intercept the entering action and move the player to the shop location.
This seems a bit hacky. Is there a more elegant way to understand enter shop as wanting to move to the shop location?
The Bus Stop is a room. The player is in the bus stop.
The shop is a room.
The shop-front is scenery in the bus stop.
The printed name of the shop-front is "shop".
Understand "shop" as the shop-front.
The shop is inside from the bus stop. The shop-front is an enterable container.
Instead of entering the shop-front, move player to shop.
I don’t think the shop-front has to be an enterable container for you to write Instead rules about it. (Sorry for the “I think”, I don’t have immediate access to an Inform 7 compiler.) I am certain that you write the following code instead of the current instead rule, which is less hacky and will work better with all kinds of special circumstances:
Instead of entering the shop-front:
try going north instead.
(Assuming that your shop is to the north, of course.) This call Inform’s normal going routines, with all the customary rules.
Yup, you’re right. There’s no need to make shop front a container of any sort. Instead of entering the shop-front, move player to shop. works just fine.
Yes, but I recommend redirecting it into a going action as in my example. This will make sure that Inform checks the normal rules for going; e.g, that the player can’t go when in a closed container, that he can’t go if there’s a locked door in between, and so on. Moving the player ‘by hand’ so to speak may generate bugs. (You can do it when necessary, of course.)
Yes you’re right, I see why that could be a problem.
So now I have:
The Bus Stop is a room. The player is in the bus stop.
The shop-front is scenery in the bus stop.
The printed name of the shop-front is "shop".
Understand "shop" as the shop-front.
The shop is a room.
The shop is north from the bus stop.
The bus-stop is outside from the shop.
Instead of entering the shop-front, try going north instead.
I’ve defined the bus stop as being outside of the shop because I will eventually have multiple rooms that represent enterable buildings.
However, I now have this problem:
Bus Stop
>enter shop
shop
>leave
bus-stop
>enter shop
You can't see any such thing.
>n
You can't go that way
Why can I not see the shop once I’ve left it?
I can navigate n to s and back again fine if I avoid using exit/leave when inside the shop.
You could also try adapting Example 306, “Misadventure”, from Chapter 6.9 in the Recipe Book, like this:
The Town Square is a room.
The Shop is west of the Town Square.
The Cold Storage is west of the Shop.
The Police Station is east of the Town Square.
Room-entering is an action applying to one thing.
Understand "enter [any room]" or "go to [any room]" or "go inside [any room]" as room-entering.
Check room-entering:
if the noun is the location, say "You're already in [the location]." instead;
if the noun is not adjacent and the noun is unvisited, say "That noun did not make sense in this context." instead.
Carry out room-entering:
let aim be the best route from the location to the noun, using doors;
if aim is not a direction, say "You can't think how to get there from here." instead;
say "(heading [aim])[command clarification break]";
try going aim;
if the location is not the noun, say "(One step at a time.)".
This way you won’t need scenery items, and it’s generalised for all rooms.
It does not take care of exiting, because when there are multiple exits from a location, Inform won’t know where the player wants to go. (Unlike the case of entering, where the target location is given by the player.)
For that aspect, you might try to use parts of example 103, “Polarity” (for tracking where the player came from, and going back there) or example 179, “Owen’s Law”, which you mentioned (see Chapter 6.9 in the Recipe Book).
You say I won’t need to use any scenery items. I still need to use scenery items for the player to be able to examine the exteriors of the buildings. Is that what you meant?
I’m wondering if it’s possible to add an additional description text for the exterior:
A building is a kind of room.
A building has some text called exterior description.
The Shop is a building.
The exterior description of The Shop is "Just a shop".
The Shop is north from the Bus Stop.
The Bus Stop is outside from the Shop.
If the player tries to examine a building and it’s in an adjacent room, we see the exterior description. I’m not quite sure how to do that at the moment. Am I right in thinking it’s possible?
What I meant was that (using adapted example 306) you won’t need any scenery items as proxies for the purpose of entering the buildings.
But you bring up a good point: of course, for the purpose of letting the player examine the buildings, you might very well use scenery items.
Alternatively, your suggestion with the building kind and the exterior description could also work. As far as I can see, the only thing that’s missing from your code is to hook up the exterior descriptions to the examining action. You could add something like:
Instead of examining a building:
say "[exterior description of the noun]".
However, a potential problem with this approach is that there are other verbs the player might try:
>climb police station
You can't see any such thing.
And similarly for open shop, throw stone at station and so on, because these verbs are meant to apply to things in the same location, not to the newly-defined building kind.
So either you would have to include some extra rules for these other verbs (like you did for examining), or you use scenery items for these purposes. I think the latter approach might be better, because Inform then provides some sensible default responses out of the box:
>climb police station
Little is to be achieved by that.
>take shop
That's hardly portable.
This may not wind up being what you want to do in this case, but it is possible to allow the player to examine things in another room. Recipe Book §3.6 on Windows has some relevant examples, especially #217 “Dinner Is Served”–see the parts about placing the next room in scope.
However I’m not sure that this would be what you want, because in the code you had the building isn’t in the adjacent room, it is the adjacent room. Your and St. John Limbo’s approach looks like it’s making a lot of progress there, but he raises good caveats about doing other things to the room!
One possibility that avoids creating a scenery object would be using a catchall parser error:
Rule for printing a parser error when the player's command includes "[any adjacent building]": say "You can only ENTER or EXAMINE that."
If that even works, it goes under the assumption that if the player typed the name of the adjacent building, they’re trying to do something with it. It won’t intercept any legitimate commands, since those get processed without reaching the printing a parser error stage. And I’m not sure, but you may be able to change “that” to “[the building understood]” to get the name of the building into the error message.
I’ve dropped in Rule for printing a parser error when the player's command includes "[any adjacent building]": say "You can only ENTER or EXAMINE that.".
It works as expected when examining the shop but when doing anything with the bus stop (get bus stop for example), the interpreter hangs.
I ended up using a scenery item in the end. I think I was trying to bend Inform in ways it isn’t intended to be used.
I defined building as a type of room. Then defined two actions: building-entering and building-exiting.
A building is a kind of room.
building-entering is an action applying to one thing.
Understand
"enter [any building]"
or "go to [any building]"
or "go inside [any building]"
or "step inside [any building]"
or "head inside [any building]"
as building-entering.
Check building-entering:
if the noun is the location, say "You're already there." instead;
if the noun is not adjacent, say "You cannot go there from here." instead.
Carry out building-entering:
let aim be the best route from the location to the noun, using doors;
if aim is not a direction, say "You can't think how to get there from here." instead;
try going aim.
building-exiting is an action applying to one thing.
Understand
"leave [any building]"
or "exit [any building]"
or "vacate [any building]"
as building-exiting.
Check building-exiting:
if the noun is not the location, say "You are not there." instead.
Carry out building-exiting:
try exiting.
The Bus Stop is a room. The player is in the bus stop.
The Shop is a building.
The Shop is north from the Bus Stop.
The Bus Stop is outside from the Shop.
The shop-exterior is scenery.
The description of the shop-exterior is "Just a shop."
The shop-exterior is in the bus stop.
Understand "shop" as shop-exterior.
Well, it looks like this sends the parser into an infinite loop somehow. I don’t know why exactly. My suspicion is that checking to see whether the player’s command includes a token involves running the parser, and when you do that from within the printing a parser error activity something gets broken. I reported this as a bug.
This perhaps can be worked around by checking for “[any adjacent building]” in After reading a command and then checking the flag when printing a parser error:
Building mentioned is a truth state that varies.
Before reading a command:
now building mentioned is false.
After reading a command when the player's command includes "[any adjacent building]":
now building mentioned is true.
For printing a parser error when building mentioned is true: say "You can only ENTER or EXAMINE that building."
A building is a kind of room.
A building has some text called exterior description.
The Shop is a building.
The exterior description of The Shop is "Just a shop".
The Shop is north from the Bus Stop.
The Bus Stop is outside from the Shop.
but you’re right that this is fighting against the natural way of using Inform, and the scenery objects are the way to go! (In particular, if you get tangled up in the quirks of the parser, it’s usually better to find another way.)
I’m late here, but you might take a look at Easy Doors by Hanon Ondricek. It’s basically a simple way to handle scenery objects that can be ENTERed like doors, while not having directions assigned to them.
…though I’m sure there’s a more recent version than that one, because I remember hacking the route-finding code to use them. @HanonO do you remember where that version ended up?