[I7] Interesting Consideration for Debugging and Learning

Here’s another example based on finding things that can cause friction for people writing in Inform. Consider this:

The Test Lab is a room.

Kitty Pryde is a woman in the Test Lab.
A glass box is a container in the Test Lab.

Hypnotizing is an action applying to one thing.
Understand "hypnotize [someone]" as hypnotizing.

Check hypnotizing:
  if the noun is not a person:
    say "You should try that on living things."

A sample transcript:

I took out some of the rules that are in fact displayed for the action against Kitty just to highlight what this looks like. The issue is that the response to hypnotizing the glass box is a standard “You can only do that to something animate” as opposed to the message provided in the check rule. There is nothing at all printed as a result of the actions of the rules tracing for that action.

I’m looking for ways to present this material such that what people need to know is provided as part of a contextual example, rather than having to skip around a bit in the manuals, particularly in cases where intuition based on certain already-read sections can lead people astray.

Yeah, this isn’t explained very well in the documentation. The relevant bit is this, from §17.1:

 "[someone]" needs to be the name of anything of the kind "person", for instance (though as usual that person will need to be in sight of the player for the name to be accepted).

And then, the thing is that when you have “hypnotize glass box” it doesn’t match the Understand line, so it doesn’t get processed into an action, so you get a message for a parser error rather than any of the action-processing rules. The “something animate” message is a specialized parser error message–it’s what the parser does when it’s trying to match a [someone] token but can only find inanimate things.

A solution is to change “hypnotize [someone]” to “hypnotize [something]”; that way the command will be understood and then stopped by your check rules. Though this will also mean that the attempt to hypnotize the box will take a turn. With a little bit of hacking you can replace the parser error message with your custom message when the player is hypnotizing–though this particular message might serve as a wholesale replacement for the “you can only do that to something animate message.”

What the best way to present this is, I don’t know.

Actually, I think my example with your explanation is probably the best way to present this. One way I’ve found to get Inform 7 into people’s head, in terms of building up intuition for it, is just to present examples that showcase a problem and then explain why it’s a problem and then, as you did, provide an alternative.

My current approach is I just start accreting aspects to one running example. It doesn’t matter that the example isn’t a coherent “game”, per se, and I don’t detract from the ideas I’m trying to get across by filling out a lot of descriptions. (Unless, of course, the description is necessary for the point being demonstrated.) I treat the running examples as basically a series of test scenarios.

Inform 7 is definitely an interesting and fun language to try these things in.

Another interesting example. Let’s say you add this:

Check someone hypnotizing someone:
	say "[The person asked] lacks your skill to do that.";
	stop the action.

This is to stop Kitty from being able to hypnotize you. I would think the “stop the action” would stop everything at that point. But what happens is this:

I’m getting both messages: mine and the default one. So then I tried this:

Check someone hypnotizing someone:
	say "[The person asked] lacks your skill to do that." instead.

I took out the “stop the action” part and just used an “instead” qualifier. But the result is the same.

I’m not sure if it’s the “right” way but what it seems you can do is this:

Check someone hypnotizing someone:
	stop the action.       

Unsuccessful attempt by Kitty Pryde hypnotizing someone:
	say "[The person asked] lacks your skill to do that."

That seems to work.

Again, it’s just one of those things that you can easily do based on what you think you are intuiting from what you’re learning. I know some people can find that terribly frustrating; but I find it somewhat fascinating as an exercise.

…yeah, the unsuccessful attempt rules and the messages that action rules print are just two different systems that don’t play together great, at least as far as I’ve been able to tell. When I did a game that went entirely through NPC commands, I wound up with your solution, separate check and unsuccessful attempt rules. (There was an even messier thing that had to do with a rule that blocked an entire kind of action for the robots.)

It seems like the officially-recommended solution to that is something like this:

Check an actor singing (this is the don't sing rule): if the actor is the player, say "You don't know how to sing."; stop the action; Unsuccessful attempt when the reason the action failed is the don't sing rule: say "[The person asked] [don't] know how to sing."