One room visible from another room? Scope?

Authoring Inform 7
1

I’m trying to make a sheriff’s office with an attached jail cell, where each room can be viewed from the other. I was able to find this thread (Viewing objects from another room) which directed me towards 18.29. Deciding the scope of something.

An example in the documentation says:

The Cloakroom is a room. "This is just a cloakroom, but through a vague, misty mirror-window you can make out the Beyond." After looking in the Cloakroom, say "In the mirror you can see [list of things in the Beyond]."

After deciding the scope of the player while in the Cloakroom: place the Beyond in scope.

The Beyond is a room. Johnny Depp is a man in the Beyond.

Following the example in the documentation, I came up with this:

[SHERIFF'S OFFICE]
The Sheriff's Office is northeast from the Village Square.
The description of the Sheriff's Office is "An open doorway leads southwest to the village square."

After deciding the scope of the player while in the Sheriff's Office: place the Jail Cell in scope.

[JAIL]
The jail door is a locked door.
The jail door is north from the Sheriff's Office.
The description of the jail door is "A door with iron bars.  The jail door is currently [if the jail door is open]open[otherwise]closed[end if]."

The jail key unlocks the jail door.
The description of the jail key is "A heavy iron key."

The Jail Cell is north from the jail door.

After deciding the scope of the player while in the Jail Cell: place the Sheriff's Office in scope.

which yielded:

Problem. You wrote 'After deciding the scope of the player while in the Sheriff's Office'  : but I don't understand the 'when/while' clause, which should name activities or conditions.

 See the manual: 18.4 > 18.4. While clauses
--------------------------------------------------------------------------------
Problem. You wrote 'After deciding the scope of the player while in the Jail Cell'  : again, I don't understand the 'when/while' clause.

What am I missing?

EDIT:
I am also not sure exactly what kind of interactions being “in scope” covers, I was just trying to get SOMETHING working so I could start fiddling with it. My goal is that characters should be able to talk back and forth between rooms, but objects should (probably) not be taken between rooms (unless they’re in reach somehow). Not 100% sure where I’m going with this but would like to get started tinkering. The idea is that the jail cell has bars, so you can see and talk through them and maybe even grab something if it’s close, but generally not have access to most things in the other room.

2

Well, you might take a look at my own recent post for something somewhat similar: How to Use Does the Player Mean with Scope

It was a rough test mainly focusing on being able to look at one person in another room, but if there was any question as to who to look at, it would focus on those in the same room first.

I went back to it and tweaked it a bit using what you are looking for, and think I had it working. Take a look.

[ Room Creation ]
Scope Testing is a room. The description is "Altering Focus / Clarification for Objects in Scope but not in Location[paragraph break]You see a bunker to the north.".

a shiny penny is in Scope Testing. The description is "A single penny that shines like new.".

A rule for reaching inside Scope Testing when the noun is a shiny penny: say "You reach through the slits of the bunker wall."; allow access. 

Bunker is a room. It is north of Scope Testing. The description is "A protective bunker. There are small slits in which you can see out. An exit to the south leads to the barren wastes of Scope Testing".

a big red button is a device in Bunker. a big red button is switched off. Instead of pushing a big red button, try switching on a big red button.
Instead of switching on a big red button:
	if Fred is in the location:
		say "Sorry, only one Fred per person.";
	else:
		now Fred is in the location;
		say "A Fred materializes out of nowhere.";


[ Setting Scope so one room can have 'windows' to view people outside of it ]
After deciding the scope of the player when the location is Bunker:
	place Scope Testing in scope;
	[let L be a list of people;
	now L is the list of people in Scope Testing;
	repeat with P running through L:
		place P in scope;]
		

[ Creation of Body Parts ]
a body part is a kind of thing. 

eyes are a kind of body part. eyes are a part of every person.
nose is a kind of body part. nose is a part of every person.
mouth is a kind of body part. mouth is a part of every person.


[ Creation of People + Descriptions ]
Bob is a man in Scope Testing.
The description of Bob's eyes is "Bob has evil eyes.".
The description of Bob's nose is "Crooked, like the man himself.".
The description of Bob's mouth is "Always curled into a sneer.".


Fred is a man.
The description of Fred's eyes is "Fred has no eyes!".
The description of Fred's nose is "Long and narrow.".
The description of Fred's mouth is "Straight-faced.".


The description of your eyes is "You have dull eyes.".
The description of your nose  is "Bigger than you'd like.".
The description of your mouth is "Full of rotten teeth."


[ Definitions ]


[ Does the Player Mean ]
Does the player mean doing something to something not held by the player: it is likely.
Does the player mean doing something to something when the location of the noun is not the location: it is unlikely.

Okay, that may be a lot of extra code, as it has my own stuff as well as what I tried. Primarily though, focus on these bits:

[ Room Creation ]
Scope Testing is a room. The description is "Altering Focus / Clarification for Objects in Scope but not in Location[paragraph break]You see a bunker to the north.".

a shiny penny is in Scope Testing. The description is "A single penny that shines like new.".

A rule for reaching inside Scope Testing when the noun is a shiny penny: say "You reach through the slits of the bunker wall."; allow access. 


Bunker is a room. It is north of Scope Testing. The description is "A protective bunker. There are small slits in which you can see out. An exit to the south leads to the barren wastes of Scope Testing".


After deciding the scope of the player when the location is Bunker:
	place Scope Testing in scope;

First we created our rooms, I tossed a penny in the starting room for testing. “The rule for inside” part can be read up on at 12.18. Changing Reachability.

It seems if you just use scope, it is mostly for examining/listing things as far as I can tell (which is what I wanted in my original test). But to access things, you need to be able to reach them. 12.16 and the next couple of chapters also hit on this as well as other useful things for this sort of stuff.

So that line about reaching is specific to the room (called Scope Testing) and the object (called shiny penny). You could also put all sorts of other specific requirements depending on your case. Perhaps only when a scene was happening, or a person wasn’t in the room, or the penny was not carried by anyone - that sort of thing.

You could also make it deal with more objects within the rule, having if statements and such as needed. Really a lot of options, but depends on your needs. I’m still a novice myself, but hopefully that gets you started.

If you need some more help or explanation, feel free to ask!

3 Likes
3

Thanks for the feedback! I’ll play around with this and see if it helps. I am super novice, not a coder at all. So I easily get lost.

4

Scoping stuff from a second room is a pain. Can you make the cell an enterable openable transparent container? You can fake it being a real location:

The sheriff's office is a room.
The jail cell is an enterable transparent open openable container in the sheriff's office.
before an actor going south when the location is the sheriff's office, instead try the actor entering jail cell.
before an actor going north when the jail cell holds the actor, instead try the actor exiting.

There are various default messages you’ll want to change, too, but it’s time for bed so I’m not going to try to comment on them…

2 Likes
5

Not a problem. Another quick note, I just looked at your code and error you mentioned again. You might try changing your lines:

After deciding the scope of the player while in the Sheriff's Office: place the Jail Cell in scope.
...
After deciding the scope of the player while in the Jail Cell: place the Sheriff's Office in scope.

to

After deciding the scope of the player while the player is in the Sheriff's Office: place the Jail Cell in scope.
...
After deciding the scope of the player while the player is in the Jail Cell: place the Sheriff's Office in scope.

Seems “while in the Jail Cell” caused the error, while “while the player is in the Jail Cell” (or Sheriff’s Office) works. My bad for not noticing that first.

This alone will let you examine things in the jail cell from the office (or vice versa). Though note you will have to actually have it described manually at some point. That is, if you put the key in the Jail Cell, you can type “x key” and it works, but it won’t actually list the key in your room description or anything.

There are many ways to deal with this. Using “list of things in Jail Cell” is one such that could be appended to various locations, such as:

The description of the Sheriff's Office is "An open doorway leads southwest to the village square. A jail cell rests at the north side of the office.Inside, you can see [list of things in Jail Cell]."

That does have the odd side-effect of saying you can see nothing. It makes sense, but may read oddly to you. It can be handled with a simple if-statement.

The description of the Sheriff's Office is "An open doorway leads southwest to the village square. A jail cell rests at the north side of the office. [if there is anything in Jail Cell]Inside, you can see [list of things in Jail Cell].[end if]"

Likewise, you could require more effort, such as looking at the door, searching it, or whatever else your story calls for. But if you want to TAKE the object from the outside, that is where the reachability I mentioned in the prior post goes into detail.

The jail key is in the Jail Cell.
A rule for reaching inside Jail Cell when the noun is a the jail key and the player is in Sheriff's Office: say "You reach through the narrow bars of the jail door and scoop up the key."; allow access
1 Like
6

Dredging up old memories of version changes…

I believe “while in [room]” is an old syntax that was removed a few versions ago, in…6L38, I think? The issue is that “while in [room]” and “while the player is in [room]” behaved slightly differently—the former was a synonym for “while the location is [room]”, so it would be true if the player was e.g. in a vehicle in the room, while the latter would not be. This was considered unnecessarily confusing.

The examples should have been updated for this; you can just say “when the location is [room]” now.

EDIT: Nope, it was 6L02. Finally found it in the changelog.

3 Likes
7

Thanks for all the tips, everyone! I’ll experiment with it tonight.

8

Thanks to some extensive efforts to clarify this by @drpeterbatesuk, I’ve come to understand that something being “in scope” effectively means that the parser will try to match words of player input to it when generating a command. If an object is not in scope, it can’t be the noun or second noun of an action, or the person asked for a command to an NPC.

Scope is by default driven by the visibility relation per the spatial model provided by the Standard Rules. Scope can be modified with rules related to the deciding the scope of... activity.

The parser checks the words of player input against all objects determined to be in scope. Use of the keyword any in a grammar line for an action, e.g. Understand "consider [any thing]" as considering. for a hypothetical considering action, lets the parser alter the scope for the purposes of evaluating that grammar line only. (I think.)

You want generic changes in scope, so the rule-based approach is probably best. You probably want to use the phrase place the contents of <room> in scope though – otherwise the room object itself is placed in scope, which is atypical.

In addition to basic questions of scope, the parser will eliminate objects from consideration if they don’t match the profile specified by the grammar line. As an example, the someone keyword requires that the matched object be a person, so Understand "chat with [someone]" as chatting. won’t let the command >CHAT WITH MAILBOX parse as the action chatting with the mailbox unless the mailbox is a person (or another person-derived kind), or unless there is a person whose name matches (e.g. a person called a mailbox repair technician) that is in scope. Things added to scope count as “visible” in the narrow sense seen in action definitions such as Considering is an action applying to one visible thing.; note that this is not exactly the same sense of visible as the visible adjective defined by the Standard Rules, which relies on the visibility relation (i.e. the ability to see things according to the spatial model).

After the parser resolves scope and successfully matches a grammar line, an action is generated and the action processing rules kick in. (These are the well-known Before, Instead, Carry out, etc.) Just after the Before rules are processed assorted lesser-known rulebooks kick in, most importantly here the one involving reachability. Any action that requires a touchable object will fail if the object can only be seen by the actor. Many actions in the Standard Rules require this, sometimes perhaps unexpectedly. You will need to write rules to allow any exceptions to reachability that you want to enable. (This sort of thing will be an issue whether you set up the jail cell as a separate room or an enterable container.)

As Zed says, you can just make the cell into a container and avoid the hassle of scope modification entirely. That approach probably fits better with the implicit world model used by Inform.

Speech-like actions (i.e. asking it about, answering it that and telling it to) all require that the target of the spoken content be touchable – this seems to be used as a proxy for modeling continuity of the air medium between the actor and the target, as the same applies to the listening and smelling actions. You’ll have to make some modifications so that talking with people in the cell will work.

Asking about is speech-like action.
Answering that is speech-like action.
Telling about is speech-like action.

A container can be porous.

The gaol is a locked enterable transparent porous fixed in place container in Sheriff's Office.

The player carries a brass key. The brass key unlocks the gaol.

A person called a jailbird is in the gaol.

Reaching inside something porous when speech-like action: [these require touchability, not just visibility]
    allow access.

There are still more things to deal with to get the output to look “pretty,” but a rule for writing a paragraph about the gaol will probably serve well for that purpose.

If you want to go the multiple rooms route, then similarly (and note that this is very close to RB Ex 366 “Rock Garden”):

Mutual visibility relates rooms to each other in groups. The verb to be clearly visible from means the mutual visibility relation.

The Jail Cell is clearly visible from the Sheriff's Office.

Definition: A room is expansive if it is clearly visible from a room that is not it.

After deciding the scope of the player when the player is in an expansive room:
    repeat with R running through rooms clearly visible from the location:
	    place the contents of R in scope.

After looking while the player is in an expansive room:
    repeat with R running through rooms clearly visible from the location:
	    carry out the  printing the locale description activity with R;
    continue the action.

Definition: A room is surveyed if it is clearly visible from the location.

Reaching inside a surveyed room when speech-like action:
    allow access.
4 Likes
9

This is a very confusing aspect of Inform syntax.

The narrow sense of “visible” seen in action definitions such as Considering is an action applying to one visible thing. is actually synonymous with “in scope”, rather than the sense of visible defined by the visible adjective, i.e. something which can be seen. Objects placed in scope using the ‘deciding the scope of’ activity become forcibly “in scope” (and so “visible” in the first sense, i.e. they can be referred to in a command in order to generate an action) but they are not at the same time necessarily made “visible” to the player/actor in the latter sense- i.e. if the player/actor couldn’t see them before, then they still can’t necessarily see them- they will only be made “visible” in the latter sense if the player/actor is not in the dark.

For more information on the meaning of scope, see here.

1 Like
10

And of course “one visible thing” in action definitions being broader than “one thing”. Out of all the weird inconsistencies in Inform’s syntax, I think this one qualifies as the most confusing.

I don’t know what a better adjective for “need not be touched” would be, but if anyone invents one it could be worth a pull request (not to remove “visible thing” but to add an alternative to it).

1 Like
11

Probably nothing better than ‘one thing in scope’…

1 Like
12

“one visible thing” means “one thing in the game” so a single word version could be “one diegetic thing” but you’d have to be a certain kind of literature, writing, or gaming nerd to already know that word…

2 Likes
13

If the world could be made anew, the best approach would probably have been to have:

‘one object’ to mean one object in scope (equivalent to ‘one visible thing’ as Inform actually has it)

‘one touchable object’ to mean one touchable object (equivalent to ‘one thing’ or ‘one touchable thing’ as Inform actually has it)

‘one carried object’ to mean one carried object (equivalent to ‘one carried thing’ as Inform actually has it)

Sadly, we must live in the broken world as it is :frowning:

2 Likes
14

er, I don’t think we can say that. Actions don’t care about scope. Grammatical tokens in understand lines care about scope. one visible thing means that the basic accessibility rule won’t care whether the noun is touchable and the carrying requirements rule won’t care whether the noun is carried. That is, that any game object – direction, room, region, or thing (in or out of play) could be usable with this action, provided an understand line gets us there.

Lab is a room.
Conservatory is a room.

fooing is an action applying to one visible thing.
understand "foo [any thing]" as fooing.
understand "foo [any room]" as fooing.
understand "foo [any region]" as fooing.

report fooing: say "Foo [noun]."

The house is a region.
The box is a thing. [out of play]

test me with "scope / foo conservatory / foo north / foo house / foo box".

yields

>[1] scope
1: yourself (582487)
 
>[2] foo conservatory
Foo Conservatory.
 
>[3] foo house
Foo house.
 
>[4] foo box
Foo box.
 
>

edited to correct myself: The basic accessibility rule already doesn’t care if the noun is a region or room; with one visible thing it also won’t care whether or not the noun is a direction, or a thing that isn’t present or can’t be touched.

2 Likes
15

An interesting semantic distinction.

I have always thought of [any …] tokens as overriding the usual requirements of scope implicit in constructing any action from a command, but I see how understanding ‘Understand tokens’ as the policemen of scope makes more sense, philosophically and in how the parser and action-processing actually operate. So in this paradigm:

Action definitions:
(i) restrict whether one or two objects and/or values can be used in the construction of an action
-these restrictions apply whether the action is constructed from a command, e.g. ‘Take the banana’ or in code, e.g. ‘try taking the banana’
-any action to be generated from a typed command or in code must match this basic definition or be rejected by the parser or compiler respectively
(ii) may add certain other requirements which are tested after the action is constructed and action-processing is already underway
-i.e. touchability/carriage of objects and/or the presence of light- specifically after the Before stage has had opportunity to intervene (by, for example, trying an ‘implicit take’ for an object which must be carried.)

Between the operation of stages (i) and (ii) defined in the action definition, in the case of actions generated from typed commands, Understand tokens:
(a) may restrict further what kinds of objects or values can be referred to in the command in order for it to be successfully translated to an action
- e.g. [someone] means that an object referred to in the action definition as a ‘visible thing’ must in fact, in a typed command, be a person
(b) enforce scoping rules, such that in the absence of the preceding word or prefix ‘any’, only objects that are ‘in scope’ can be referred to in a typed command in order to to construct an action
-N.B. scope does not apply to values, so for example [number] does not require ‘any’ to precede it (although [any number] does compile)

Naturally, as suggested above ‘Understand tokens’ are only used in parsing typed commands, not when code generates actions as in ‘try taking the banana’. Consequently, scope plays no part in code-generated actions, which can ignore all usual considerations of scope.

Similarly, code can generate actions including objects that no ‘Understand’ line would allow. For example, if you have 'Understand “Insult [someone] as insulting” as the only typed command-based syntax for the insulting action, code can still say ‘try insulting the banana’, which will not only compile but will also generate and run the action to insult the banana, ignoring restrictions of both scope and person.

However, restrictions to do with touchability, carriage and requirement for light appearing in an action definition will still kick in after the Before stage of any code-generated action. So if the action definition of insulting is ‘Insulting is an action applying to one touchable thing’, ‘try insulting the banana’ will only work if the banana can be touched, (barring any intervention at the Before stage to make it touchable).

3 Likes
16

Thanks for all the feedback. I haven’t had the opportunity to work on my game for the last few days, but I’m sitting down with it again now. I’m trying to implement the jail cell as a transparent container in the sheriff’s office.

Currently the description of the sheriff’s office is:

The description of the Sheriff's Office is "An open doorway leads southwest to the village square.[paragraph break]To the north is a [jail cell].[if there is anything in the Jail Cell]  Through the bars you can see [a list of things in the Jail Cell].[end if]".

Yielding:

Sheriff's Office
An open doorway leads southwest to the village square.

To the north is a jail cell.  Through the bars you can see a doodad.

You can see Sheriff Ogo and Deputy Glupp here.

>

Consequently, the view from the jail cell is:

Sheriff's Office (in the jail cell)
An open doorway leads southwest to the village square.

To the north is a jail cell.  Through the bars you can see yourself and a doodad.

You can see Sheriff Ogo and Deputy Glupp here.

>

which I’d rather be something like:

The description of the Jail Cell is "In the cell you can see [list of things in the Jail Cell].[paragraph break][if there is anything in the Sheriff's Office]Outside the bars, you spy [a list of things in the Sheriff's Office].[end if]".

Though obviously this is a description of a container and not a room description. Apparently it’s not possible to put nested ifs in a room description so I can’t just put [if the player is in the jail cell][otherwise] in the description of the Sheriff’s Office (because there are other ifs in these descriptions). Is there a simple way to toggle the room description based on whether the player is in the room proper vs in the container in the room?

17

A workaround for this is to break out the description into a full routine, e.g.:

The description of the Sheriff's Office is "[office_description]"

To say office_description:
    if ....
        if...
    otherwise...
1 Like
18

A strength of I7 is how modifiable and customizable it is, and the rules surrounding room descriptions are a great example of this. But that modifiability means there are a lot of moving parts and it’s hard to learn what bits you should change for what.

Check out Room Descriptions in the Recipe Book and its examples. And daunting as it is, read Chapter 18: Activities in Writing in Inform: most of how room descriptions are generated are in various activities, detailed there.

I’ll try to get into some specifics tomorrow…

1 Like
19

If you’re willing to be flexible about the structure of your output in order to work with the default machinery for room descriptions, something along the lines of the following may do the trick:

Rule for writing a paragraph about the gaol (this is the view of the cell from the office rule):
    say "To the north is a jail cell. Through the bars you can see [a list of things in the gaol]."

Definition: a thing is incarcerated rather than unincarcerated if it is enclosed by the gaol.

Rule for printing the locale description of Sheriff's Office when the player is incarcerated (this is the view of the office from inside the cell rule):
    say "The Sheriff's office is to the south. Through the bars you can see [a list of unincarcerated visible things that are not the gaol]."
1 Like
20 
The description of the Sheriff's Office is "[office_description]".

To say office_description:
	if the player is in the Jail Cell:
		say "In the cell you can see [list of things in the Jail Cell].[paragraph break][if there is anything in the Sheriff's Office]Outside the bars, you spy [a list of things in the Sheriff's Office].[end if]";
	otherwise:
		say "An open doorway leads southwest to the village square.[paragraph break]To the north is a [jail cell].[if there is anything in the Jail Cell]  Through the bars you can see [a list of things in the Jail Cell].[end if]".

When in the Sheriff’s Office, there’s an unexpected paragraph break and indentation when describing the jail cell. Any idea why that’s happening?


To the north is a jail cell.
  Through the bars you can see a doodad.


You can see Sheriff Ogo and Deputy Glupp here.

>

The view from the jail cell lists the jail cell, even though I used “the jail cell is undescribed”. How do I stop that?

Sheriff's Office (in the jail cell)
In the cell you can see yourself and doodad.

Outside the bars, you spy Sheriff Ogo, Deputy Glupp, and a jail cell.


>