Standards for creating a competent, modern IF in Inform 7

I realize that everyone’s requirements for their own IF are different, and some people don’t mind seeing “a chair is here” or “as good looking as ever.” Default messages don’t automatically make your game bad. But it seems to me that the stories that really stick with you are the ones that go out of their way to provide unique flavor text.

To that end, I’ve been wondering if anyone has attempted to define a list of practices or extensions which are most useful towards creating a quality work of IF - code that provides the tools for reducing the amount of errant, awkward or default output.

I suppose there would be several categories of useful code, the first primarily dealing with getting rid of parser errors or awkward-looking output. For example, the issue of “take all” including all the scenery and people, happily telling you that John doesn’t want to be picked up and the trees are fixed in place. I found the resolution buried in a post on this forum:

Rule for deciding whether all includes scenery: it does not.
Rule for deciding whether all includes backdrops: it does not.
Rule for deciding whether all includes people: it does not.

I’m not sure how easily I would’ve discovered this if I hadn’t happened to browse to that thread. I suppose a game could be designed that allows for portable people, but in general these few lines would be beneficial for most new authors. Along these lines, what other simple additions are there that could be universally recommended?

Then you might have a category based on getting rid of default output, or descriptions that are not in error but could use some work. This might include extensions such as David Fisher’s Default Messages, or Emily Short’s Room Description Control and Tailored Room Descriptions. For general code toward this end, the verbose default enabled by the line “use full-length room descriptions” is something I notice that most all modern games include. Another useful line that budding new users ought to take advantage of is:

The description of the player is “.”

Essentially what I’m looking for is a framework, a starting point where you can say, alright, if you begin by learning this code and these extensions, you’re well on your way to making a nice memorable piece of interactive fiction.

For those who have created a fully-realized IF like this, what code do you consider the most helpful/useful which is also broadly portable to other games?

I prefer something like this. Instead of going nowhere, try listing exits. There’s several extensions that list exits available on the Inform website.

I’m also fond of having a compass rose in the status bar.

The worst thing you can do, in my mind, is create situations where the player must read your mind to solve a puzzle. Make sure all your puzzle solutions will make sense to your average IF player - or, more accurately, that at least one solution to every puzzle does. This does not mean that you can’t make really hard puzzles, though.

As an example of what I mean: Consider a puzzle involving getting to the second floor of a house without going through the first floor, where the correct solution is to wear body armor and fire a ray gun at the ground, detonating a buried land mine. The mine’s explosion throws you up into the air, and you just so happen to go flying through a window in the second floor of the house. The problem here is that most people don’t go around firing ray guns at the ground for no apparent reason, making the puzzle unsolvable without an absurd amount of luck (or looking at the walkthrough).

Someone on RAIF just made a post that applies here:

groups.google.com/group/rec.arts … 0e02921e3#

FWIW, the next version of Inform will revise the way take all is handled to make this less necessary, and do some related things towards tweaking the world model.

That doesn’t cover getting the protagonist’s description right and guaranteeing interesting text about every object, though, of course.

Aaron Reed’s extension Small Kindnesses implements a number of niceties, including some mentioned in this thread.

If you’re thinking of making an extension out of your research into this topic, check out the way that Aaron has organized the extension–each piece of functionality is placed into its own section so that the user can eliminate that section if they don’t want to use Aaron’s implementation (see the extension documentation for more explanation).

–Erik