Preference an action during a scene

Okay, here’s a more functional version that demonstrates the challenge I’m having:

Part - Room_Navigating

A person can be discouraged_from_compass_navigating or not discouraged_from_compass_navigating.

Room_navigating is an action applying to one thing.
Understand
	"go back/- to/around/near/by/-- [any room]",
	"return to [any room]",
	"walk to/-- [any room]",
	"run to/-- [any room]",
	"follow [any room]" 
	as room_navigating.

Check room_navigating:
	if the noun is the location, say "Well, happily you're already here." instead;

Carry out room_navigating:
	let initial location be the location;
	let the destination be the noun;
	if the initial location is the destination,
		say "." instead;
	let heading be the best route from the initial location to the destination;
	say "(DEBUG room_navigating: heading toward [noun] is [heading])[line break]";
	if heading is nothing:
		say cant_find_that instead;
	else:
		now player is not discouraged_from_compass_navigating;
		try going heading.

Part - Elusive_Landmarks and Landmark_navigating

An elusive_landmark is a kind of thing.

The_distance is a container.
The_distance is in Limbo.
[ Definition: an elusive_landmark is distant if it is in the_distance. ]

landmark_navigating is an action applying to one visible thing.
Understand
	"go to/near/by/-- [any elusive_landmark]",
	"walk to/near/by/-- [any elusive_landmark]",
	"run to/near/by/-- [any elusive_landmark]",
	"landmark_navigate [any elusive_landmark]"
	as landmark_navigating.

Check landmark_navigating:
	if the noun is touchable:
		say "Well, that's right here." instead;
	if the noun is not in the_distance:
		say cant_find_that instead;

To say cant_find_that:
	say "You're no longer sure how to get there.";

Carry out landmark_navigating:
	say "You head toward the [noun].";
	move_within_dark_woods;
    try looking.

To move_within_dark_woods:
    let distant_thing be a random elusive_landmark in the_distance;
    let next_thing be a random elusive_landmark in Limbo;
    let past_thing be a random elusive_landmark in location;
    now distant_thing is in location;
    now next_thing is in the_distance;
    now past_thing is in Limbo;

The can't reach inside rooms rule does nothing if landmark_navigating.

The can't reach inside rooms rule response (A) is "You can't get there from here."

Part - Rooms & Stuff

Dark Woods is a room.
"[dark_woods_desc].".

To say dark_woods_desc:
    let distant_thing be a random elusive_landmark in the_distance;
    say "It's dark and woody. You see [the distant_thing] in the distance";

The white tree is an elusive_landmark in The_distance.
Understand "tree" as white tree.

The madrone tree is an elusive_landmark in Dark Woods.
The tree stump is an elusive_landmark in Limbo.

Top of the Tree is a room [west of Dark Woods].
Understand "tree" as Top of the Tree.

And running it:

>look
[looking]
Dark Woods
It’s dark and woody. You see the white tree in the distance.
You can see a madrone tree here.
[looking - succeeded]

>go to white tree
[landmark_navigating the white tree]
You head toward the white tree.
[(1) looking]
Dark Woods
It’s dark and woody. You see the tree stump in the distance.
You can see a white tree here.
[(1) looking - succeeded]
[landmark_navigating the white tree - succeeded]

>go to white tree
[landmark_navigating the white tree]
Well, that’s right here.
[landmark_navigating the white tree - succeeded]

>go to tree
[room_navigating Top of the Tree]
(DEBUG room_navigating: heading toward Top of the Tree is nothing)
You’re no longer sure how to get there.
[room_navigating Top of the Tree - succeeded]

You can see that rather than landmark_navigating, it is prioritizing room_navigating with the ambiguous target “tree”.

And as Peter queried, does the order in the source determine which it privileges: I reversed the position within the source of “Part - Room_Navigating” and “Part - Landmark_Navigating,” and voila! It privileges Landmark_Navigating.

Though frustratingly, “go tree” still privileges “room_navigating Top of the Sentinel Tree” rather than “white tree”.

>go to tree
[Rule “Response Assistant reset responses list rule” applies.]
[Rule “ignore beta-comments rule” applies.]
[Rule “new_blank_line_replacement rule” applies.]
[Rule “declare everything initially unmentioned rule” applies.]
[room_navigating Top of the Sentinel Tree]

OK, here is your grammar table for the synonyms ‘Go’ ‘Run’ ‘Walk’:

Verb 'go' 'walk' 'run' 
	* -> Go 
	*  noun=Noun_Filter1 -> Go 
	* noun -> Enter 
	* SlashGPR1  scope=Scope_Filter1 -> A_room_navigating 
	* SlashGPR2  scope=Scope_Filter2 -> A_room_navigating 
	* SlashGPR3  scope=Scope_Filter3 -> A_landmark_navigating 
	* SlashGPR4  scope=Scope_Filter4 -> A_landmark_navigating 
	* SlashGPR5  scope=Scope_Filter5 -> A_landmark_navigating 
	* 'into' / 'in' / 'inside' / 'through' noun -> Enter 
	* 'back' / '-//' SlashGPR6  scope=Scope_Filter6 -> A_room_navigating;

This illustrates another rule of grammar line precedence, which appears to trump others already discussed- before sorting on token precedence ( and then subsequently on whether or not a condition is attached, such as ‘when the player is in the Lab’) grammar lines are arranged in ascending order of the number of leading prepositions/alternate prepositions/prepositional parsing routines (SlashGPRx) after the verb.

so:

    "walk to/-- [any room]" (1 prepositional parsing routine, matching 'to/--') and
    "run to/-- [any room]" (1 prepositional parsing routine matching 'to/--')

come before

     "go back/- to/around/near/by/-- [any room] (1 alternate preposition matching 'back/-' (note persisting typo so this is an alternative between 'back' and '-' ( '-//' is arcane I6 code for 'the single character '-') rather than a prepositional parsing routine matching 'back/--') and 1 prepositional parsing routine, matching 'to/around/near/by/--' - so total of 2 (possible) leading prepositions

Note how

 'into' / 'in' / 'inside' / 'through' noun -> Enter 

which has just 1 leading alternate preposition also takes precedence despite having a low-precedence token (noun).

Note that this is the reverse of the example given in WI 17.22 for building new tokens rather than a grammar table. When building a new token possible matches are considered in descending order of number of possible prepositions (the example given being that ‘on top of’ (3 prepositions) comes before ‘on/in/inside’ (1 alternate preposition)).

I think the upshot of all this is that trying to manipulate the precedence of grammar lines to achieve specific game effects is complicated, fiddly and poorly documented/understood, so its best not to rely on it- at least in part because the precedence rules the compiler uses may change without warning or notice.

I think the correct approach must be to not have two separate actions here, but to channel all your grammar lines into one action, and then once that action has left the rarified and arcane workings of the parser and emerged as an action, use Before/Instead/Check/Carry Out/After/Report rules, whose workings are transparent and where you have more control, to separate out and channel your action how you want- into other actions if you like, e.g.

Before going an elusive landmark:
	try landmark_navigating the noun instead.

Note that landmark_navigating can be an ‘untypable’ action with no ‘Understand’ phrases of its own, just existing to receive redirections like the one above.

2 Likes

How would that action look? To minimize the effects on other actions (like swimming or jumping) which also use some of the same verbs, I’d prefer it only matched an elusive_landmark or a room, but

Room_or_landmark_navigating is an action applying to one thing.
Understand
	"go back/-- to/near/by/-- [any room or elusive_landmark]",
	"walk back/-- to/near/by/-- [any room or elusive_landmark]",
	"run back/-- to/near/by/-- [any room or elusive_landmark]",
	"return to/near/by/-- [any room or elusive_landmark]",
	"follow [any room or elusive_landmark]" 
	as room_or_landmark_navigating.

is not legal syntax.

well, it’d look like my example above where I took the same tack that Dr. Bates advised, right down to noting that it could be one action or two.

1 Like

As I understand your essential question, it’s how to get “tree” interpreted by default as the white tree during this scene, but in general to have a room such as Top of the Sentinel Tree preferred.

If that’s the case, then having separate landmark_navigating and room_navigating actions is inherently part of the problem. No matter how you arrange things, the grammar line for one of the actions will come before that of the other. (The same, unfortunately, applies to different specialized grammar lines for a single action.)

Your original approach to use DTPM rules can work only if the parser is trying to decide which object is the noun of a single action, and the rules are checked only while the player’s command is being evaluated to see whether it can be interpreted as validly requesting that action. It is important to understand that DTPM can only differentiate between objects that are in scope because they match to a word or words used in the player’s command. It can’t add things to scope, it can only give a preference (or dispreference) for things already decided to be in scope. [EDIT: Reading back over this, I see that I neglected to clarify an important point here: What is being evaluated when the DTPM rules are checked is a single grammar line. Thus, all of the objects to be weighted with respect to each other by DTPM rules must have been brought into scope at the same time.]

Although you can have one action decide to invoke another, this is not strictly necessary. The same action can execute different logic based on the nature of the noun and/or second noun. All you need to do is structure the rule preambles appropriately for check, carry out and other rules.

The following reworks things a bit in light of the above. Note that I reinserted some DTPM rules that depend on the state of the discouraged_from_compass_navigating property for the player. The conditional logic can be modified as you like to make use of scenes or whatever. The test me sequence shows how the command >GO TO TREE is interpreted based on the current situation.

Lost in the Woods
"Lost in the Woods"

Part - Room_Navigating

A person can be discouraged_from_compass_navigating or not discouraged_from_compass_navigating.

Navigating is an action applying to one object.

Definition: an object is navigable if (it is a room and it is not the location) or (it is an elusive_landmark and it is not in the location).

Understand
	"go back/- to/around/near/by/-- [any navigable object]",
	"go to/near/by/-- [any navigable object]",
	"return to [any navigable object]",
	"walk to/near/by/-- [any navigable object]",
	"walk to/-- [any navigable object]",
	"run to/near/by/-- [any navigable object]",
	"run to/-- [any navigable object]",
	"follow [any navigable object]"
	as navigating.

Does the player mean navigating a room when the player is discouraged_from_compass_navigating:
	it is unlikely.

Does the player mean navigating a distant elusive_landmark when the player is discouraged_from_compass_navigating:
	it is likely.


After waving hands:
	if the player is discouraged_from_compass_navigating:
		now the player is not discouraged_from_compass_navigating;
	otherwise:
		now the player is discouraged_from_compass_navigating;
	showme whether or not the player is discouraged_from_compass_navigating.

Check navigating a room:
	if the noun is the location, say "Well, happily you're already here." instead;

Carry out navigating a room:
	let initial location be the location;
	let the destination be the noun;
	if the initial location is the destination,
		say "." instead;
	let heading be the best route from the initial location to the destination;
	say "(DEBUG room_navigating: heading toward [noun] is [heading])[line break]";
	if heading is nothing:
		say cant_find_that instead;
	else:
		now player is not discouraged_from_compass_navigating;
		try going heading.

Part - Elusive_Landmarks and Landmark_navigating

An elusive_landmark is a kind of thing.

The_distance is a container.
The_distance is in Limbo.
Definition: an elusive_landmark is distant if it is in the_distance.

Check navigating an elusive_landmark:
	if the noun is touchable:
		say "Well, that's right here." instead;
	if the noun is not in the_distance:
		say cant_find_that instead;

To say cant_find_that:
	say "You're no longer sure how to get there.";

Carry out navigating an elusive_landmark:
	say "You head toward the [noun].";
	move_within_dark_woods;
	try looking.

To move_within_dark_woods:
	let distant_thing be a random elusive_landmark in the_distance;
	let next_thing be a random elusive_landmark in Limbo;
	let past_thing be a random elusive_landmark in location;
	now distant_thing is in location;
	now next_thing is in the_distance;
	now past_thing is in Limbo;

The can't reach inside rooms rule does nothing when navigating.

The can't reach inside rooms rule response (A) is "You can't get there from here."

Part - Rooms & Stuff

Dark Woods is a room.
"[dark_woods_desc].".

To say dark_woods_desc:
	let distant_thing be a random elusive_landmark in the_distance;
	say "It's dark and woody. You see [the distant_thing] in the distance";

The white tree is an elusive_landmark in The_distance.
Understand "tree" as white tree.

The madrone tree is an elusive_landmark in Dark Woods.
The tree stump is an elusive_landmark in Limbo.

Top of the Tree is a room [west of Dark Woods].
Understand "tree" as Top of the Tree.

Test me with "go to tree / wave / go to tree / g".
4 Likes
Room_or_landmark_navigating is an action applying to one thing.
Understand
	"go back/-- to/near/by/-- [any room],
	"go back/-- to/near/by/-- [any elusive_landmark],
	etc.
	etc.
	as room_or_landmark_navigating.

You could have all of these go through the Going action without having a new Room_or_landmark_navigating action and then just start processing at the Before stage (as in the example I gave)

1 Like

True, but you can make grammar lines conditional so that they swap in and out of parser consideration, e.g. ‘Understand “blow up [something]” as detonating when the player is in the mine. Understand “blow up [something]” as inflating when the player is in the balloon factory.’

Although as already stated, I think the whole approach of manipulating grammar line precedence/consideration like this is probably flawed and best avoided.

Otis’ "[any navigable object]" above is a clever way to express allowed things in one grammar token, and it obviates the need for putting things in scope manually as in my example.

I think the easiest way to handle this would be to do something like this. (Sorry, I don’t have time right now to put a properly functional version together, or indeed to test whether or not this is nonsense.)

Understand [COMMANDS] as landmark_navigating when [SCENE] is happening.
Understand [COMMANDS] as room_navigating.
Understand [COMMANDS] as landmark_navigating.

I think that should lead to the grammar lines for landmark_navigating taking priority during SCENE, but not at other times.

Sadly not, unless all the [COMMANDS] are identical for room_navigating and landmark_navigating, since the presence of a condition has the lowest priority of all apart from source text order when the compiler is ordering grammar lines.

There are hacky ways of forcing priority on the compiler, but as suggested earlier in this thread, IMHO this whole approach really isn’t a good way to try to implement game mechanics.

The compiler orders things the way it does to optimise sensible parser responses to a wide range of input, which is probably at odds with interfering to drive game mechanics.

As is generally the case with Inform, if you’re fighting the system you’re probably missing a better way of achieving your goal.

I’m experimenting with combining room_navigating and landmark_navigating. Then since this added more and longer grammar lines, climbing_something took precedence and had to be combined as well. So the strategy of one navigation action to rule them all ends up having tons of grammar lines and tons of conditions (though Otis’ Carry out navigating a room could help).

Navigating is an action applying to one thing.
Understand
	"go back/-- to/near/by/-- [any reachable room]",
	"go back/-- to/near/by/-- [any elusive_landmark]",
	"walk back/-- to/near/by/-- [any reachable room]",
	"walk back/-- to/near/by/-- [any elusive_landmark]",
	"run back/-- to/near/by/-- [any reachable room]",
	"run back/-- to/near/by/-- [any elusive_landmark]",
	"return to/near/by/-- [any reachable room]",
	"return to/near/by/-- [any elusive_landmark]",
	"follow [any reachable room]",
	"follow [any elusive_landmark]",
	"climb on/onto/in/into/over/through/under/-- [visible thing]", 
	"climb up in/into/on/onto/-- [visible thing]",
	"hop on/onto/in/into/over/through/under/-- [visible thing]", 
	"hop up in/into/on/onto/-- [visible thing]",
	"scale on/onto/in/into/over/through/under/--  [visible thing]", 
	"scale up in/into/on/onto/-- [visible thing]",
	"jump on/onto/in/into/over/through/under/-- [visible thing]", 
	"jump up in/into/on/onto/-- [visible thing]",
	"cross up/on/onto/in/into/over/through/under/-- [visible thing]",
	"go up/on/onto/in/into/over/through/under/to/-- [visible thing]"
	as navigating.

This approach violates my sense of programming elegance, and it might be hard to manage. This is a possibility, but is it a good idea? Is it the most elegant, modular, extensible approach? Originally I wanted to find a solution to my small problem without digging in deeply to these already working solutions, but now that I have, I’m willing to consider what a good approach would be.

I’ve just clocked that there is an inbuilt debugging verb for looking at grammar lines (of course there is!)

showverb go

does the trick!

1 Like

I’m not sure what you’re gaining by combining actions together that don’t share verbs (and therefore can’t be ambiguous to the parser)?

As a separate issue, it’s probably not good style to introduce constraints to your grammar tokens (such as [visible thing] instead of [thing]) unless there really is no other way of achieving what you want.

General rule of thumb is to keep things as broad as possible at parser level so that any vaguely sensible player input is accepted by the parser, then sort out details in action-processing where you have complete and transparent control of logic and responses.

The parser not matching [visible thing] gets you the default blank ‘You can’t see any such thing’ response, whereas ‘Before navigating something invisible:’ allows you to take full control.

As a further aside, the differences between [thing] (a thing in scope for the actor) and [visible thing] (a thing visible to the player) are subtle, unless the actor is not the player… (see here)

EDIT PS The differences between [visible thing] as a grammar token (as in 'Understand “destroy [visible thing]” as destroying) and ‘visible thing’ in an action definition (as in ‘Destroying is an action applying to one visible thing’) are not so subtle. The former means ‘a thing the player can see’ (thing here having the sense of ‘an instance of the thing kind, or of one of its sub-kinds, e.g. people or women or doors or containers)’, the latter means ‘any object in the universe, including rooms, regions, directions and objects out-of-play, and (confusingly) whether the player or anyone else can see them or not’.

Christ, that would have been good to know. I recently discovered scope. Where are these documented?

To develop this idea further, I note that there are at least three or four possible solutions offered in this thread. Which is “best?” I am always interested in learning best practices. With I7, it sometimes feels like all the solutions are a bit hacky.

When I was learning Python, it was helpful that there was consensus on what practices are considered “pythonic,” that is, “ code that doesn’t just get the syntax right but uses the language in the way it is intended to be used. It improves the overall code quality from maintainability, readability and efficiency perspective.”

Is there a consensus on what could be termed “informic?”

Mostly in WI Ch. 24 sections 3-4. They’re all listed in the General Index under testing commands… except for glklist which is undocumented on purpose.

Hehe… probably not at the level of the problems you’ve shared in this topic. We probably all agree about stuff like when to not use an instead rule, etc. But at this topic’s level, you’re creating new logic specific to your game. We can subject the results of our attempts to create it the idea of being Informic, but less so the nature of the attempts themselves.

Looking at the suggestions to funnel everything through one grammar line (and maybe one action) – and remembering I suggested two of each – I thought about my WIP where I’m using two of each and tried to decide why I’m doing it the way I’m doing it (if I even know). And I also tried to work out, ‘Why haven’t I run into the problem Wes is having (yet)?’

Probably the reason I have two is evolutionary. I started with Emily Short’s Approaches extension, which works only for rooms. I then had to expand the mechanism to take in all Things in the game. So I added a new grammar and a new action. The new action responds to attempts to go to things, and ultimately if an attempt succeeds, it executes it via the approaching (going to a room) action. The room containing that thing.

Rooms are pretty bedrocky. They stay where they are, are usually referred to the same way, and don’t come and go. Things are moving all over the place and coming and going. Also, I mentally think of the approaching code (an action and a lot of activity rules) as a big self-contained unit. It’s easier for me to put in there only code dealing with finding the path to a room.

If the player tries to go to a thing, there are a mountain of extra checks involved. So many it’s mentally easier for me for that code to be one whole other self-contained unit. The action has to get through that to pass on to the approaching unit. So the separation may not be essential, code-wise, but it helps me think about the problem(s).

Why have I not run into annoying problems of grammatical overlap? It could be luck. The actions aren’t defined similarly. One is for visited rooms, one is for known things (known being a term from the Epistemology extension - meaning you’ve seen it or heard about it). It’s probably partly by design, too. I’m very careful in naming rooms and things.

My WIP also has a low cheat capacity. What I mean by that is – thanks to me including a command that lists everything you can interact with at any particular moment, I mostly can’t cheat things using prose alone. Things have to be in the world model where the player expects them to be for the LIST command to work right. All of my GO TO is based on rooms and things that are all really in the map someplace. i.e. I can’t use an abstract stand-in thing like your distant elusive_landmark, because its real position is in a container in a hidden room.

All I can say, my system is working really well, but it’s for a game that’s probably a lot more complex than yours. I could probably have done it all through one action, but the way it’s evolved into two actions that funnel to one of the actions is working for me. When I look over this topic now, I think a one-grammar-line solution will probably be best for you.

-Wade

1 Like

Not really. Other things being equal, approaches that result in code that reads well as natural language is considered more Informic than those that don’t. Approaches centering rulebooks and relations would be considered more Informic than using lots of to-phrases.

The docs will try to tell you that relying on I6 inclusions is un-Informic, but if one takes Informic to mean what experienced users of Inform do an extraordinarily large amount of, then there’s nothing more Informic.

4 Likes

The documentation gives numerous hints, caveats, warnings and admonitions about how to ‘best’ use the language- ranging in strength from ‘you might consider this good style’ to ‘you don’t really want to do this. No, really, you really, really don’t want to do this. Oh alright, if you must- but don’t say you weren’t warned, and don’t come crying to me when I change things so this doesn’t work any more.’

It must be acknowledged, as Mr Nelson does, that no experienced coder can receive a gift without immediately wondering how they can subvert its original purpose and bend it to their will. It’s often said that to a man with a new hammer, every problem looks like a nail: but experienced coders seem to immediately wonder what else they could hit with it- maybe it could be just the answer to that clanking heating pipe in the loft if it’s hit in just the right way…?

I know I am particularly susceptible to hammering away at the language to get it to do things my way, enjoying that as a satisfying challenge in itself- rather than saving a lot of time and trouble by changing my approach to fit more snugly with what Inform makes it easy to do. When two roads diverge in a yellow wood, I always want to take the one less traveled by… As Zed has suggested, this approach frequently leads one into I6 inclusions, which can be a lot fun in itself but not necessarily conducive to getting quickly on with the job of producing a work of IF.

I think probably the most universally accepted advice on this forum is don’t mess with the parser- it’s bigger, tougher and smarter than you. That extends even to thinking very long and hard before resorting to ‘after reading a command’ to directly examine and/or interfere with player commands, or even sidestep the parser entirely. Elegantly covering your bases with anything a player might reasonably type is a minefield, particularly when considering the possibility of chained commands (a sequence of commands typed in one go, separated by full stops, commas or ‘then’).

I think other good general advice is to avoid falling into the habit of side-stepping the full action processing sequence, with all its checks and balances (particularly for inbuilt actions) by making everything an Instead rule. Instead (ha ha) consider whether what you’re doing would fit naturally into one of the other action rule-books before reaching for Instead…

Most of all, I’d reiterate the advice I gave earlier in this thread- if what you’re trying to do seems to be cutting across Inform’s grain, you may well be missing something and it’s worth going back to analysing the fundamentals of the story effect you’re looking for (particularly the visible effect, not the elegance and accuracy of any underlying simulated world) and brainstorming new approaches, and/or sifting through the documentation or extensions for an established solution. I’m still rediscovering new things daily in the documentation that I’d forgotten entirely, or perhaps skipped over in previous readings.

4 Likes

This is a lot, but I wanted to close the loop on this. Here’s a summary of some choices I made and why:

  • I combined many similar navigation or movement actions into one navigation action - this helped prevent similar grammar lines from uncontrollably competing with each other
  • It was suggested not to use any in grammar lines - however, I wanted the action to catch these possibilities to give an error in the check rule that made sense for the kind of thing and action
  • It was suggested not to use qualifiers in grammar lines so you wouldn’t get the dreaded “The noun does not make sense in this context” - I took this to heart, but also used some definitions (described below) that helped
  • I used definitions to keep grammar lines from being triggered when I didn’t want them to, i.e., [any relevant elusive_landmark]
  • I was careful to put grammar lines I wanted to be preferentially triggered before others (if the number of grammar options is the same, the parser is first come, first served)

So here is the final code that takes the advice in this thread, plus the choices above:

Chapter - Navigation to Rooms and Landmarks

Part - Lost_stuff, Elusive_Landmarks, & Landscape_Features

lost_stuff_storage is a container.
The printed name is "Lost Stuff Storage".
lost_stuff_storage is in Limbo.

An elusive_landmark is a kind of thing.
An elusive_landmark is mentioned scenery.
An elusive_landmark can be distant.

landmark_nav_counter is a number that varies. landmark_nav_counter is 0.

[ Create richer generative Dark Woods locations with rises and downslopes, incidental details, etc. ]
A landscape_feature is a kind of thing.
An landscape_feature is scenery.

Does the player mean examining distant elusive_landmark:
	It is unlikely.

Does the player mean examining not distant elusive_landmark:
	It is likely.

When play begins:
	Let this_landmark be a random elusive_landmark in Limbo;
	Now this_landmark is in Room_Dark_Woods_South;
	Let next_landmark be a random elusive_landmark in Limbo;
	Now next_landmark is distant;
	Now next_landmark is in Room_Dark_Woods_South;
	[ landscape_features ]
	Let this_feature be a random landscape_feature in Limbo;
	Now this_feature is in Room_Dark_Woods_South;

Part - Reachability & Interactivity

[Basically, if the player and the room are in Region_Dreams OR the player and the room are both not in Region_Dreams, than the room is reachable.]
Definition: A room is reachable
	if it is reachable_in_dreams or
		it is reachable_IRL.

[Everywhere within Region_Dreams is contiguous -- and discontiguous with everything outside of it.]
Definition: A room is reachable_in_dreams
	if the map region of it is Region_Dreams and
		the map region of the location is Region_Dreams.

[Everywhere NOT within Region_Dreams is contiguous -- and discontiguous with everything inside of it.]
Definition: A room is reachable_IRL
	if the map region of it is not Region_Dreams and
		the map region of the location is not Region_Dreams.

Definition: A thing is interactive
	if it is climbable or it is a supporter or it is an enterable container.

Definition: An elusive_landmark is relevant
	if Scene_Lost is happening.

Part - Navigating

[ navigating means moving from one room to another, moving to an elusive_landmark, or on/in to a supporter or container ]

Navigating is an action applying to one thing.
Understand
	[ rooms and landmarks ]	
	"go to/near/by/-- [any relevant elusive_landmark]",
	"go to/near/by/-- [any room]",
	"walk to/near/by/-- [any relevant elusive_landmark]",
	"walk to/near/by/-- [any room]",
	"run to/near/by/-- [any relevant elusive_landmark]",
	"run to/near/by/-- [any room]",
	"return to/near/by/-- [any relevant elusive_landmark]",
	"return to/near/by/-- [any room]",
	"follow [any relevant elusive_landmark]",
	"follow [any room]",
	[ interactive things ]
	"climb on/onto/in/into/over/through/under/-- [interactive thing]", 
	"climb up in/into/on/onto/-- [interactive thing]",
	"hop on/onto/in/into/over/through/under/-- [interactive thing]", 
	"hop up in/into/on/onto/-- [interactive thing]",
	"scale on/onto/in/into/over/through/under/--  [interactive thing]", 
	"scale up in/into/on/onto/-- [interactive thing]",
	"jump on/onto/in/into/over/through/under/-- [interactive thing]", 
	"jump up in/into/on/onto/-- [interactive thing]",
	"cross up/on/onto/in/into/over/through/under/-- [interactive thing]",
	"go up/on/onto/in/into/over/through/under/to/-- [interactive thing]"
	as navigating.

[ landmark navigating ]

Check navigating elusive_landmark:
	[ say "(DEBUG: check nav elusive_landmark: [noun])"; ]
	if noun is not visible:
		say "(DEBUG: [noun] not visible?)";
		say cant_find_that instead;
	else if noun is not distant:
		say "Well, that's right here." instead;

Carry out navigating elusive_landmark:
	[ say "(DEBUG: carry out nav elusive_landmark: [noun])"; ]
	increment landmark_nav_counter;
	move_within_dark_woods;

[ room navigating ]

Check navigating room:
	[ say "(DEBUG: Check navigating room: [noun])"; ]
	if the noun is the location:
		say "Well, happily you're already here." instead;
	else if the noun is not reachable:
		say cant_find_that;

Carry out navigating room:
	[ say "(DEBUG: Carry out navigating room: [noun])"; ]
	if noun is not reachable:
		say cant_find_that;
	else:
		let initial location be the location;
		let the destination be the noun;
		if the initial location is the destination,
			say "." instead;
		let heading be the best route from the initial location to the destination;
		[ say "(DEBUG navigating: heading toward [noun] is [heading])[line break]"; ]
		if heading is nothing:
			say cant_find_that instead;
		else:
			now player is not discouraged_from_compass_navigating;
			try going heading;

[ navigating to climbable things, supporters, containers, & waterbodies]

Check navigating interactive thing:
	[ say "(DEBUG: check navigating interactive thing: [noun])"; ]
	if noun is not touchable:
		say cant_find_that;

Carry out navigating interactive thing:
	[ say "(DEBUG: carry out navigating interactive thing: [noun])"; ]
	if the noun is climbable:
		[ say "You climb [the noun]."; ]
		try climbing the noun;
	else if the noun is an enterable container:
		[ say "You climb into [the noun]."; ]
		try entering the noun;
	else if the noun is a supporter:
		[ say "You climb onto [the noun]."; ]
		try entering the noun;
	else if the noun is a waterbody:
		try doing_some_swimming;
	else:
		say fail_navigation;

[ some things we say about navigation ]

To say cant_find_that:
	say "You're no longer sure how to get there. [looking_for_available_exits]";

To say fail_navigation:
	say "You can't really figure out how to go about that.";


Part - Moving Within Room_Dark_Woods

To say movement_in_woods:
	say "[one of]You stumble around in the dark woods[or]You carefully make your way through the forest[or]You follow an uncertain path through the wood[or]You bushwhack your way through the underbrush[at random].".

To move_within_dark_woods:
	say movement_in_woods;
	[ elusive_landmarks ]
	Let near_landmark be a random not distant elusive_landmark in Room_Dark_Woods_South;
	Let distant_landmark be a random distant elusive_landmark in Room_Dark_Woods_South;
	Let next_landmark be a random elusive_landmark in Limbo;
	Now near_landmark is off-stage;
	Now distant_landmark is not distant;
	Now next_landmark is in Room_Dark_Woods_South;
	Now next_landmark is distant;
	[ landscape_features ]
	Let old_feature be a random landscape_feature in Room_Dark_Woods_South;
	Let new_feature be a random landscape_feature in Limbo;
	Now old_feature is off-stage;
	Now new_feature is in Room_Dark_Woods_South;
	[ deal with dropped stuff ]
	Repeat with item running through stuff_you_brought_here:
		if item is visible and item is not held:
			move item to lost_stuff_storage;
	try looking;

The can't reach inside rooms rule does nothing if navigating a room.
2 Likes