Abide / follow / continue problem

I’m modularising my game into chapters so I can compile it with just one chapter active at a time. This mostly means the main source cannot refer to specific things in chapters. Each chapter has its own extension. In some cases, these extensions drop chapter-specific rules into rulebooks when they’re included.

I’m having trouble with this drop-in system and a particular programming approach. I’ve reduced it to a coding example here.

Summary: I have these backdrops, which here we’ll call feature-props.

The idea is, 90% of actions tried on a feature-prop fall through to a fob line of ‘That doesn’t make sense’ via an ‘Instead of doing anything but examining to a feature-prop:’ rule. But first some actions are checked and allowed to continue, others are redirected, and others get a custom fob message.

The process is:

  • Action tried on a feature-prop enters instead rule.
  • A series of rules dropped in by specific chapters are run (abided by). They could stop things, redirect, or allow the action to continue Right Away.
  • If the action wasn’t dealt with somehow, it reaches the bottom and says ‘That doesn’t make sense.’

I need to abide by the chapter-specific rules if I want their ‘instead’ clauses to stop things. But I can’t work out how to make an allowed action continue Right Away. Using ‘continue the action’ simply keeps all the rules flowing, whether I use abide or follow. It doesn’t exit and run the action.

This system worked when I had one mega-rule to do the whole thing, because then ‘continue the action’ exited the main rule and did indeed continue the action. But now I need it modularised and can’t work out the best way to do it.

In the example code, if you type LOOK UNDER CARRIER, the desired behaviour is that that action is allowed as per the chapter 1 rule and says ‘You find nothing of interest’. What actually happens is ‘continue the action’ does nothing, all the rules run, and then the fallthrough is reached and printed: “That doesn’t make sense.”

Summary
A feature-prop is a kind of backdrop.

current chapter is initially 1.

underwater is a room.[chapter 1]
a carrier is a feature-prop in underwater.

atrium is a room.[chapter 2]
a marble pool is a feature-prop in atrium.
pool water is a feature-prop in atrium.

Instead of doing anything other than examining to a feature-prop:
	abide by the chapter-specific feature-prop rules;
	say "That doesn't make sense.";[fallthrough line]

The chapter-specific feature-prop rules is a rulebook.

A chapter-specific feature-prop rule (this is the chapter 1 rule):
	if current chapter is 1:
		if noun is the carrier:
			if searching:
				instead try looking under carrier;
			if looking under:
				continue the action;
			if eating:
				instead say "Don't be ridiculous.";

A chapter-specific feature-prop rule (this is the chapter 2 rule):
	if current chapter is 2:
		if noun is pool water:
			if looking under:
				instead try searching marble pool;
			if drinking or entering or searching or tasting or touching:[a general redirect]
				now the noun is marble pool;
				continue the action;

The example’s more illustrative than practical. You’d have to change the start location, and the current chapter value to 2, to try the second rule, but there’s no need to. You can see what’s going on with the chapter 1 rule.

-Wade

Wade,
In the chapter-specific feature-prop rule, continue the action is returning to the instead rule, which says to print “That doesn’t make sense.”

Instead rules impose a “rule fails” or “stop the action” status, so unless your chapter-specific rule handles the action (like it does eating), continuing the action will return to the instead rule. It won’t ever continue to the standard rules.

If you change the rule to a before rule, your chapter-specific rule can “continue the action” and have the standard rules handle the action. However, in this case, your failthrough line will always print. You’d have to use an after rule that can check if the chapter-specific rule did something, and display the failthrough line if it didn’t.

1 Like

You could try:

To decide whether no result occurred:
	if rule succeeded, no;
	if rule failed, no;
	yes.

Instead of doing anything other than examining to a feature-prop:
	abide by the chapter-specific feature-prop rules;
	if no result occurred, make no decision; [ADDED]
	say "That doesn't make sense.";[fallthrough line]
1 Like

Thanks you two.

I’ve worked out a bit of a hybrid approach. otis’s method was looking good (testing the result of the rule) but didn’t quite work because 'continue the action’s (I want the action to go ahead now and ditch the master instead rule) and rules that just didn’t catch anything (I want the master instead rule to keep exploring options) gave the same outcome and ended up in the same place, though I need them to do different things.

To distinguish one situation from the other, I created a true/false flag and a phrase called ‘make the action proceed’ that sets it and does a continue the action. So now, when abiding by the chapter-specific rules:

  • insteads do their thing and stop the master rule
  • ‘make the action proceed’ will return to the master rule then trigger another continue the action there, which does indeed continue the action the player tried
  • if nothing happens in any chapter-specific rule, the master instead rule keeps on checking its own clauses

-Wade

I think I see what you’re trying to do, though it looks to me like you might be trying to recreate your own versions of several pre-existing features.

The non-standard phrase:

To decide whether there was no named outcome:
	(- (~~ResultOfRule()) -).

can be useful in this scenario. I was trying to give you something with no I6 inclusions, but I think this small one might be worth it. Using that, you can write your chapter-specific rules in more or less the style that you laid out in your first post, without requiring extra lines:

Instead of doing anything other than examining to a feature-prop:
	follow the chapter-specific feature-prop rules;
	if the outcome of the rulebook is the proceed outcome, continue the action;
	if the outcome of the rulebook is the halt outcome or there was no named outcome, stop the action;
	say "That doesn't make sense.";[fallthrough line]

The chapter-specific feature-prop rules is a rulebook.
The chapter-specific feature-prop rules have outcomes unhandled (failure - default), halt (failure) and proceed (success).

A chapter-specific feature-prop rule (this is the chapter 1 rule):
	if current chapter is 1:
		if noun is the carrier:
			if searching:
				instead try looking under carrier; [generates no outcome]
			if looking under:
				proceed;
			if eating:
				instead say "Don't be ridiculous."; [generates no outcome]

which yields what I think you want:

underwater

>look under carrier
You find nothing of interest.

>search carrier
You find nothing of interest.

>eat carrier
Don't be ridiculous.

>smell carrier
That doesn't make sense.

EDIT: Minor changes to the preceding are needed to keep the rule-writing style used in the original example; see below.

1 Like

Thanks much. Yes, you’ve grokked my purpose. I’m now trying to grok the logic of your mechanism: Is it that the instead clauses (like Don’t be ridiculous) end the rulebook immediately with no outcome, whereas an action that makes it through the rulebook without triggering any clause on the way produces the default outcome of failure?

-Wade

Wade,
That is the basic idea.

When a player tries to eat the carrier, the chapter-specific rules tell the game to say “Don’t be ridiculous.” instead of anything else.

In the case of searching, the instead rule halts the rulebook, but it also starts a new action to “look under” the carrier, triggering the “instead of doing anything…” rule. That triggers the chapter-specific rulebook again, which proceeds to the standard rules.

If the player tries any action that isn’t handled by the chapter-specific rulebook, the result is the failthrough line.

1 Like

Yes to the first part but no to the second. (I think.)

Unfortunately, I forgot that the default outcome of a rulebook is also the default outcome of any rule in it, so the version above isn’t quite right for your purposes, because the rulebook will always halt after the first rule that “applies,” and given the way that you’re writing them the first rule that applies will always be the first rule in the rulebook.

It’s not too difficult to fix, though, just these changes:

The chapter-specific feature-prop rules have outcomes unhandled (failure), halt (failure) and proceed (success).

A last chapter-specific feature-prop rule:
	unhandled.

The first paragraph makes it so that no outcome is the default. The second provides a rule to cause the rulebook to end in unhandled if no other rule halts rulebook processing first.

1 Like

Ah yeah, good catch. Okay I updated the process and tested it with a chapter-2-specific rule to make sure it was reaching later rules, and now I’m all set. Thanks.

-Wade