I7 How to 'report' a failure
Standard Black
Report. I understand how to Report the outcome of a successful rule,
but how dow I report the outcome of a failure? I know I can print
something out in the Check rule, but that is less flexible than the
report rule, as I would have to restate the logic in the check rule
just to produce a different (perhaps more specific) outcome.
Thanks
Jim Aikin
Actually, I think that's kind of backwards. If you use Check, Carry Out,
and Report in the usual way, you never need to restate any logic.
To start at the top, I'm going to assume that you're creating a new
action. Maybe you want the player to be able to bounce a ball, so you
need a bounce action. First, create the action:
Bouncing is an action applying to one thing and requiring light.
Understand "bounce [something]" as bouncing.
Then use the Check, Carry Out, and Report rules to handle the player's
command. In this particular case, we only want the player to be able to
bounce the ball object, and the ball has to be held in order for the
action to make sense. So the Check rule will check these conditions --
and if the conditions aren't right, the Check rule will tell the player
why the action can't be carried out, and then shut off further processing:
Check bouncing:
if the noun is not the ball:
say "You can't bounce that." instead;
otherwise if the player does not carry the ball:
say "You need to be holding the ball if you want to bounce it." instead.
With this particular action, there's no need at all for a Carry Out
rule, because the action isn't going to change the state of the model
world. So all we need is a Report rule:
Report bouncing:
say "Boing! Boing!"
Notice that the Report rule doesn't need any logic of its own, because
it will ONLY be reached if the Check rule allows it. Notice also the use
of "instead" in the Check rule: This causes the Check rule to end in
failure (thus shutting off the action) if the conditions listed are met.
Now let's say the player is carrying an egg, and you also want "bounce
the egg" to do something -- probably something unfortunate. Rather than
rewrite the bounce action, write an instead rule:
Instead of bouncing the egg:
if the player does not carry the egg:
say "You aren't holding the egg.";
rule succeeds;
otherwise:
remove the egg from play;
now the broken egg is in the location;
say "The egg lands on the floor and breaks!"
The instead rule encapsulates the functionality of a check (if the
player does not carry the egg), a carry out, and a report, all in one
bundle. This is normal -- an Instead rule will usually apply an action
to only one object (though there's no law that says it has to be used
this way).
Hope this helps!
--JA
Standard Black
wrote:
You must be a teacher. Am I right?
This helps a lot! Thanks!
Jim Aikin
>
> You must be a teacher. Am I right?
I'm not a classroom teacher, but I teach. I've written The Inform 7
Handbook (www.musicwords.net/if/i7hb.htm), plus a couple of music books
available from Hal Leonard Publishing, and I write tutorials from time
to time for music magazines. (Check out my feature on GarageBand in this
month's issue of Drum.)
Also, I teach cello to private students, so I guess maybe I _am_ a
teacher, yeah.
--JA
Jay
> Standard Black wrote:
>
> > You must be a teacher. Am I right?
>
> I'm not a classroom teacher, but I teach. I've written The Inform 7
> Handbook (www.musicwords.net/if/i7hb.htm),
The handbook is GREAT! I think the general I7 documentation is well-
done, but having it talked out in the manner you do in the handbook
helps immensely. I'm working my way through it slowly.
Snacky Pete
wrote:
And I will second (third? fourth?) that!
Jim Aikin
>
> And I will second (third? fourth?) that!
The feedback on the Handbook is very encouraging. Thanks!
BTW, if you're still using the 1.0 edition, you should download the new
one. It's still in beta, and will remain so until after the next release
of I7, but there's a LOT of new material in it.
--JA