I can’t judge whether it has the best support, especially since at least TADS 3 also has these capabilites. But here are some concrete points:
“act-based IF”
This might refer to Inform’s action handling rules, and/or to its Scenes mechanism (if we understand “act” in a theatrical sense).
Action handling
Inform gives you a lot of possibilities to modify when and how actions take place. Specifically, the Before, Instead, Check, Carry Out, After, and Report rules allow you to hook into the process at various stages and fine-tune everything.
See chapters 12.2 How actions are processed and 12.21 Guidelines on how to write rules about actions in the docs for a short overview.
You can also differentiate further by making some rules more specific than others, as zarf already said above (for example, restricting them to a class of things, or to a Scene, see below).
A slight drawback is that it can sometimes become a bit difficult to sort out what exactly you need to do in order to get a certain desired behaviour, when you have a big pile of rules which might apply in any given situation.
Two simple examples for illustration: (click to expand)
You might use an “Instead of jumping” rule to quickly override some default behaviour, but you have to keep in mind that this means that the action did not actually take place, as far as Inform is concerned (because we have done something else instead). So later checks for “If we have jumped” will turn out false, which might not be what you intended.
Or you might use a Carry Out rule to customize what an action does, and then find out that the Standard Rules have a Report rule which tacks on a message that’s incongruent with what you just implemented.
But of course, you can solve these problems by studying the documentation and the examples and by using the RULES and ACTIONS testing/debugging commands.
And arguably, drawbacks like these are hard to avoid in any system of a certain power and complexity. For example, in TADS 3, you might use multiple inheritance to give a subclass the characteristics of more than one parent class. When you then call a method which could theoretically be inherited from several parent classes, you need to understand which method will actually be executed by TADS. For details, see “The Object Inheritance Model” in the T3 System Manual, “Multiple Inheritance” in the T3 Technical Manual, and the WP article on the “diamond problem” of multiple inheritance.
Scenes
Scenes are a way to organize plot events and other goings-on in time. Basically, they are global flags which you can check in order to make rules conditional on them. For example, you could define a scene called “the Apocalypse” and write “Every turn during the Apocalypse: [...]”.
Scenes can also have properties:
“A scene can be dangerous or relaxed. The Car Chase is a dangerous scene. The Apocalypse is a dangerous scene. The Beach Party is a relaxed scene.”
And then you can define stuff conditional on whether “a dangerous scene is happening”, for example you could forbid the player to WAIT or to otherwise waste time.
By the way, note that there is a known bug (Reports here and here):
Contrary to what the manual says, the syntax “... during a dangerous scene” does not work (while the same syntax does work for referring directly to a scene, as in “during the Apocalypse”). The workaround is to use:
“when a dangerous scene is happening”.
Scenes can also end in various ways, see chapter 10.8.
In the end, that’s nothing that you couldn’t implement in other ways in different systems, but it’s nice to have the functionality & the “scaffolding” already built in.
For TADS 3, see Eric Eve’s scenes.t.
