There are several ways to approach writing complex behavior in Inform 7.  Two common ones are what I’ll call “action oriented” and “subject oriented”.  It might make more sense to use “object oriented”, but that term already has enough associated connotation and confusion.

The “action oriented” style seems to be the one used most consistently in the Inform 7 documentation, and as you would expect it’s very useful and readable.  An example is something like this:

Instead of examining something in the presence of Dan when Dan is bored:
	say "'Quit gawking at the scenery and entertain me!'";

Note that this code applies to the player whenever he or she examines anything.  Although there are additional qualifiers attached that limit the scope of the rule, and we could certainly add more, it fundamentally works as a modifier (or in this case, a replacement) for a single action against a range of possible objects.

But it’s often the case that you want specialized responses for a number of different actions performed in certain circumstances.  You can achieve this using a more “subject oriented” style:

Instead of doing something to the teak table in the presence of Dan when Dan is bored:
	say "'Quit screwing around with the table and entertain me!'";

We now have a rule that makes anything you do — to the table, and the table only — trigger a generic complaint message.

All this is great as far as it goes, but what if we want to get more ambitious yet?  Let’s say Dan mocks you when he’s bored, and you’d like him to have something different to say depending on what you happen to be doing.  How would we express this?

If we went by the book we could make a bunch of “action oriented” rules, arrange them in a rulebook, and run that rulebook when the proper conditions apply.  If we did that, we’d have something that looked like this (code changed due to Andrew Plotkin pointing out that the Report rulebook doesn’t have a generic version):

The block singing rule is not listed in any rulebook.

After doing something in the presence of Dan when Dan is bored:
	consider the mockery rulebook;

A mockery rule when examining:
	say "'Ooooh, look at me!  I'm wasting time looking at something completely irrelevant!'";

A mockery rule when singing:
	say "'Hold on there, pal!  Ryan Seacrest is holding on line one!  He wants you to be the next audition reject on American Idol!'";

etc.

This works, and works well.  In the case where you want to do anything dynamic to the rules on the fly, this is definitely the way to go.

But there’s another syntax that allows expressing these kinds of constructs in a more straightforward manner, particularly if you don’t need the full power of a rulebook.  The Inform 7 documentation hints at this, but doesn’t always give you full examples of the syntax.  Here are the above rules expressed in this other format:

The block singing rule is not listed in any rulebook.

After doing something in the presence of Dan when Dan is bored:
	if examining:
		say "'Ooooh, look at me!  I'm wasting time looking at something completely irrelevant!'";
	otherwise if singing:
		say "'Hold on there, pal!  Ryan Seacrest is holding on line one!  He wants you to be the next audition reject on American Idol!'";

This is good — I like it because it groups together all the special responses when a particular condition obtains — but often we might want to specify an action that can involve multiple nouns.  In that case, you can use the following syntax (if you have a filling action defined):

...
	otherwise if filling something with something:
		say "'You're wasting your time with that...'";

and, of course, you can specify either or both of the nouns as well:

	otherwise if attacking Dan:
		say "He easily dodges.  'C'mon, wimp!  You'll need to do better than that!'";

It would be nice, as long as we’re valuing brevity, to be able to use the “switch/case” syntax for this — something like:

The block singing rule is not listed in any rulebook.

After doing something in the presence of Dan when Dan is bored:
	if the current action is:
		-- examining:
			say "'Ooooh, look at me!  I'm wasting time looking at something completely irrelevant!'";
		-- singing:
			say "'Hold on there, pal!  Ryan Seacrest is holding on line one!  He wants you to be the next audition reject on American Idol!'";

… but I haven’t been able to find a variant of this syntax that works properly.  Perhaps the new version of Inform 7, scheduled to be released today, will allow this.

At any rate, I hope this was useful.  Rulebooks are exceptionally powerful and many times they are the proper solution to your design issues, but don’t underestimate the power of the “subject oriented” approach.  By keeping your related actions in close proximity like this, you can keep your code clean, readable, and well-organized.

Tags: Inform 7, Interactive Fiction

I thought I’d share an Inform 7 programming tip I’ve come up with in recent work on my new game.  As you could probably have guessed from previous blog entries (here and here), I’m using a keyword-based interface in this new work.

At its core, what a keyword-based interface does is to link up a generic single-token input to one or more default actions, such as examining, asking about, or going.  Here’s a very basic example of some code that you might use to effect this:

Understand "[something]" as examining.

Simple, right?  Now if you type a word that refers to an object, the game will examine it.

Well, most of the time it will, except in a couple of annoying cases.  What if you have a drill in your game?  You could refer to the drill as the keyword “drill”, but if you have a drill you likely also have a drilling action as well.  What happens then?

Drilling is an action applying to one thing.

Understand "drill [something]" as drilling.
Understand "drill in/into [something]" as drilling.

What happens here is that whenever you type “drill”, the system immediately assumes that you want to use the specific “drilling” action rather than the generic keyword examination, and it asks you to clarify what you want to drill.

Likely this is not really what you want.  If it is, you’re fine; you can leave things as they are.  But in a keyword-focused game, you might judge it more important to preserve the behavior of the keywords and force the user to actually specify an object to drill if they want to perform the drilling action.

The reason the parser resolves a command of “drill” the way it does is not easy to pin down through standard Inform debugging commands, but is almost certainly due to the same general prioritization rules that it uses throughout the system:  the most specific match wins.  Even though “[something]” and “drill [something]” are both potentially valid matches for an input string of “drill”, Inform counts the exact text match of the drilling action as a closer match, even though it requires a second token. To Inform, that’s not a problem; it knows how to prompt the player for that required noun.

To get around this behavior, you need to provide a match that’s even closer.  Fortunately, this is pretty easy:

Drill-referring is an action applying to nothing.

Understand "drill" as drill-referring.

Instead of drill-referring:
	try examining the electric drill;

Now we’ve implemented an action tied to an exact match to the input token.  “Drill-referring” is now the best match for an input string of “drill”, and we can wire up the “drill-referring” action to do the appropriate thing.

Likely you won’t run into this type of behavior in a whole lot of places, but it can be nice to know how to resolve it if you do.

Tags: Inform 7, Interactive Fiction