Results following a type of action

I’m attempting to write my first game in Inform 7, and I want something to happen to the player after attempting a type of action two or three times. I’m sure this is an issue of me not quite understanding action rules, but I haven’t found exactly what I need in the documentation.

Any guidance would be appreciated!

Here’s a simplified version of my code:

The Cell is a room. "Your standard escape room. There's a bare mattress on the floor." The player is in the Cell.

A mattress is scenery in the cell. The mattress is a supporter.

Mattresspushing is an action applying to nothing. Understand "push mattress" as mattresspushing. [This is obviously a clunky workaround. I don't want the mattress to be pushable between rooms.]

Carry out mattresspushing:
	say "You bend over and push the mattress around the limited floor space.".

Instead of looking under the mattress:
	say "You grab the edge of the mattress with both hands and lift it up. You find nothing but bare concrete underneath.".

A pole is in the cell.

Looking under the mattress is straining. Mattresspushing is straining. Taking the pole is straining.

After trying straining for the second time:	
	say "You feel a bit of strain in your left wrist.".

After trying straining for the third time:
	say "The muscle strain sharpens into pain. You drop everything and massage your wrist.";
	now everything carried by the player is in the cell.

One obvious issue is that the “instead” rule for looking under the mattress isn’t triggering the “straining” rule. I’m not sure how to avoid the “You find nothing of interest” automatic response without using “instead.”

But that’s not my only problem. I’d ideally like whatever action to be fully carried out before printing the player reactions. E.g., if the player picks up the pole as the third “straining” action, I’d like the game to print “Taken.” and only then go into “The muscle strain sharpens …” That order works with “mattresspushing” but not taking the pole.

Any suggestions?

The way I handle this kind of thing is with something like:

A person has a number called straining. The straining of the player is 0.

After reading a command when the straining of the player is 3:
	say "The muscle strain sharpens into pain. You drop everything and massage your wrist.";
	now everything carried by the player is in the cell;
        reject the player's command.

Then you can increase the straining of the player either the first time they try each action, if you want them to do each once, or every time they perform the action, if you don’t care if they do once each or the same one three times.

Hm, that seems like it could be a good solution, but I’m running into problems with it. I want each strain/pain reaction to just show up once, on the same turn as the straining action, not every turn when the number = 2 or 3 (which happened when I test your suggested code).

Something like this would be my ideal scenario:

Lift mattress
Nothing but concrete floor.

Push mattress
You push the mattress around.
You feel a bit of strain in your left wrist.

x me
Looking good!

Take pole
Taken.
The strain turns into pain.

You can put the “if” bits in the commands to get that effect:

Carry out mattresspushing:
	say "You bend over and push the mattress around the limited floor space.";
        increase the strain of the player by 1;
        if the strain of the player is 1:
               say "You feel a bit of strain in your left wrist."

This only has text for strain up to 1, but you can add more checks for strain at 2 and 3.

1 Like

Thanks, that’s working well!

The reason that your first code didn’t work is because “Instead” rules fail by default. If you want to use constructions like “…for the second time” then the action has to succeed. So the rule-family you want is “Report”. In this case, “Report looking under the mattress”.

Here's the amended code.
"Escape!" by "Testa".
The story headline is "(original code by Joan)".

The standard looking under rule is not listed in the carry out looking under rulebook. [see the accompanying post for notes about this.]


The Cell is a room. "Your standard escape room. There's a bare mattress on the floor." The player is in the Cell.

A mattress is scenery in the cell. The mattress is a supporter.

Mattresspushing is an action applying to nothing. Understand "push mattress" as mattresspushing. [This is obviously a clunky workaround. I don't want the mattress to be pushable between rooms.]

Report mattresspushing:
	say "You bend over and push the mattress around the limited floor space.".

[Instead of looking under the mattress:] ["Instead" rules fail by default, so it's not the best type of rule to use here, because in order to use "...for the second time" etc., the action has to succeed. ]
Report looking under the mattress:
	say "You grab the edge of the mattress with both hands and lift it up. You find nothing but bare concrete underneath.";
	[stop the action;]

A pole is in the cell.

Looking under the mattress is straining. Mattresspushing is straining. Taking the pole is straining.

After trying straining for the second time:	
	say "You feel a bit of strain in your left wrist.";
	continue the action;

After trying straining for the third time:
	say "The muscle strain sharpens into pain. You drop everything and massage your wrist.";
	now everything carried by the player is in the cell.

The only way to get rid of the “You find nothing unexpected” message is to unlist the standard rule.

In general Carry Out rules shouldn’t print any text, since this allows the library to call actions silently. I’d hesitate to call anything in the Standard Rules a bug, but Look Under is certainly atypical in this respect, and unfortunately confusing if you’re just starting out. Personally I’d avoid getting into the habit of putting messages in Carry Out rules, reserving that rule stage for making alterations to the model world, and use After and Report rules for printing messages.

You’ll notice if you play through the amended version, that the notifications appear in the “wrong” order, with the consequence of lifting the mattress being given before the description of doing so. That’s because the order that Inform checks rules is “Before”, “Instead”, “Check”, “Carry Out”, “After”, and “Report”.

I know it seems bizarre that “After” rules shouldn’t be, well, after an action has finished, but there’s a useful reason: it allows you to easily tag on extra consequences to an action succeeding, such as a greedy NPC who snatches things out of the player’s hands, or makes sarcastic comments.

“After” rules stop the action by default. You’ll notice if you play the example through that you get told about looking under the mattress the first and second times, but not the third time. As you can see, the way to change this is using the statement “continue the action;”. Its converse is “stop the action;”.

Personally, I always end statements in rules with a semicolon. That way, if I need to go back and extend the rule with further statements, I don’t have to remember to change the period. (A period is only accepted as the conclusion of the last statement in a rule.)

1 Like

Thanks for the explanation! I’ll keep practicing with all of this.

1 Like

Oh cool, I never realized that was the reason for that piece of advice!

Largely Irrelevant Pontification

FWIW looking and examining both have standard carry out rules that print things–but those actions are entirely about getting things to print, so it doesn’t make sense to call them silently anyway. The carry out looking under rule is very weird–it also has a strange format, where it’s written as for “an actor looking under,” so it applies to any actor–but then there’s an if clause that ensures that it only does anything if the actor is the player. So it might as well be “Carry out looking under” instead of “Carry out an actor looking under.”

I suspect that it may have gradually evolved into its current form; it certainly seems like it’d make more sense as a Report rule.

Yes, I did think about explaining that “After” is part of the I6 legacy, but decided I’d aim for clarity rather than historical completeness.

I know the justification for Examine’s Carry Out rule is that, well, that’s what examine does, but I’d still prefer to have it in a Report rule so that if I were writing, say, a Cthulhu story (where reading and examining eldritch exotica have mental side effects) I’d just be able to put the crazy-code where it should be instead of having to futz around with the messages too.

And Look, of course is a massive slab of light-calculation code that it’s best not to mess with.

I must say that I’m very curious about the new version of Inform that Graham Nelson & co. have been working on, which won’t have I6 running underneath and will be all logical and sorted out.

I wonder if I’ll end up missing I6’s little weirdnesses. It’s gotten to be like having a favorite “colorful” auntie, and so what if she’s taken to wearing her bra on her head?

Ah, you may be misunderstanding the I7 plans. The next release will still compile through I6. It will have a new intermediate code layer which could be compiled to a different back end, but with the same semantics.

As far as I know, there are no major changes to the rule mechanics, or the light calculation, or anything else like that.

2 Likes

Future versions (after this upcoming release) may rearrange all that stuff, of course, but that’s still speculative.