Why is there separate procedure called Report? Why not just print the outcome in Carry Out?
I have to play devil’s advocate to myself here, because I hardly use the Report rules at all.
I’d say the main reason is: There can be multiple or overlapping code paths to an action succeeding, that share the same output text. And sometimes it’s a kind of action that’s running on different objects. With a report rule, you can avoid having to duplicate the code that produces the shared message(s). It’s part of the systematic separation of things that Inform likes.
Here’s a simple example. Say I’ve got a red door that when I open it, monsters materialise in two rooms I’ve already been in. And a yellow door somewhere else that when I open it, a cave in occurs in a different previous room (but we’ll only see it when we go back there).
You can write a carry out for each circumstance that makes these things happen, but the report rule will still just “You open the door.” Or “You open the [colour] door.”
If the game had twenty of these door things happening, they could still all share that one report rule.
Sometimes you want to change the message that gets printed out but still keep the code part of the action the same.
If you say:
After taking a rock:
Say “Oh, that rock is heavy!”;
It still does the “carry out” part (the player now has the rock) but replaces the “report” message (so it doesn’t say “taken”).
I don’t know any other real reason for it.
If you “silently try” an action, the carry out rules run, but the report rules don’t. This is generally used when you want to print failure messages, but don’t want to print success messages.
At the time when the bottle spontaneously combusts:
if the player carries the bottle:
silently try dropping the bottle;
if the player carries the bottle, end the story saying "Ouch ouch ouch!";
otherwise say "You feel the bottle heating up and hurl it away!";
[other code here]
A thing can be sticky.
Instead of dropping a sticky thing: say "You try to let go of [the noun], but it sticks to your hand!"
In this case, you don’t want a “Dropped.” message appearing in the middle of the action sequence, but you do want any failure messages to appear, if the player can’t drop it for one reason or another. “Silently try” is the mechanism Inform offers for this, which runs all the carry out rules (so it’ll move the bottle to the location) but doesn’t run the report rules.
It also gives the author another place to hook in for custom messages. If describing the action is intertwined with actually performing it, you can’t change one without changing the other. If they’re separate, you can insert new After or Report rules to change the descriptions but not the functioning.
Or vice versa, by replacing Carry Out.
The report rules are a full rulebook, meaning all the usual rule precedence systems can be used. Want separate reporting rules for specific NPCs? Want to report things differently if a scene is active or some other condition is true? Easy when you can put those conditions in the rule preamble.
Rules also make it much easier to add different reporting behaviour selectively. You don’t need to replace an existing report rule with all its code, you can just add a new rule that is more specific.
Also, multiple carry out rules can run, so you wouldn’t want to report things before all the results have happened yet.
Since report is the last bit of action processing before “every turn,” it’s a good place to deal with anything that’s happened during the turn.
Some people put everything in the same type of rule (like this person did with Instead), but splitting stuff up into separate rules is conceptually clearer and helps prevent certain bugs. Still, for a lot of things it won’t really matter which type you pick. Looking at recent sources, I think for simple things (i.e. an action that produces one say “blah” and that’s it) we tended to use Carry Out and Report interchangeably.
If you have NPCs running around doing things, or machinery, a careful use of “Report” can make sure that the player sees those and only those activities visible to the player character – but they still happen (in “Carry Out”) whether or not they are visible.
If you don’t have a lot of stuff going on “out of sight out of mind” the distinction may not seem as important, but it becomes essential to detangle it as soon as you have both “visible” and “invisible” things happening at the same time.
So, for example… the player can tell their assistant to go on some mission, and the assistant goes and does a bunch of actions, and if the player follows the assistant around, they’ll see the “report” messages for all of those actions, but if the player walks off somewhere else, they won’t see the report messages but the actions will still happen. It starts to be a lot cleaner to have a separate report phase.