Referencing objects in adjacent rooms - coding advice

Authoring Inform 7
1

After all these years of lurking around the forums and fantasizing about writing my first IF piece (which will be great, believe me :wink:)… I’ve finally started doing it. And stumbled across the first small problems (Hey, this isn’t as easy as I thought it would be).

The initial rooms of my story are actually not rooms, but outdoor locations in a rather open environment. So some of the objects that I implement in one “room” I do also mention in the descriptions of adjacent locations. I want the player to be able to reference those objects, so he doesn’t get the “You can’t see such a thing here.” answer, because that would be silly considering the room description just mentioned (e. g.) the meadow to the west.
I’m not satisfied with using backdrops, because the objects should have a very distinct behavior in the rooms they’re actually in. In the adjacent rooms the player should be able to reference them, but only get a rather generic answer, prompting him to go into a certain direction.

I hope I could make myself clear (sorry, English not my language of play in real life).

What I tried is the following code:

A thing can be eye-catching. 

Definition: a thing is neighbour if it is eye-catching and it is in a room adjacent to the location.

After deciding the scope of the player:
	repeat with X running through neighbour things:
		place X in scope.
		
A Before Rule:
	if the noun is a neighbour thing:
		let X be the location of the noun;
		let Y be the best route from the location to X;
		say "[The noun] is [Y] from here. You need to go there to have a closer look.";
		stop the action;
	if the second noun is a neighbour thing:
		let X be the location of the second noun;
		let Y be the best route from the location to X;
		say "[The second noun] is [Y] from here. You need to go there to have a closer look.";
		stop the action.

Pasture is a room. "Yummy green grassy meadow! There's a hut to the east.".

The Meadow is a eye-catching thing in Pasture. The description is "Yummy!".

At the hut is east of Pasture. "You're standing in front of a hut. To the west you can see a meadow.".

Test me with "x meadow / east / x meadow".

This works but I am unsure if this is the best way to do it. Isn’t it bad style to have such a generic Before rule that will fire without any conditions? Any better way to solve this problem?

(by the way, I’m using I7-6G60 and the actual game is in German using the language extension by Team GerX)

Looking forward to your answers. Thank you!

2

Well, you could break your rule up into two rules: “Before doing something when the noun is a neighbour thing” and “Before doing something when the second noun is a neighbour thing.” Then the rule won’t fire for every object.

That’ll make a minor difference in behavior – if the noun and the second noun are both neighbour things, then the message won’t print for both of them. But that seems to me like it might be desirable.

3

Thank you matt. So there’s no possibility to attach a condition that’s considering noun AND secound noun at the same time? So the following code:

Instead of doing something to a neighbour thing, ... Instead of doing something with a neighbour thing, ...

are equivalents and will always only check the noun and never the second noun, correct?

BTW, this is what I made of this thing - I’m a little proud but considering it took me half a day… :laughing:

[rant][code]
A thing can be regionally visible. [A regionally visible thing can be referenced in all of the rooms of its region.]

Distance visibility relates various things to various rooms. The verb to be visible from implies the Distance visibility relation. [To make things visible from certain rooms, not considering regions. Both methods can be mixed.]

Definition: a thing is interesting from far:
if it is regionally visible and the map region of the location of it is the map region of the location of the player and the location of it is not the location of the player, yes;
if it is visible from the location of the player, yes;
no.

After deciding the scope of the player:
repeat with X running through things that are interesting from far:
place X in scope.

Before doing something when the noun is a thing that is interesting from far:
prompt to go closer to the noun;
stop the action.

Before doing something when the second noun is a thing that is interesting from far:
prompt to go closer to the second noun;
stop the action.

To prompt to go closer to (target - a thing):
let X be the location of the target;
let Y be the best route from the location to X;
say “You need to go [Y] to get to [the target].”.
[/code][/rant]

4

Looks pretty good to me, for what that’s worth.

5

Thanks!

Man, that’s fun! I’m nearly there:

[rant][code]A thing can be regionally visible. [A regionally visible thing can be referenced in all of the rooms of its region.]

Distance visibility relates various things to various rooms. The verb to be visible from implies the Distance visibility relation. [To make things visible from certain rooms, not considering regions. Both methods can be mixed.]

Definition: a thing is interesting from far:
if it is regionally visible and the map region of the location of it is the map region of the location of the player and the location of it is not the location of the player, yes;
if it is visible from the location of the player, yes;
no.

After deciding the scope of the player:
repeat with X running through things that are interesting from far:
place X in scope.

Rule for reaching inside a room when the noun is a thing that is interesting from far:
prompt to go closer to the noun, for touching;
deny access.

Rule for reaching inside a room when the second noun is a thing that is interesting from far:
prompt to go closer to the second noun, for touching;
deny access.

Instead of doing something when the noun is a thing that is interesting from far, prompt to go closer to the noun, for looking.

Instead of doing something when the second noun is a thing that is interesting from far, prompt to go closer to the second noun, for looking.

To prompt to go closer to (target - a thing), for touching or for looking:
let X be the location of the target;
let Y be the best route from the location to X;
if for touching, say “You need to go [Y] to handle [the target].”;
if for looking, say “You should go [Y] to get a closer look at [the target].”.

Room1 is west of Room2.

The box is an opaque open openable container in Room1.
The ball is a thing in the box. The ball is visible from Room2.
The coffin is an opaque open openable enterable lit container in Room2.[/code][/rant]

Now I got different answers, depending on whether I would need to touch or only see the ball. Still, I want to make sure that the ball is not in scope when either it is in the closed box or the player is in the closed coffin. Any idea where and how to do it? I tried it with “if X can see the location of X” in the “Deciding the scope” rule, but obviously a room can never be seen, only its contents.

1 Like
6

There is an example in the Manuals which handles this exact behavior, I believe it is called “Fairground”. You might want to look at that.

One other small suggestion: you could write something like this to make your rules cleaner.

[code]To decide whether we need to touch something from afar:
if the noun is interesting from far and the action requires a touchable noun, yes;
if the second noun is interesting from far and the action requires a touchable second noun, yes;
no.

Rule for reaching inside a room when we need to touch something from afar…
[/code]

7

Thank you. The example is actually called “Carnivale” and I’ve been looking at it. It does manage the problem in a simpler way (always giving the same message, no matter why the “reaching inside a room” is called) – which would probably be just enough for me, but I’ve become so stuck in this scenario that I want a more general solution for it (it’s quite a good way to learn coding in I7).

Your code does clean up a little bit, but then I don’t know if the “reaching inside a room” was called because of the noun or because of the second noun, do I? I’ve tried using “particular possession”, but that seems to work only for “deciding the concealed possessions”.

Still working on it, I will post my code when I feel I’ve somehow mastered it. Thanks for all your replies.

8

I reworked it a little and now it (almost) fulfills my purposes. I’d love to have some feedback from the experienced I7 writers… what would you have done differently, where do you see problems? I know it’s a bit of code to read, but if anyone invested her/his time, I’d be grateful, because I’m eager to learn… :unamused:

[rant][code]Distance visibility relates various things to various rooms. The verb to be distantly visible from implies the Distance visibility relation.

A thing has a text called distant description.

After deciding the scope of the player (this is the put distantly visible things in scope rule):
repeat with X running through things that are distantly visible from the location of the player:
if X has a clear view and the player has a clear view, place X in scope.

To decide whether (X - a thing) has a clear view:
let A be an object;
now A is the holder of X;
while A is not a room:
if A is a closed opaque container, decide no;
now A is the holder of A;
decide yes.

The can’t touch distantly visible things rule is listed before the access through barriers rule in the accessibility rulebook.
Accessibility rule (this is the can’t touch distantly visible things rule):
if the action requires a touchable noun and the noun is a thing that is distantly visible from the location of the player:
prompt to go closer to the noun, for touching;
stop the action;
if the action requires a touchable second noun and the second noun is a thing that is distantly visible from the location of the player:
prompt to go closer to the second noun, for touching;
stop the action.

The handling distantly visible things stage rule is listed after the instead stage rule in the action-processing rulebook.
This is the handling distantly visible things stage rule:
Unless the noun is a thing that is distantly visible from the location of the player or the second noun is a thing that is distantly visible from the location of the player, continue the action;
abide by the handling distantly visible things rulebook.

The handling distantly visible things rules are an action based rulebook. The handling distantly visible things rules have default no outcome.

Last handling distantly visible things rule (this is the need to get closer to distantly visible things rule):
if the noun is a thing that is distantly visible from the location of the player:
prompt to go closer to the noun, for looking;
stop the action;
if the second noun is a thing that is distantly visible from the location of the player:
prompt to go closer to the second noun, for looking;
stop the action.

Handling distantly visible things for Examining (this is the special descriptions for distantly visible things rule):
unless the noun provides a distant description, make no decision;
if the distant description of the noun is “”, make no decision;
say the distant description of the noun;
say paragraph break;
rule succeeds.

To prompt to go closer to (target - a thing), for touching or for looking:
let X be the location of the target;
let Y be the best route from the location to X;
if for touching, say “You can’t reach [the target], since it is [Y] from here.”;
if for looking, say “You should go [Y] to get closer to [the target].”.

Room1 is west of Room2.

The box is an opaque open openable container in Room1.
The lamp is a thing in the box. The lamp is distantly visible from Room2. The description of the lamp is “Its red flickering light lifts your mood.”.
The small hut is a thing in Room1. The hut is distantly visible from Room2. The description of the hut is “From close you see a lot of cracks in its masonry.”. The distant description is “From far away it looks nice.”.
The coffin is an opaque open openable enterable lit container in Room2.
The ball is a thing in Room2.

Test one with “x lamp / x hut / e / x lamp / x hut / look under lamp / look under hut / take lamp / take ball / throw ball at lamp”.
Test two with “enter coffin / close coffin / x lamp / take lamp / throw ball at lamp / look under lamp / open coffin / get out”.
Test three with “w / close box / e / x lamp / take lamp / throw ball at lamp / look under lamp”.
Test me with “test one / test two / test three”.[/code][/rant]

What bugs me most is the “To decide whether (X - a thing) has a clear view:” part. Doesn’t look too elegantly to me and also it doesn’t check for darkness. Any idea how to do this better?
Thanks in advance!

9

On a quick check, wouldn’t you get the same effect as your code just by checking “If A is enclosed by a closed opaque container”?

Checking for this stuff and darkness can be complicated; one thing is that you might want to check whether the player is in a closed opaque container, and whether the player is in the same container as A…

Checking darkness is tricky. Look at example 81, “Unblinking” (and the previous version had a bug in the code, so this stuff is tricky even for the most experienced I7 programmers).

10

There’s a much cleaner way to test for light or darkness.

Definition: a room is light-filled rather than darkness-filled if I6 routine "OffersLight" says so.

Warning: this is an expensive function that is only called once per turn normally, be careful about using it too frequently. (It’s still faster than the method in Unblinking though.)

One thing I’m noticing right away is that examining is coded as a special case. There are other actions which don’t require touchability, and in this system you’d need to write a special rule for each one. It’s also possible for an action to require a touchable noun but only a visible second noun or vice versa, e.g. “photograph mountain with camera” would require the camera to be touchable but not the mountain.

This code from one of my WiPs might help. I think it’s based on one of the examples but I can’t remember which.

To decide whether (item - a thing) must be touched:
	if the item is the noun and the action requires a touchable noun, yes;
	if the item is the second noun and the action requires a touchable second noun, yes;
	no.

To decide whether (table - a supporter) must be touched indirectly:
	repeat with the item running through things on the table:
		if the item must be touched, yes;
	if the table must be touched, yes;
	no.

To decide whether (box - a container) must be touched indirectly:
	repeat with the item running through things in the box:
		if the item must be touched, yes;
	if the box must be touched, yes;
	no.
11

I’m not sure what you need the “must be touched indirectly” code to do, but would you want to make that recursive to take care of the case where the noun is on top of a tray which is on top of a table?

12

Thanks for your hints, matt and Draconis. I will look at your ideas and code tonight, haven’t had time yet.

Actually, my Last handling distantly visible things rule (this is the need to get closer to distantly visible things rule) captures all the actions that haven’t been coded explicitly. I could add more exceptional handling (e. g. Handling distantly visible things for Photographing the mountain…), but at the end, everything that wasn’t captured by those special cases finally ends up at the aforementioned last rule of the rulebook. My new “Handling distantly visible things rulebook” is not much different from the Instead rulebook, except that it is only relevant for actions that include “distantly visible” nouns or second nouns (or both).

13

I think I made this work the way I wanted to and I put it into a small extension:

Distantly Visible Things
“Provides flexible handling of things that can be seen in multiple rooms, but - unlike backdrops - still have one distinct location.”

I don’t know if anybody wants to use it - it’s not a big deal, but could be something that other authors would want to implement. So if you are interested in using, testing or maybe giving me some feedback: feel free to answer or PM me, I can send you the extension. A documentation and examples are provided and it should be 6L02 ready.
(I don’t know if there’s an official way to make extensions public, but since it’s my first “work” and it’s only a small implementation I’d rather not make a fool of myself :confused: )

And thanks again for your help!

14

Try submitting it to the Github repository, it’s where most WiP and currently-being-tested extensions are kept.

15

I’ll try this out, thanks!

16

Okay, so my new extension is up on Github, it’s called “Distantly Visible Things” and you can find it here:

https://github.com/i7/extensions/tree/master/Marc%20von%20der%20Heiden

I’d love to get some feedback, since it’s my first extension. Feel free to suggest changes, reword the documentation (as I said, I’m no native speaker of English) or anything you like…

17

Small suggestion: put a make no decision at the end of your after deciding the scope rule, so it doesn’t block other rules in that rulebook.

18

I think that only the “for” rules for each activity have default outcome success, the before and after rules (I used an after rule for adding to the scope) have default outcome “no outcome”. This is why I didn’t mention it explicitly. I tried it with an example and the scoping rules seem to add up the way it is.

19

Really? I remember having a bug in my (non-6L02) project caused by those rules not stacking.

20

I’m not a hundred percent certain, but the example I tried did work (also non-6L02). But you’re probably right: adding the line at the end of the rule does no damage at least.
But maybe anybody else knows it for sure?