Possibly novel way of preventing multiple actions per input command

(there have been a number of threads over the years about the issue, but I figured they all seemed old enough at this point to warrant posting this independently)

I was hitting my head against the “how to stop players from entering multiple commands in one line” issue, and came up with something that’s pure Inform 7 and feels clever, or at least is compact and seems robust, though I’m not sure if the approach is actually new:

"Lab"

[Inform 7 v10.1.2]
Action points is a number that varies.
Before reading a command: now action points is 1.
The check action points rule is listed before the generate action rule in the turn sequence rules.
This is the check action points rule:
	decrement action points;
	if action points is -1, say "Message to the player goes here. Only the first action was executed.";
	if action points < 0, rule fails;

[TESTING]
The Lab is a room. Labrat is an animal in the Lab.
Persuasion rule for asking Labrat to try waiting: rule succeeds.
Before reading a command, say "Turn [turn count][run paragraph on]".
Test me with "z / z,z,z / z. z. z. z. / version then version then version / labrat,z,z,z / z,asdf / z,asdf,asdf,asdf".

Starting with the realization that the problem is, definitionally, that more actions are being generated than commands are being read (in the sense of the defined activity) …

So, rather than fully prevent even the attempt, effectively one action is always let through (which I feel is actually good behavior, as long as the message to the user afterwards is clear) and then any more that follow are just fully cancelled before any kind of processing in the turn sequence rules, so time does not pass etc. for them either. I’m using a number (rather than a boolean or whatever) for a simple way to only print the refusal message once per input, so as a kind of bonus functionality, the allowance value could also be reset to an arbitrary number higher than 1, though it’s hard to imagine that being terribly useful.

This seems to work in all my test cases, and does not interfere with commands directed at characters either (like messing with commas in the command can), so I just wanted to share, and also see if people would come up with cases where this approach might end up backfiring, or something else I’m missing.

I guess one worry is whether simply failing out of the turn sequence rules before actually reaching any kind of action processing might have side effects? I’m not really familiar with the internals, but it did seem that placing this intervening rule elsewhere in the sequence can make it not function, or even make the engine crash, and I just sort of lucked into this seemingly working as intended thanks to a vibes-based guess. At the least I suppose that if a specific project is doing something fancy of their own with the turn sequence that e.g. relies on the rulebook finishing, this would get in the way.

And then there’s the last two test commands with the nonsense, which could be handled more graciously since the premise is that everything after the first command should be ignored rather than complained about, especially with assumptions about “talking”, but that feels like its own rabbit hole with the parser …

5 Likes

I do have to ask: what’s your goal with preventing multiple actions per input?

1 Like

My current project is not quite traditional IF, it has a pretty involved battle system, and tightly scheduled “cutscenes” with long bits of description that require some reactions, so a player trying to be efficient and queuing a bunch of actions will probably just fall into failure and/or blast their screen full of text they didn’t know would be coming. And due to the bespoke nature of most of the interactions, I don’t see a great need for it in the first place.

I suppose it wouldn’t take much work to make this a toggled state that only referees the actions when it’s really necessary, though.

Makes sense! I just try to check, because going against players’ intuitions is not something to do without a reason, but it sounds like it makes sense in your concept.

1 Like

This approach gets right to the heart of the matter. It should work in earlier versions, too.

The placement might as well be before the declare everything unmentioned rule, since the mentioned status of any object is not likely to impact the message to the player.

1 Like