Modelling variable reachability

Authoring Inform 7
1

I’m struggling to figure out how to model a concept of reachability where the player’s reach varies according to the situation.

My initial thought was to use a rulebook, which I set up like this:

Check reachability is an object based rulebook. The check reachability rules have outcomes in reach (success) and out of reach (failure).

An action-processing rule (this is the checking reach rule):
	if the current action is going up and the door gone through is a door:
		follow the check reachability rules for the door gone through;
		if the rule failed:
			if the actor is the player:
				say "[if the actor is the player][We][else][The actor][end if] [can't reach] the opening." instead;
	unless the action requires a touchable noun, make no decision;
	follow the check reachability rules for the noun;
	if the rule failed:
		say "[if the actor is the player][We][else][The actor][end if] [can't reach] [regarding the noun][those]." instead;

The checking reach rule is listed before the basic accessibility rule in the action-processing rules.

So then I can have rules like these:

  • Check reachability rule while the player is wearing the extensible claw: in reach.
  • Check reachability rule while the player is on a booster and the posture of the player is standing: in reach.
  • Check reachability rule while the player is hoisted by someone: in reach.
  • Check reachability rule while the flight level of the player is greater than 0: in reach.
  • Last check reachability room for something out-of-reach: out of reach.

There are a bunch of custom concepts in those examples – a “booster” is just a special type of enterable supporter, “posture” is from Emily Short’s extension, and “hoisting” is an action+relation that allows you to ask another person to “hoist” you up onto their shoulders. I could post the details, but I don’t think it’s ultimately relevant to the core question.

Anyway, that approach works… but then I had the thought that those conditions should stack. For example, there could be a puzzle where you have to put one booster on top of another to reach a particularly distant thing, or a puzzle where you have to ask someone to climb onto a booster and then hoist you, or a puzzle where you need to be on a booster and wearing the extensible claw.

(Although, the “flight level” property mostly trumps everything else – if you can fly, all the other rules are irrelevant. But on the other hand, perhaps if you’re flying you can’t reach things that are lower than your current height…)

Some things I’ve tried that don’t seem to quite satisfy me (though I didn’t follow them far enough to be minimally functional):

  • I thought of defining a phrase to decide what number is the access level of (P - a person) which would then be compared to a locale height property on the thing being accessed. I think this would work, but it feels like it renders the use of a rulebook mostly redundant - nearly every case would be handled by a single rule that compares the access height of the player to the locale height of the object.
  • I thought of making the rulebook produce a number, also in conjunction with a locale height property, but that doesn’t seem to satisfy the requirements either.

I may ultimately decide to scrap this and return to the previous rulebook-based method where the various conditions don’t stack, but I’d like to at least explore as many options as possible first… so does anyone have any other ideas to achieve this?

As an aside: it’s not really that important, but it might be nice if the system also works for actors other than the player. I don’t really plan to have other actors taking unreachable things though, and so far I don’t mind them leaping through unreachable trapdoors in the ceiling.

2

Just a brief philosophical design thought:

The basic concept of a room is something like ‘a discrete space within which everything is by default visible and within reach’

If an actor needs to access/see things not in the current room, they usually must move to the room that those things are in, traditionally by going via doors or compass directions (including up/down).

The concept of reach is implemented in the Standard Rules to allow enhancements or restrictions to those basic concepts for exceptional situations, such as the actor being locked in a cage- but even in that scenario it bears consideration whether the cage is better implemented as a separate room- depending on what the actor is expected to be able to do/observe/interact with from within the cage.

The existing implementation allows you, for example, to allow an actor to see into adjacent (or even distant) rooms or to physically interact with objects within them.

Is there something particular about the scenario you have in mind that justifies building a whole new metaphysical structure to support it, rather than writing a handful of ‘exception rules’ within the existing framework? Or is this more of an intellectual simulationist exercise?

3

It might be a bit of the latter, I suppose. I haven’t entirely decided whether it’s worth expanding the concept to allow conditions to stack; it just seems like it would increase the options available to me in constructing puzzles.

I already have 6 puzzles that require you to get at something that’s out-of-reach by one of the available means, so dropping the concept altogether really isn’t an option. Those puzzles worked just fine with the earlier system, mind you – they didn’t rely on conditions stacking. That said, the most recent one only works if you’re flying, as it’s higher up than a booster or hoister can get you; if conditions stacked, using both a booster and a hoister would probably work as an alternate solution.

From what you said in the rest of your post, you seem to be suggesting simulating it by making every possible “level” you can be at in a “room” be implemented as an entirely separate room.

I’m not sure if I like that idea, as it would dramatically explode my room count[1] and inflate the index map, but it does sound like a possibility worth considering.

It’s a really dramatic break from the current approach and would require reworking a lot of things, but that’s probably not a problem in and of itself. I’ll give that idea some thought, at least.

  1. I currently have 88 rooms and still counting (no idea if that’s considered to be a lot though). Since outdoor locations mostly have 6 possible heights (including walking on the ground), and indoor locations typically have 2 or 3, this approach would surely at least quadruple the room count. ↩︎

4

The traditional way to implement ‘out of reach’ things in systems with very simplistic world-modelling is just to write exception code for them, along the lines of:

Instead of taking the vase when the player does not carry the long-handled pincers for the first time: say “You need some means of reaching up there!” instead.

The question for such puzzles is always whether it’s necessary to implement a complex simulationist model for them or just code something ‘simple but good enough’ for the circumstances’ and move swiftly on.

5

This is a good question, though I think the rulebook-based system I already had can qualify as “simple but good enough” – given that I have several out-of-reach things and will likely have several more, I think it’s easier to just write “The shelf is out-of-reach” and let those four or five rules take care of it than writing 12 exceptional cases.

I’d still like to explore possibilities for the more complex model where the conditions that extend your reach can stack, however.

6

In general, I would prefer an approach that involves a single rule over one that requires an entire rulebook, everything else being equal. The first principle of design is “simpler is better”.

7

That might be true if there are only one or two out-of-reach items, but it surely breaks down if you have thirty or forty of them. (I don’t have that many at the moment, admittedly, but still.) If you have more than about ten items, my simple “check reachability” rulebook is fewer rules than if you had one rule for each out-of-reach item.

But I suppose you may be trying to make the point that I could delete the “check reachability” rulebook and funnel all the logic into the custom action-processing rule, using the phrase I described. That’s definitely an option too…