Partitioning a room

Authoring Inform 7
1

Hey all. I’m attempting the sectioning off of a room into multiple areas, similar to what zarf used in Shade. The problem is, I feel as if I’m failing to see the forest for all the trees. It is as if I’m overlooking obvious solutions.

Hopefully, the code below illustrates things. How can it be improved, and are there any bugs I have missed?

Rule for printing the name of a room: say "[printed name in title case]" instead.

An area is a kind of thing.

the window is an area.
the middle of the room is an area.
the wall is an area.
the doorway is an area.

Placement relates various things to one area. The verb to be situated in implies the placement relation. The verb to grant (it grants, she is granting) implies the reversed placement relation.

[a kludge, yes. "It grants" not expressive at all, but I was at a loss as to what else to call it.]


The tacky sofa and the cushy chair are enterable containers.
The hardwood table and the windowsill are enterable supporters.
The bookcase is a container.

The sofa, the chair and the table are situated in the middle of the room.
The bookcase is situated in the wall.
The windowsill is situated in the window.
The player is situated in the doorway.


Before doing something when the action requires a touchable noun:
	consider the implicitly pass through other barriers rule;
	let M be a random area granting the noun;
	let N be a random area granting the actor;
	if M is not N:
		now the actor is not situated in an area;
		now the actor is situated in M;
		say "You cross over to [the M].".


The lounge is a room.

The sofa, the chair, the table, the bookcase and the windowsill are in the lounge.

Any takers? hopeful smile

2

Why not use “situates” instead of “grants?”

3

Dropped me brain, is why. :stuck_out_tongue: But yes, that’s a good suggestion. “Situates” makes it far more symmetric.

I think my main problem is deciding on where to take this. For instance, is it more logical to make the areas actual objects within the room as opposed to leaving them vague? What about slowdown? There’s going to be a lot of relations floating about, after all.

Also, I’m wondering what else would be needed in terms of functionality. I.e. picking something up, moving somewhere else, then dropping the item.

4

I think the only thing I would maybe add is something to define any enclosed object as being in the same area as the container/supporter/person in question rather than placing each enclosed object individually in an area, even if just for the sake of word economy.

However, when I did add this line:

The book is in the bookcase. It is situated in the wall.

… it produced the following result:

When I comment out all the placement rules, this issue doesn’t happen… so I’m not sure I can help that much with it right now, but I figured I could point it out. :slight_smile:

Also, you might want to make sure that carried items move between areas along with the player. I added the following:

The backpack is a container in the Lounge. It is situated in the wall. The book is in the backpack. It is situated in the wall.

… which produced:

It’s probably pretty easy to fix that, as well. If I get more free time, I’ll see if I can help at all ( assuming you don’t already have it ironed out by then :stuck_out_tongue: ).

5

Thank you. That is hugely helpful, and illuminates a few snags I didn’t consider. Specifically, that invoking the implicitly pass through other barriers rule (which I found so handy earlier) seems to throw a spanner in the works. Not to mention the fact that said rule is now called twice every time we try to physically touch something. :frowning:

I do know now that I’ll probably change the syntax to be “near” an area. Also, it may be smarter to change the area idea so that certain things can behave as landmark, and optionally.

If, for instance, the notion holds that

A thing can be a landmark. A thing is usually not a landmark.

then I’m figuring this’ll allow me to declare certain things (whether they are in the room or not) to be one of these landmarks, and allow other items be defined by their proximity to said landmarks. Some landmarks might be abstract (such as “the middle of the room”), so it feels sensible to allow for landmark items that aren’t present.

I only wish I could make heads or tails of the handling of implicit actions and the whole container/supporter business. Every time I try to wrap my mind around how I’d do this, I feel more stupid. If anyone here has any tips on where to start, I’d be indecently grateful.

6

I’m not sure how helpful this will be, but one thing I’ve been using to let the player’s situation change has been recurring scenes. As a bit of a alternate take on the Areas of your initial code, you could try to work with something like this:

[code]Mobility is a kind of value. The plural of mobility is mobilities. The mobilities are wandering, exploring, lounging, and observing. Every person has a mobility. A person is usually lounging.

The Middle Of The Room is a recurring scene. The Middle Of The Room ends when The Window begins. The Middle Of The Room ends when The Wall begins. The Middle Of The Room ends when The Doorway begins. The Middle Of The Room begins when the player is lounging.

The Window is a recurring scene. The Middle Of The Room begins when The Window ends. The Window begins when the player is observing.

The Wall is a recurring scene. The Middle Of The Room begins when The Wall ends. The Wall begins when the player is exploring.

The Doorway is a recurring scene. The Middle Of The room begins when The Doorway ends. The Doorway begins when the player is wandering.

The Doorway begins when play begins.

Before going a direction:
now the player is wandering.[/code]

… and then just associate various searching and action verbs with the ‘mobility’ value, which will trigger any given scene to begin. I’ve used this to varying degrees of success lately, though mostly with a Silent-Hill-themed game I’m working on … but the scenarios aren’t that much different from what I can tell.

Edit: Also, the above is -really- useful if you want to make a special trigger between certain locations… for example: if you want to set an event ( a trap, maybe ) to occur between the window and the bookshelf; this makes it fairly easy to code.

7

That technique makes for a great way to transition between rooms, but otherwise it’s not quite what I’m looking for. I’m looking at something that may need several rooms, and the functionality should ideally allow for expansion without the workload expanding at a geometric rate. While scenes are a great idea, I’m not sure how to use them for that purpose, nor how it would solve the in-room transitioning problem.

8

I myself would approach this from the other direction: don’t subdivide a room into multiple “area” objects, but build a narrative room out of several code rooms. Then instead of the problem of figuring out how to prohibit access, you have the problem of putting things from adjacent areas in scope and automatically describing them; this is not completely trivial, but it is doable, and there are several examples in the Recipe Book under Place > Continuous Spaces and the Outdoors.

9

That sounds like an awesome idea. I do have to wonder, though, if this would work with the implicit actions I spoke of. The idea would be that any character trying to physically interact with an item in the room would implicitly approach it if necessary. Is this model a good way to handle such things?

10

That exact behavior is covered in some of the examples.

11

I tried the Rock Garden example. It is quite snazzy, but as far as I can tell, it requires the presence of the player for the connections to work. I need something that would work for any actor, even if the player is not present, and I’m given to understand other actors don’t have a scope concept in quite the same way as the player.

12

Scope mostly works the same way for other people as for the player; the thing you need to watch out for is backdrops, which are single objects moved around the map so that the player can see them wherever he goes (and because they track the player, they intentionally don’t track other characters – otherwise the sun would be constantly winking out of the player’s room in order to go attend the rooms where NPCs were).

In other respects, though, you can still use scope if you write the rules more generally, using “after deciding the scope of someone” for instance.

Here’s a revised version of Rock Garden that allows for an NPC to play along:

[code]“Rock Garden”

Section 1 - General Rules

Intervisibility relates rooms to each other in groups. The verb to be connected with implies the intervisibility relation.

Definition: a room is inter-visible if it is connected with more than one room.

After deciding the scope of the someone (called the scoper) when the location of the scoper is an inter-visible room:
repeat with other place running through rooms which are connected with the location of the scoper:
unless the other place is the location of the scoper, place the other place in scope.

Rule for reaching inside a room (called target) which is connected with the location of the person reaching:
let way be the best route from the location of the person reaching to the target;
if the way is not a direction:
if the person reaching is the player:
say “You can’t get over to [the target] from here.”;
deny access;
if the person reaching is the player:
say “(first heading [way])[command clarification break]”;
try the person reaching trying going way;
if the person reaching is in the target, allow access;
otherwise deny access.

After an actor looking when the location of the person asked is an inter-visible room:
repeat with other place running through rooms which are connected with the location of the person asked:
if the other place is not the location of the person asked:
describe locale for other place.

Section 2 - The Scenario

Rock Garden West is west of Rock Garden East. Rock Garden East contains a rake. Rock Garden West contains a bench and a maple leaf. The bench is an enterable supporter.

Rock Garden West is connected with Rock Garden East.

Bob is a man in Rock Garden West. A persuasion rule: persuasion succeeds.

Report someone going:
if the room gone from is connected with the location and the room gone to is the location:
say “[The actor] comes over to you from [the room gone from].” instead;
if the room gone from is the location and the room gone to is connected with the location:
say “[The actor] heads off to [the room gone to], and is still visible from a distance.” instead.

Test me with “get rake / drop rake / sit on bench / get rake / drop rake / bob, get rake / bob, sit on the bench”.
[/code]

Aside from rewriting the scope rules, the only quirky bit is that the standard library does not expect you to be able to see both the starting and the ending locations when an NPC walks from one room to the next. So you need to add your own report rule (exemplified here) in order to make that look right.